From nobody Sun May 1 14:52:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F4612D195 for ; Sun, 1 May 2016 14:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d30saHEj_w31 for ; Sun, 1 May 2016 14:52:18 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0100.outbound.protection.outlook.com [104.47.2.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C589012D144 for ; Sun, 1 May 2016 14:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6lHO7UbKPAo7lkysjDu+EFgAB5ipnLCK0ehtkWNz4JU=; b=i0Vxb/IA//xO50LmBk9HBKyKwfZqbFX4fret8tskogEdPlr4wMLhmoI5psgdcxQy23z7QjjdE0kon3KB3UA6hhVrXacFl70wmpvfOxC19e9+3+HnkPZ05pQaRhAYX7TTtQukEHUsLVkULsl5SuXSyjjieoFCubG83rh7zCTBQfk= Received: from HE1PR0401CA0035.eurprd04.prod.outlook.com (10.166.116.173) by VI1PR04MB1584.eurprd04.prod.outlook.com (10.164.84.142) with Microsoft SMTP Server (TLS) id 15.1.485.9; Sun, 1 May 2016 21:40:26 +0000 Received: from DB3FFO11FD040.protection.gbl (2a01:111:f400:7e04::159) by HE1PR0401CA0035.outlook.office365.com (2a01:111:e400:c512::45) with Microsoft SMTP Server (TLS) id 15.1.485.9 via Frontend Transport; Sun, 1 May 2016 21:40:26 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; tcs.com; dkim=none (message not signed) header.d=none;tcs.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by DB3FFO11FD040.mail.protection.outlook.com (10.47.217.71) with Microsoft SMTP Server (TLS) id 15.1.477.4 via Frontend Transport; Sun, 1 May 2016 21:40:25 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0172.MGDPHG.emi.philips.com (141.251.190.20) with Microsoft SMTP Server (TLS) id 15.1.477.8; Sun, 1 May 2016 21:40:24 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0477.014; Sun, 1 May 2016 21:40:24 +0000 From: "Dijk, Esko" To: Abhijan Bhattacharyya Thread-Topic: Using draft-tcs-coap-no-response-option to *enable* responses Thread-Index: AdGcj/YQCrN+XzqqSpmFRQBEAJ7w2AAGgNwAAdGkGKA= Date: Sun, 1 May 2016 21:40:24 +0000 Message-ID: References: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.73.250.218] X-MS-Office365-Filtering-Correlation-Id: 03da9b9e-f4fe-4d99-3497-08d37209351c Content-Type: multipart/alternative; boundary="_000_fa7de3e8b19a41189f7bc668b7eff60cHE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(428002)(189002)(85714005)(374574003)(199003)(52084003)(377454003)(66066001)(16601075003)(86362001)(1096002)(4326007)(5003600100002)(5890100001)(24736003)(2906002)(3846002)(512954002)(2900100001)(2950100001)(790700001)(10400500002)(586003)(1220700001)(15975445007)(6116002)(81166005)(102836003)(5008740100001)(260700001)(101416001)(189998001)(87936001)(105586002)(11100500001)(19580405001)(92566002)(6806005)(54356999)(19580395003)(50986999)(16796002)(76176999)(106466001)(33646002)(16236675004)(108616004)(84326002)(19300405004)(230783001)(19625305001)(19617315012)(19625215002)(110136002)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB1584; H:011-smtp-out.Philips.com; FPR:; SPF:None; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD040; 1:gTd5aKVTqfaHlNu9T3LSAaUpPWDpm3Bg9L9UyS58/RItjiGi5PXyTZ2jokRBfahGO4Rrxh3uFs83khEL8aXArAMc6auGK19Ti0WisqOjgfs1xFNXCkxJwYdmT4hGyCg0daz/X+EAH15E39gRsCJdfiDKIReLSjmA16Znz7OnnrBX1rvnUuf60/u8dhJvapkgkI4s+z+KK+7OOmMhNIwInQZWKP0psfTkxnfAmvs3sltUKwI0WCXTtRUIKOVgkpMngUC1WQ1/LD1qwCPCZRzWCSCOTxcpWAT5oDZtITf3o7bVlYhLPrh+lEsU2H6wNMldd00DqpTiGrtOXD0N6qarmtRFQrJAeFGWhVWeqIC51+mS/X7mHJh5HWtIaT/DyGvUlD55XIvQJT6V+GrIdxA2mIjiipx+205sFJ4XMHobHlFST68B6eHnrMWbwDNq5BSs X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 2:J8ZsQ6bcztemmWDlhkBTN07xyfYPAZ2YFH+fU7mrPgED0hy05J1t0ZZ7NTBCY6A/Nb5ee8UQcY3SIHPNRhanmRH88c9C6e39TdsDbaR0gf2f0hE5d5LFlsnN4NUgekAWhZT0XhsC/buJKE3ckhpvesVA5tToprmQtnDg/zBLEi02vYyzUtyTDKvrEA3K7c9X; 3:3vYjHCiKBmNroYi1Seq8V2XxQEwBvCeJwsC7OaHkzIcYkPP+/NyR7ctjxvI4v+T+umDylY527WfHq3doTMcbYlUmRoplxgaDv7ls/PP41gIGNCbRwn9lsXGdXGs3shdreUwYuPrKIUQs9qlUT0VIp1bN/wXZg2hiIZR4idVgeawBEwYyKTT6cq0/vX9wSZ8er/cuhcoWF+TyWM7URdmdM2zPpGzXWpAn1jgpIpgQsns= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB1584; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR04MB1584; 25:cMjgNmuClVcqJVubVf4dixJjD+X2h6PSGqmRSW84g?= =?us-ascii?Q?XXXwxTaHa6jSb/TYeHdiTH3L2hNEmra6hekp4kqp4hXUzpomHFxqQ0nL4QGH?= =?us-ascii?Q?2VLUIW+E6Xywc7idT/VbuI5xwpN0r5U67LPIfYMOGHCQH0IUMdRzsCevgfAG?= =?us-ascii?Q?hwxBfKw5JnrNM7PSFQGaKq2heHnEjT6PoEEwwYldtLRFZvFCL0/Mzk/hn/mF?= =?us-ascii?Q?O194WesPE8M5Vb0E6gGpyEdLlhu57mEAn7s5k6oLHE/QctClLITcbzloRHWO?= =?us-ascii?Q?qlsFcyZ/mZJMHIjElROYH8C2l0R+ds021LkgKwRuD/gM9dPNRoUmAWvlJ9Uy?= =?us-ascii?Q?gdg+Et8Z2t+pPgLqD8dc0uVK3fQCrXweZoJrWXAea+oIiBAroL2DQde0Aob9?= =?us-ascii?Q?mf3MPhygPiVhP2TZH1BBgtmSAth49GO7PMcC6R1JZwWcIQ8BrIfZ5ffy4d7R?= =?us-ascii?Q?4SNldocIETscsZCJSbIHuZGEZwXPMp5AnHyqCtBfDEvyUOqYvfqzxVW7eel2?= =?us-ascii?Q?R/CFoSO0PVCfkoALXngQdIqdMS0+XvbZNPJBX+0ZgM+hxhXAAx5/XlJXZc7U?= =?us-ascii?Q?Zw6PJhO4V6WXJNhB1tCVecFvlSLimtkqHsp9tNX6b0ARWLF0rd8jB5LB4mRc?= =?us-ascii?Q?Hdq5bfYMl7JUp9W8crvD0Q4vm0qzpRcJnLfg64E/Q3dvxrYj9T8ZGoZd0fQ2?= =?us-ascii?Q?vT5q6P59bJJDorpxg/qymD/4CPbum2/KuCUivcOhURdEaWQfLf/lQoUiG5EJ?= =?us-ascii?Q?aV9omSwZE4HqGdm15BV1d/R+WcVsb8P1sjjaVv9RGVWVSy8hTr+nXmH5f8M8?= =?us-ascii?Q?Eqw5GM+QLLLJtuHnInoXfFF+U+DALt5wsFh7z87OPJVK7i7n5kft0OyeudU3?= =?us-ascii?Q?cAJ7AYBbDuawrCHYd+6ycJhCc9kjvfTR5h7FRMu7XTEHf+l9V6XJqgLpXG13?= =?us-ascii?Q?mq7aPGzTGKz5C/AClBfGjJKR1qD2yhySvnj2E9Cc6F2KXMc9lohLfPQPk14S?= =?us-ascii?Q?53V/9Ir1voV5F71Qe01NuVLyvAoEne73LneOOHtM7KFAvghj0T6ydZpx5gcY?= =?us-ascii?Q?SL88JaBLac6Px8cH156HBvCL7Zjz7TzcFrW28DsK2avDzWbRw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 20:f+43RRZ2yW011ApxWSuFkAlaQupH2I2btwjfPsiGzx84+ZcksKl8X+x/xs4mdPd4ow7sr3ZAwdxhW+IOAoxzc+9Rk1/9ZxmaSZzab9MIzpx037ZRHvqslOH0eShxmfJ6iwHNPxJnoz15HdqtaNkFT/nL7EzifGJXxUaMHkZMFxU2JgL4pHQLN/XdJQQZ35Mv7VuGVh88loyIBslAO9tDT2wUN1h42TuZgAtT0Ow2loFJ7Hw6ecCHRSn1IDX7DImgtcyttHaDHWLfvHckT0neSUJSVKOOwpINunke+Iun2dKd5IykuNI0uCjmaxru/AZSN1l3Nrv3XR3F0ZRGCJ7hvGTojwHR6G+wFBCERzHkiTOWWzeJfrwXnRemR/d+inWfZjT8DzLwnnhIeqQSWqLx8R0nzruf0HDvTWlt6E1E7jnsVI3oLalACv6eESwWKvjUET6RLWRJZ0sBilThLBvVk/sWPfBEjDGhRf8aoMdykElp6hcyoY6rY79e2OL81BE5 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(114017886912203)(220618547472400); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(13018025)(13016025)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:VI1PR04MB1584; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB1584; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 4:8YiV3o0fsWpq14UG9zqd3OfiHqbLmS7zGITYjm5VhfbNJclGoGcPuX02ubeeVZrPmjurMShTSZu0CP5vzmvMVQy+YzGJIpLa3+tSoaF/++D8wzxIeb8SnAUpRQbvfhAMnAuDCeGQC3vfjm+mexBxkSjTj5XDwfNyfnki6r5X86T+6d/EUk0HBmdTy8HwDUUc6qRv5rP2DydkDcs065PRKrX8dBlJb9m1n+KnTPDaUFeFMlAGJSsqDf8Ph3LGaMRAAJxi+GkmoQ4zTFMVp9t6QXJOH2UJZpdQjd72NgwmMNdDOxRj8nvFfV1BKOOU952hzUxRhWrSi2FFumJd7v99c7O4Gr0VRGVvyfmqf+d8+pPpDGjzoYDYkBdkXUVFtCWcjPMPLjHfKFjo4pecbut0g01H3GdY48bc1kbdvujqB/jG0/iCVBvr5kK7CIQp7IWe6GDCdMRMIcdlzu74Pw6SLKdk1Cgl4znzta0x3DgqHSjub9gXA5B2L6IbWnLpZ5oqBnLKSMX0xgGUHeSC6GapAQ== X-Forefront-PRVS: 0929F1BAED X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR04MB1584; 23:J2SYwpiiN/agPsyS7o7OkvoIxDjTAQvAR5rP1SVfB?= =?us-ascii?Q?wc+yktwF67uhj+GuoevJpbVsmMnEZUQWnBPJVgIfDaa5iv6xai2kvO/lS9rt?= =?us-ascii?Q?6njAufZx80COZJH+RrweQsQ0DRCRcDnMvwTmmZVPFIF6Cpawp5GxMkI9tNdm?= =?us-ascii?Q?KjnnQA3CXiZ8inYkFcnTSFdnwTTxnFYUbCVqRjRNUnHn3FUnHOzpY4bwtmnm?= =?us-ascii?Q?VvUEgDCRa+dQQ3cTm/Xx0QTu/PAVd8w2+Rb8cpH54ClmOYNsUnRRKgqxjFqB?= =?us-ascii?Q?SGQkggC6+xqfbfkQp2+KNMJF/Q6PUzmW+KP10hH3yDfgjaEGb6tpDIqksz8x?= =?us-ascii?Q?oUGpgvR/6ez5YR/XLD/yc6t20umdgeIpfNtJosOIWtALwD4EErwKNdOSFNQB?= =?us-ascii?Q?V92KaAMcCs/jmaCMTk1822ez12kp88cvFJf4Jy4zHhcaZOGTVX7vLJnth553?= =?us-ascii?Q?xKZVyYaEsGe1fjNL94LC+NTp50TmS3oC/uM9LuJrHDMRMlfiOJzVd3OJTWjb?= =?us-ascii?Q?cYfqGO9ntdrgr7IcIlQETmGLygOffO2fK91LrbdywqvJGxOW0OTAXiyR4zAT?= =?us-ascii?Q?NCiW0u32BZxNBwP0kNveGJyIWadlqRe4p5wkM8CIWwFR+UkoS9Yd+BklM8iD?= =?us-ascii?Q?GlmH+SKiXJuUDuqz99pEVQa+0kAlDRvGS3o803D0FK8157wmPwO0HCNNB4fn?= =?us-ascii?Q?izsIxIGERN7PnjbNKkfU/zEtHXlZPOmz/nGyiunRIOPw1b8rW+V1lEAx4Wb4?= =?us-ascii?Q?+YyuVZ8EhDj6ACI76tPYR4od8EKgMDGWZw2znbon8bKISRDBPpnczUCABTh6?= =?us-ascii?Q?9tIbePuJ6uNO9us8/Kq3s5dGU4mgldOg6YfJC5YEm5xh7Y3grEQreRbyp57t?= =?us-ascii?Q?p5BkmCW5ayNb7zn8SDpbPiUZp+mZ5IFz2ArlDpf8E40+bQemZVNJrKWtgQYG?= =?us-ascii?Q?moPAJrh/Y0Tas8hnhe7Z/Wx4S0cayiO9p7Og4Wo84Q4twSv0LfC4lafEVB44?= =?us-ascii?Q?4DGcmxZ0yVQvFNowCywwGu+/IxmoCQT9QWYUmSjK27SXHPXq6U9L3SdWD6AL?= =?us-ascii?Q?OVIoxaiUhwaTEE6eKeYOkm8y2D36XW8QHGkaebW7bynIP48xkX8e0XgwT806?= =?us-ascii?Q?ZtXVsw5Kj33gYtjhoE5G6i8ws2Nnrx1InTtDABlYM9A9JoNxnY8eTBdVU5KZ?= =?us-ascii?Q?WTDTMuFS9GhoCoLMUg2ikOFHOrqmdv7oJYj2xVGj4GoQ1B9SzHFGZHWr0wa6?= =?us-ascii?Q?7ib5CliiL1LYbLlHpvJ0L1aV91xjv/QO6sbm4hIOukhidMw6W+TpiP+K181k?= =?us-ascii?Q?L+GB1+taKT4WrvrepySQhw2CUFYQDs4nm48pGDRFyKyyGe4ZbfLimaS+k63V?= =?us-ascii?Q?BsOcOnEUYydcfOoQf+2uFMpHk/Y8PBqrFV+aD5IzOEBw/VjTUVG6FW+sYwXe?= =?us-ascii?Q?Rk3+2YEHe/wwEVyDCynwyauu41V8k9IQteAAJANExYU0OWrruMI?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 5:vWQRqlJh8xg4C8MNaTHTtmvCpLSvEJL1qDAMkp+TVTf5/JOxZnrEK3GkTS07uLHRIoFtlLwf+lSP+iu1CkrHI8JKjyKCuLObQOyWpJSWdyvbtSJdQYJqxLp96Wlg//HLQgGfKFeCTGbD6y7icO26Bg==; 24:VaZhw6ifRSzpOUnMBeb2OujvngIm1+9aFH0tAPibwPn0UATYb7cdQDVD5uHi3ScAkrVhRt6Yt2smIpMyya/J4cIK1hRjMWd/xP1mg9JNZds=; 7:5pDxzN9CDxfYrx8x2TeN557XdurJEt1tIzHaRAYhV48fBcZK99UgWnk6SiUcJv7/+d/+Xk8EImrdko+y4pwH7npXG01IXsKjMQ/GY8kiOlFtED7hPQOVtAArAF+E+31Mh40ON2YZXBSWiwJTOvTdUek5iHqDvM4ZJZGHMrfuIGvN9y7M5XcvXEeOPzVfcRpF SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2016 21:40:25.9436 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB1584 Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 01 May 2016 21:52:27 -0000 --_000_fa7de3e8b19a41189f7bc668b7eff60cHE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Abhijan, > Mandating such server behaviour from the client side will be a bit out-of= -sync with the spirit of the specification. This is not fully clear to me yet ... the client does not mandate anything = from the server; it just expresses its interest (0-bits) and disinterest (1= -bits). The server can always not parse the option (elective) or choose not= to bother about it. This does keep the client waiting for a possible response that never comes;= but that is the same in the general multicast case : the client can never = know if or when a response will come, the server MAY always choose to not r= espond. So what I propose is to use the "indication of interest" to specific respon= se classes in a new way; namely to enable certain response classes that are= suppressed by default. It just happens that the same Option syntax is ver= y well suited for that purpose. A separate draft could be written for that = perhaps if you think it does not fit in draft-tcs-coap-no-response-option o= r if it is too late for that. The we can point to the syntax of the No-Resp= onse Option and re-use it completely. regards Esko From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] Sent: Friday, April 22, 2016 17:17 To: Dijk, Esko Cc: core@ietf.org WG ; Nevil Brownlee Subject: Re: Using draft-tcs-coap-no-response-option to *enable* responses Hi Esko, Thanks for your mail. First of all let me just bring this to your (as well as the mailing list's)= notice that the latest version of the draft is: https://www.iet= f.org/internet-drafts/draft-tcs-coap-no-response-option-16.txt This version "officially" closes the technical reviews and is with the RFC = editor through the IS track. Now coming to your use case (and indeed it is an interesting one) one thing= that we should consider is that the No-Response option was deliberately de= signed not to mandate anything for the server side mainly to ensure that it= does not disrupt the many usefulness of the usual request/response symanti= cs. The draft all along deals with the requesting client's behaviour and it= s expression of interest to the server. Since this option is elective we le= ave it upto the server implementation to honour the client's interest. Now, as per usual request/response symantics the responses are always enabl= ed. The behaviour in groupcomm server in terms of suppressing the responses= on its own is something special and, generally speaking, the clients are n= ot aware of such special behaviour. So, it would be justified to handle the situation at the server's end. Here= is the idea: While No-Response is to expresses client's dis-interest in some or all of t= he responses depending on the option value, it is also true that the option= automatically expresses interest in all other responses (marked by 0's in = the respective positions). The client is going to wait for these responses = upto a given timeout. Now, if the server behaviour is modified like this : = "I have closed my door for all out going response. **BUT**, if I see a fell= ow requesting with No-Response and keeping windows open to some responses t= hen I assume that this guy really needs those kind of responses. In that ca= se let me be linient and let me open the door for such responses. This fell= ow must be available to listen to them as per the prescribed behaviour in t= he No-Response specification." Mandating such server behaviour from the client side will be a bit out-of-s= ync with the spirit of the specification. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: "Dijk, Esko" > To: Abhijan Bhattacharyya > Cc: Nevil Brownlee >, "core@ietf.org WG" > Date: 04/22/2016 05:43 PM Subject: Using draft-tcs-coap-no-response-option to *enable* respons= es ________________________________ Hello Abhijan, in our project we see a clear use case of using the No-Response Option to *= enable* certain responses that are by default suppressed. CoAP allows supp= ression of multicast responses by default, which is what we use for a light= ing multicast use case. However for diagnostic usage we'd like to enable th= ese responses again using the No-Response option which is perfectly suited = for that. However, the draft text currently only talks about suppressing re= sponses (not enabling). Hence my request: could we modify/add some text to show that also the optio= n can be used to enable responses in case where they are normally (by defau= lt -- server decision) suppressed? Just to clarify such usage; which is quite useful in my view. regards Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --_000_fa7de3e8b19a41189f7bc668b7eff60cHE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Abhijan,

 

> Mandating such server behaviour from the client = side will be a bit out-of-sync with the spirit of the specification.

This is not fully clear to me yet … the client = does not mandate anything from the server; it just expresses its interest (= 0-bits) and disinterest (1-bits). The server can always not parse the option (elective) or choose not to bother about it.

This does keep the client waiting for a possible resp= onse that never comes; but that is the same in the general multicast case := the client can never know if or when a response will come, the server MAY always choose to not respond.<= /p>

 

So what I propose is to use the "indication of= interest" to specific response classes in a new way; namely to enable= certain response classes that are suppressed by default.  It just happens that the same Option syntax is very well suited for = that purpose. A separate draft could be written for that perhaps if you thi= nk it does not fit in draft-tcs-coap-no-response-option or if it is too lat= e for that. The we can point to the syntax of the No-Response Option and re-use it completely.

 

regards

Esko

 

From: Abhijan Bhattacharyya [mailto:= abhijan.bhattacharyya@tcs.com]
Sent: Friday, April 22, 2016 17:17
To: Dijk, Esko <esko.dijk@philips.com>
Cc: core@ietf.org WG <core@ietf.org>; Nevil Brownlee <rfc-i= se@rfc-editor.org>
Subject: Re: Using draft-tcs-coap-no-response-option to *enable* res= ponses

 

Hi Esko,
T= hanks for your mail.
F= irst of all let me just bring this to your (as well as the mailing list's) = notice that the latest version of the draft is:            = https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-16.t= xt

T= his version "officially" closes the technical reviews and is with= the RFC editor through the IS track.

N= ow coming to your use case (and indeed it is an interesting one) one thing = that we should consider is that the No-Response option was deliberately des= igned not to mandate anything for the server side mainly to ensure that it does not disrupt the many usefulness of the = usual request/response symantics. The draft all along deals with the reques= ting client's behaviour and its expression of interest to the server. Since= this option is elective we leave it upto the server implementation to honour the client's interest. =

N= ow, as per usual request/response symantics the responses are always enable= d. The behaviour in groupcomm server in terms of suppressing the responses = on its own is something special and, generally speaking, the clients are not aware of such special behaviour.  

S= o, it would be justified to handle the situation at the server's end. Here = is the idea:
W= hile No-Response is to expresses client's dis-interest in some or all of th= e responses depending on the option value, it is also true that the option = automatically expresses interest in all other responses (marked by 0's in the respective positions). The client is going= to wait for these responses upto a given timeout. Now, if the server behav= iour is modified like this : "I have closed my door for all out going = response. **BUT**, if I see a fellow requesting with No-Response and keeping windows open to some responses the= n I assume that this guy really needs those kind of responses. In that case= let me be linient and let me open the door for such responses. This fellow= must be available to listen to them as per the prescribed behaviour in the No-Response specification.&quo= t;  

M= andating such server behaviour from the client side will be a bit out-of-sy= nc with the spirit of the specification.

R= egards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.com=
____________________________________________
Experience certainty.        IT Services
                     = ;  Business Solutions
                     = ;  Consulting
____________________________________________




From:        "Dijk, Esko" &l= t;esko.dijk@philips.com>
To:        Abhijan Bhattacharyya <<= a href=3D"mailto:abhijan.bhattacharyya@tcs.com">abhijan.bhattacharyya@tcs.c= om>
Cc:        Nevil Brownlee <rfc-ise@rfc-editor.org>, "core@ietf.org WG" <core@ietf.org>
Date:        04/22/2016 05:43 PM
Subject:        Using draft-tcs-coap-n= o-response-option to *enable* responses




Hello Abhijan,

in our project we see a clear use case of using the No-Response Option = to *enable* certain responses that are by default suppressed.  CoAP al= lows suppression of multicast responses by default, which is what we use fo= r a lighting multicast use case. However for diagnostic usage we'd like to enable these responses again using the N= o-Response option which is perfectly suited for that. However, the draft te= xt currently only talks about suppressing responses (not enabling).
Hence my request: could we modify/add some text to show that also the o= ption can be used to enable responses in case where they are normally (by d= efault -- server decision) suppressed?
Just to clarify such usage; which is quite useful in my view.

regards
Esko

________________________________
The information contained in this message may be confidential and legal= ly protected under applicable law. The message is intended solely for the a= ddressee(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 retur= n e-mail and destroy all copies of the original message.

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--_000_fa7de3e8b19a41189f7bc668b7eff60cHE1PR9001MB0170MGDPHGem_-- From nobody Sun May 1 20:19:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7886E12D1AB for ; Sun, 1 May 2016 20:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AapQCKi1FNoB for ; Sun, 1 May 2016 20:19:04 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8D12D0C1 for ; Sun, 1 May 2016 20:19:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQB4wyZX/wQXEqxchAt9uXUBDYF2FwEMhWwCHIE8FAEBAQEBAQGBDIRBAQEBAwEjBkULBQsLBwYEAwEBASgDAgICRAkIBgsIG4gHFqYEAQEBZZAtAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYR4Z4UOhCABAQUiCwkMghw4E4JDBY5KhFmEcYFVhCeFY4QgFzeDf4hdjzEeAQGENWQBh1GBNQEBAQ X-IPAS-Result: A2DPAQB4wyZX/wQXEqxchAt9uXUBDYF2FwEMhWwCHIE8FAEBAQEBAQGBDIRBAQEBAwEjBkULBQsLBwYEAwEBASgDAgICRAkIBgsIG4gHFqYEAQEBZZAtAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYR4Z4UOhCABAQUiCwkMghw4E4JDBY5KhFmEcYFVhCeFY4QgFzeDf4hdjzEeAQGENWQBh1GBNQEBAQ X-IronPort-AV: E=Sophos;i="5.24,565,1454956200"; d="scan'208";a="79643022" X-DISCLAIMER: FALSE In-Reply-To: References: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com> To: "Dijk, Esko" MIME-Version: 1.0 Importance: High X-KeepSent: 0940C1E7:182AD649-65257FA7:000FD310; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Mon, 2 May 2016 08:48:53 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF956 | April 21, 2016) at 05/02/2016 08:48:54, Serialize complete at 05/02/2016 08:48:54 Content-Type: multipart/alternative; boundary="=_alternative 001234D765257FA7_=" Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 03:19:07 -0000 This is a multipart message in MIME format. --=_alternative 001234D765257FA7_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRXNrbywNClRoZSBleGlzdGluZyB2ZXJzaW9uIC0xNiBoYXMgdGhlIGZvbGxvd2luZyB0ZXh0 IGluIHNlY3Rpb24gMi4xIChwYWdlIDUpIDogDQoiVGhlIHNlcnZlciBNVVNUIHNlbmQgYmFjayBy ZXNwb25zZXMgb2YgdGhlIGNsYXNzZXMgZm9yIHdoaWNoIHRoZSBjbGllbnQgDQpoYXMgbm90IGV4 cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiIgDQpTbywgdGhhdCB3YXkgdGhlIGNsaWVudCBoYXMg YWN0dWFsbHkgZXhwcmVzc2VkIGl0cyBpbnRlcmVzdCAob3IgcmVxdWVzdCANCmZvciBlbmFibGVt ZW50KSBpbiBhbGwgdGhlIHJlc3BvbnNlcyBmb3Igd2hpY2ggaXQgaGFzIG5vdCBleHByZXNzZWQg DQpleHBsaWNpdCBkaXNpbnRlcmVzdC4gRG9lcyB0aGF0IGhlbHAgdG8gY29udHJvbCB0aGUgc3Bl Y2lhbCBzZXJ2ZXItc2lkZSANCmJlaGF2aW91ciBhcyB0aGUgc2VydmVyIGtub3dzIHdoaWNoIGFs bCByZXNwb25zZXMgdGhlIGNsaWVudCBpcyBpbnRlcmVzdGVkIA0KaW4gYW5kIGl0IE1VU1Qgc2Vu ZCBhIHJlc3BvbnNlIGJhY2sgPyBJIHNoYWxsIHN1Ym1pdCBhbm90aGVyIHZlcnNpb24gd2l0aCAN CnNvbWUgZWRpdG9yaWFsIGNoYW5nZXMgYmVmb3JlIHRoZSBkcmFmdCBnb2VzIHRvIElFU0cuIFNv IHdlIGhhdmUgc29tZSBtb3JlIA0Kcm9vbSBmb3IgbW9kaWZpY2F0aW9uLiBJZiB5b3UgaGF2ZSBz b21lIGNvbW1lbnRzIG9uIHRoaXMgaW4gdGhlIGxpbmUgb2YgDQp0aGUgZGlzY3Vzc2lvbiB3ZSBh cmUgaGF2aW5nLCBwbGVhc2UgbGV0IHVzIGtub3cuIEkgc2hhbGwgd2FpdCBmb3IgeW91ciANCnZp ZXdzIGJlZm9yZSBzdWJtaXR0aW5nIHRoZSB1cGRhdGVkIHZlcnNpb24uIA0KDQpBbnl3YXksIGEg c2VwYXJhdGUgZHJhZnQgKG9yLCBwb3NzaWJseSwgYW4gdXBkYXRlZCBncm91cGNvbW0gUkZDPykg aXMgYSANCmdvb2QgaWRlYS4gTm8tUmVzcG9uc2UgYXNzdW1lcyB0aGUgdXN1YWwgcmVxdWVzdC9y ZXNwb25zZSBzeW1hbnRpY3MgYW5kIGl0IA0KbWFpbmx5IGFkZHJlc3NlcyB0aGUgY2xpZW50IHNp ZGUgYmVoYXZpb3VyIGFuZCBpc3N1ZXMuIENvbnNpZGVyaW5nIHN1Y2ggDQpzcGVjaWFsIGJlaGF2 aW91ciBvZiBncm91cGNvbW0gc2VydmVycywgaXQgd291bGQgYmUgZ29vZCB0byBoYW5kbGUgDQpz ZXBhcmF0ZWx5Lg0KDQpXYWl0aW5nIHRvIGhlYXIgZnJvbSB5b3UuDQoNClJlZ2FyZHMNCkFiaGlq YW4gQmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwgSW5ub3Zh dGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQpNYWls dG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRlOiBodHRwOi8vd3d3LnRj cy5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHBl cmllbmNlIGNlcnRhaW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAgICAgICAgICAgICAgICAg QnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICBDb25zdWx0aW5nDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCiJEaWprLCBF c2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPiB3cm90ZSBvbiAwNS8wMi8yMDE2IDAzOjEwOjI0 IEFNOg0KDQo+IEZyb206ICJEaWprLCBFc2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPg0KPiBU bzogQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT4N Cj4gQ2M6ICJjb3JlQGlldGYub3JnIFdHIiA8Y29yZUBpZXRmLm9yZz4sIE5ldmlsIEJyb3dubGVl IDxyZmMtaXNlQHJmYy0NCj4gZWRpdG9yLm9yZz4NCj4gRGF0ZTogMDUvMDIvMjAxNiAwMzoxMCBB TQ0KPiBTdWJqZWN0OiBSRTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9u IHRvICplbmFibGUqIA0KcmVzcG9uc2VzDQo+IA0KPiBIZWxsbyBBYmhpamFuLA0KPiANCj4gPiBN YW5kYXRpbmcgc3VjaCBzZXJ2ZXIgYmVoYXZpb3VyIGZyb20gdGhlIGNsaWVudCBzaWRlIHdpbGwg YmUgYSBiaXQNCj4gb3V0LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZpY2F0 aW9uLg0KPiBUaGlzIGlzIG5vdCBmdWxseSBjbGVhciB0byBtZSB5ZXQg4oCmIHRoZSBjbGllbnQg ZG9lcyBub3QgbWFuZGF0ZSANCj4gYW55dGhpbmcgZnJvbSB0aGUgc2VydmVyOyBpdCBqdXN0IGV4 cHJlc3NlcyBpdHMgaW50ZXJlc3QgKDAtYml0cykgDQo+IGFuZCBkaXNpbnRlcmVzdCAoMS1iaXRz KS4gVGhlIHNlcnZlciBjYW4gYWx3YXlzIG5vdCBwYXJzZSB0aGUgb3B0aW9uDQo+IChlbGVjdGl2 ZSkgb3IgY2hvb3NlIG5vdCB0byBib3RoZXIgYWJvdXQgaXQuDQo+IFRoaXMgZG9lcyBrZWVwIHRo ZSBjbGllbnQgd2FpdGluZyBmb3IgYSBwb3NzaWJsZSByZXNwb25zZSB0aGF0IG5ldmVyDQo+IGNv bWVzOyBidXQgdGhhdCBpcyB0aGUgc2FtZSBpbiB0aGUgZ2VuZXJhbCBtdWx0aWNhc3QgY2FzZSA6 IHRoZSANCj4gY2xpZW50IGNhbiBuZXZlciBrbm93IGlmIG9yIHdoZW4gYSByZXNwb25zZSB3aWxs IGNvbWUsIHRoZSBzZXJ2ZXIgDQo+IE1BWSBhbHdheXMgY2hvb3NlIHRvIG5vdCByZXNwb25kLg0K PiANCj4gU28gd2hhdCBJIHByb3Bvc2UgaXMgdG8gdXNlIHRoZSAiaW5kaWNhdGlvbiBvZiBpbnRl cmVzdCIgdG8gc3BlY2lmaWMNCj4gcmVzcG9uc2UgY2xhc3NlcyBpbiBhIG5ldyB3YXk7IG5hbWVs eSB0byBlbmFibGUgY2VydGFpbiByZXNwb25zZSANCj4gY2xhc3NlcyB0aGF0IGFyZSBzdXBwcmVz c2VkIGJ5IGRlZmF1bHQuICBJdCBqdXN0IGhhcHBlbnMgdGhhdCB0aGUgDQo+IHNhbWUgT3B0aW9u IHN5bnRheCBpcyB2ZXJ5IHdlbGwgc3VpdGVkIGZvciB0aGF0IHB1cnBvc2UuIEEgc2VwYXJhdGUg DQo+IGRyYWZ0IGNvdWxkIGJlIHdyaXR0ZW4gZm9yIHRoYXQgcGVyaGFwcyBpZiB5b3UgdGhpbmsg aXQgZG9lcyBub3QgZml0DQo+IGluIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiBv ciBpZiBpdCBpcyB0b28gbGF0ZSBmb3IgdGhhdC4gDQo+IFRoZSB3ZSBjYW4gcG9pbnQgdG8gdGhl IHN5bnRheCBvZiB0aGUgTm8tUmVzcG9uc2UgT3B0aW9uIGFuZCByZS11c2UgDQo+IGl0IGNvbXBs ZXRlbHkuDQo+IA0KPiByZWdhcmRzDQo+IEVza28NCj4gDQo+IEZyb206IEFiaGlqYW4gQmhhdHRh Y2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tXSANCj4gU2VudDog RnJpZGF5LCBBcHJpbCAyMiwgMjAxNiAxNzoxNw0KPiBUbzogRGlqaywgRXNrbyA8ZXNrby5kaWpr QHBoaWxpcHMuY29tPg0KPiBDYzogY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9yZz47IE5l dmlsIEJyb3dubGVlIA0KPHJmYy1pc2VAcmZjLWVkaXRvci5vcmc+DQo+IFN1YmplY3Q6IFJlOiBV c2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSogDQpyZXNw b25zZXMNCj4gDQo+IEhpIEVza28sIA0KPiBUaGFua3MgZm9yIHlvdXIgbWFpbC4gDQo+IEZpcnN0 IG9mIGFsbCBsZXQgbWUganVzdCBicmluZyB0aGlzIHRvIHlvdXIgKGFzIHdlbGwgYXMgdGhlIG1h aWxpbmcgDQo+IGxpc3Qncykgbm90aWNlIHRoYXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBk cmFmdCBpczogDQo+IA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbi0xNi50eHQNCg0KPiANCj4gVGhpcyB2ZXJzaW9u ICJvZmZpY2lhbGx5IiBjbG9zZXMgdGhlIHRlY2huaWNhbCByZXZpZXdzIGFuZCBpcyB3aXRoIA0K PiB0aGUgUkZDIGVkaXRvciB0aHJvdWdoIHRoZSBJUyB0cmFjay4gDQo+IA0KPiBOb3cgY29taW5n IHRvIHlvdXIgdXNlIGNhc2UgKGFuZCBpbmRlZWQgaXQgaXMgYW4gaW50ZXJlc3Rpbmcgb25lKSAN Cj4gb25lIHRoaW5nIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIGlzIHRoYXQgdGhlIE5vLVJlc3Bv bnNlIG9wdGlvbiB3YXMNCj4gZGVsaWJlcmF0ZWx5IGRlc2lnbmVkIG5vdCB0byBtYW5kYXRlIGFu eXRoaW5nIGZvciB0aGUgc2VydmVyIHNpZGUgDQo+IG1haW5seSB0byBlbnN1cmUgdGhhdCBpdCBk b2VzIG5vdCBkaXNydXB0IHRoZSBtYW55IHVzZWZ1bG5lc3Mgb2YgdGhlDQo+IHVzdWFsIHJlcXVl c3QvcmVzcG9uc2Ugc3ltYW50aWNzLiBUaGUgZHJhZnQgYWxsIGFsb25nIGRlYWxzIHdpdGggdGhl DQo+IHJlcXVlc3RpbmcgY2xpZW50J3MgYmVoYXZpb3VyIGFuZCBpdHMgZXhwcmVzc2lvbiBvZiBp bnRlcmVzdCB0byB0aGUgDQo+IHNlcnZlci4gU2luY2UgdGhpcyBvcHRpb24gaXMgZWxlY3RpdmUg d2UgbGVhdmUgaXQgdXB0byB0aGUgc2VydmVyIA0KPiBpbXBsZW1lbnRhdGlvbiB0byBob25vdXIg dGhlIGNsaWVudCdzIGludGVyZXN0LiANCj4gDQo+IE5vdywgYXMgcGVyIHVzdWFsIHJlcXVlc3Qv cmVzcG9uc2Ugc3ltYW50aWNzIHRoZSByZXNwb25zZXMgYXJlIA0KPiBhbHdheXMgZW5hYmxlZC4g VGhlIGJlaGF2aW91ciBpbiBncm91cGNvbW0gc2VydmVyIGluIHRlcm1zIG9mIA0KPiBzdXBwcmVz c2luZyB0aGUgcmVzcG9uc2VzIG9uIGl0cyBvd24gaXMgc29tZXRoaW5nIHNwZWNpYWwgYW5kLCAN Cj4gZ2VuZXJhbGx5IHNwZWFraW5nLCB0aGUgY2xpZW50cyBhcmUgbm90IGF3YXJlIG9mIHN1Y2gg c3BlY2lhbCBiZWhhdmlvdXIuIA0KIA0KPiANCj4gU28sIGl0IHdvdWxkIGJlIGp1c3RpZmllZCB0 byBoYW5kbGUgdGhlIHNpdHVhdGlvbiBhdCB0aGUgc2VydmVyJ3MgDQo+IGVuZC4gSGVyZSBpcyB0 aGUgaWRlYTogDQo+IFdoaWxlIE5vLVJlc3BvbnNlIGlzIHRvIGV4cHJlc3NlcyBjbGllbnQncyBk aXMtaW50ZXJlc3QgaW4gc29tZSBvciANCj4gYWxsIG9mIHRoZSByZXNwb25zZXMgZGVwZW5kaW5n IG9uIHRoZSBvcHRpb24gdmFsdWUsIGl0IGlzIGFsc28gdHJ1ZSANCj4gdGhhdCB0aGUgb3B0aW9u IGF1dG9tYXRpY2FsbHkgZXhwcmVzc2VzIGludGVyZXN0IGluIGFsbCBvdGhlciANCj4gcmVzcG9u c2VzIChtYXJrZWQgYnkgMCdzIGluIHRoZSByZXNwZWN0aXZlIHBvc2l0aW9ucykuIFRoZSBjbGll bnQgaXMNCj4gZ29pbmcgdG8gd2FpdCBmb3IgdGhlc2UgcmVzcG9uc2VzIHVwdG8gYSBnaXZlbiB0 aW1lb3V0LiBOb3csIGlmIHRoZSANCj4gc2VydmVyIGJlaGF2aW91ciBpcyBtb2RpZmllZCBsaWtl IHRoaXMgOiAiSSBoYXZlIGNsb3NlZCBteSBkb29yIGZvciANCj4gYWxsIG91dCBnb2luZyByZXNw b25zZS4gKipCVVQqKiwgaWYgSSBzZWUgYSBmZWxsb3cgcmVxdWVzdGluZyB3aXRoIA0KPiBOby1S ZXNwb25zZSBhbmQga2VlcGluZyB3aW5kb3dzIG9wZW4gdG8gc29tZSByZXNwb25zZXMgdGhlbiBJ IGFzc3VtZQ0KPiB0aGF0IHRoaXMgZ3V5IHJlYWxseSBuZWVkcyB0aG9zZSBraW5kIG9mIHJlc3Bv bnNlcy4gSW4gdGhhdCBjYXNlIGxldA0KPiBtZSBiZSBsaW5pZW50IGFuZCBsZXQgbWUgb3BlbiB0 aGUgZG9vciBmb3Igc3VjaCByZXNwb25zZXMuIFRoaXMgDQo+IGZlbGxvdyBtdXN0IGJlIGF2YWls YWJsZSB0byBsaXN0ZW4gdG8gdGhlbSBhcyBwZXIgdGhlIHByZXNjcmliZWQgDQo+IGJlaGF2aW91 ciBpbiB0aGUgTm8tUmVzcG9uc2Ugc3BlY2lmaWNhdGlvbi4iIA0KPiANCj4gTWFuZGF0aW5nIHN1 Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBjbGllbnQgc2lkZSB3aWxsIGJlIGEgYml0IA0K PiBvdXQtb2Ytc3luYyB3aXRoIHRoZSBzcGlyaXQgb2YgdGhlIHNwZWNpZmljYXRpb24uIA0KPiAN Cj4gUmVnYXJkcw0KPiBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4gQXNzb2NpYXRlIENvbnN1bHRh bnQNCj4gU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENCj4gVGF0YSBD b25zdWx0YW5jeSBTZXJ2aWNlcw0KPiBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3Mu Y29tDQo+IFdlYnNpdGU6IGh0dHA6Ly93d3cudGNzLmNvbQ0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFeHBlcmllbmNlIGNlcnRhaW50eS4gICAgICAg IElUIFNlcnZpY2VzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25z DQo+ICAgICAgICAgICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gDQo+IA0KPiANCj4gRnJvbTogICAg ICAgICJEaWprLCBFc2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPiANCj4gVG86ICAgICAgICBB YmhpamFuIEJoYXR0YWNoYXJ5eWEgPGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPiANCj4g Q2M6ICAgICAgICBOZXZpbCBCcm93bmxlZSA8cmZjLWlzZUByZmMtZWRpdG9yLm9yZz4sICJjb3Jl QGlldGYub3JnIFdHIiA8DQo+IGNvcmVAaWV0Zi5vcmc+IA0KPiBEYXRlOiAgICAgICAgMDQvMjIv MjAxNiAwNTo0MyBQTSANCj4gU3ViamVjdDogICAgICAgIFVzaW5nIGRyYWZ0LXRjcy1jb2FwLW5v LXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiANCnJlc3BvbnNlcw0KPiANCj4gDQo+IA0KPiAN Cj4gSGVsbG8gQWJoaWphbiwNCj4gDQo+IGluIG91ciBwcm9qZWN0IHdlIHNlZSBhIGNsZWFyIHVz ZSBjYXNlIG9mIHVzaW5nIHRoZSBOby1SZXNwb25zZSANCj4gT3B0aW9uIHRvICplbmFibGUqIGNl cnRhaW4gcmVzcG9uc2VzIHRoYXQgYXJlIGJ5IGRlZmF1bHQgc3VwcHJlc3NlZC4NCj4gQ29BUCBh bGxvd3Mgc3VwcHJlc3Npb24gb2YgbXVsdGljYXN0IHJlc3BvbnNlcyBieSBkZWZhdWx0LCB3aGlj aCBpcyANCj4gd2hhdCB3ZSB1c2UgZm9yIGEgbGlnaHRpbmcgbXVsdGljYXN0IHVzZSBjYXNlLiBI b3dldmVyIGZvciANCj4gZGlhZ25vc3RpYyB1c2FnZSB3ZSdkIGxpa2UgdG8gZW5hYmxlIHRoZXNl IHJlc3BvbnNlcyBhZ2FpbiB1c2luZyB0aGUNCj4gTm8tUmVzcG9uc2Ugb3B0aW9uIHdoaWNoIGlz IHBlcmZlY3RseSBzdWl0ZWQgZm9yIHRoYXQuIEhvd2V2ZXIsIHRoZSANCj4gZHJhZnQgdGV4dCBj dXJyZW50bHkgb25seSB0YWxrcyBhYm91dCBzdXBwcmVzc2luZyByZXNwb25zZXMgKG5vdCANCmVu YWJsaW5nKS4NCj4gDQo+IEhlbmNlIG15IHJlcXVlc3Q6IGNvdWxkIHdlIG1vZGlmeS9hZGQgc29t ZSB0ZXh0IHRvIHNob3cgdGhhdCBhbHNvIA0KPiB0aGUgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGVu YWJsZSByZXNwb25zZXMgaW4gY2FzZSB3aGVyZSB0aGV5IGFyZSANCj4gbm9ybWFsbHkgKGJ5IGRl ZmF1bHQgLS0gc2VydmVyIGRlY2lzaW9uKSBzdXBwcmVzc2VkPw0KPiBKdXN0IHRvIGNsYXJpZnkg c3VjaCB1c2FnZTsgd2hpY2ggaXMgcXVpdGUgdXNlZnVsIGluIG15IHZpZXcuDQo+IA0KPiByZWdh cmRzDQo+IEVza28NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRp YWwgYW5kIA0KPiBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1l c3NhZ2UgaXMgaW50ZW5kZWQgDQo+IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgDQo+IHlvdSBhcmUgaGVyZWJ5IG5vdGlm aWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgDQo+IHJlcHJv ZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IA0KPiB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIA0KPiBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBh bGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KPiA9PT09PS0tLS0tPT09PT0tLS0t LT09PT09DQo+IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFp bA0KPiBtZXNzYWdlIGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBtYXkgY29udGFpbiANCj4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgDQo+IG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzc2VtaW5hdGlvbiwgdXNlLCANCj4gcmV2aWV3 LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlpbmcgb2YgdGhlIA0KPiBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSANCj4gYW5kL29yIGF0dGFjaG1lbnRz IHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiANCj4geW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCANCj4gcGxlYXNlIG5vdGlmeSB1cyBieSByZXBs eSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCANCj4gaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUgbWVzc2FnZSANCj4gYW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91DQo= --=_alternative 001234D765257FA7_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVza28sPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgZXhpc3RpbmcgdmVyc2lvbiAtMTYgaGFzIHRo ZSBmb2xsb3dpbmcNCnRleHQgaW4gc2VjdGlvbiAyLjEgKHBhZ2UgNSkgOiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1RoZSBzZXJ2ZXIgTVVTVCBzZW5k IGJhY2sgcmVzcG9uc2VzDQpvZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2ggdGhlIGNsaWVudCBoYXMg bm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiZxdW90Ow0KPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbywgdGhhdCB3YXkgdGhlIGNsaWVudCBoYXMgYWN0 dWFsbHkNCmV4cHJlc3NlZCBpdHMgaW50ZXJlc3QgKG9yIHJlcXVlc3QgZm9yIGVuYWJsZW1lbnQp IGluIGFsbCB0aGUgcmVzcG9uc2VzDQpmb3Igd2hpY2ggaXQgaGFzIG5vdCBleHByZXNzZWQgZXhw bGljaXQgZGlzaW50ZXJlc3QuIERvZXMgdGhhdCBoZWxwIHRvDQpjb250cm9sIHRoZSBzcGVjaWFs IHNlcnZlci1zaWRlIGJlaGF2aW91ciBhcyB0aGUgc2VydmVyIGtub3dzIHdoaWNoIGFsbA0KcmVz cG9uc2VzIHRoZSBjbGllbnQgaXMgaW50ZXJlc3RlZCBpbiBhbmQgaXQgTVVTVCBzZW5kIGEgcmVz cG9uc2UgYmFjaw0KPyBJIHNoYWxsIHN1Ym1pdCBhbm90aGVyIHZlcnNpb24gd2l0aCBzb21lIGVk aXRvcmlhbCBjaGFuZ2VzIGJlZm9yZSB0aGUNCmRyYWZ0IGdvZXMgdG8gSUVTRy4gU28gd2UgaGF2 ZSBzb21lIG1vcmUgcm9vbSBmb3IgbW9kaWZpY2F0aW9uLiBJZiB5b3UNCmhhdmUgc29tZSBjb21t ZW50cyBvbiB0aGlzIGluIHRoZSBsaW5lIG9mIHRoZSBkaXNjdXNzaW9uIHdlIGFyZSBoYXZpbmcs DQpwbGVhc2UgbGV0IHVzIGtub3cuIEkgc2hhbGwgd2FpdCBmb3IgeW91ciB2aWV3cyBiZWZvcmUg c3VibWl0dGluZyB0aGUgdXBkYXRlZA0KdmVyc2lvbi4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Bbnl3YXksIGEgc2VwYXJhdGUgZHJhZnQgKG9yLCBw b3NzaWJseSwNCmFuIHVwZGF0ZWQgZ3JvdXBjb21tIFJGQz8pIGlzIGEgZ29vZCBpZGVhLiBOby1S ZXNwb25zZSBhc3N1bWVzIHRoZSB1c3VhbA0KcmVxdWVzdC9yZXNwb25zZSBzeW1hbnRpY3MgYW5k IGl0IG1haW5seSBhZGRyZXNzZXMgdGhlIGNsaWVudCBzaWRlIGJlaGF2aW91cg0KYW5kIGlzc3Vl cy4gQ29uc2lkZXJpbmcgc3VjaCBzcGVjaWFsIGJlaGF2aW91ciBvZiBncm91cGNvbW0gc2VydmVy cywgaXQNCndvdWxkIGJlIGdvb2QgdG8gaGFuZGxlIHNlcGFyYXRlbHkuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XYWl0aW5nIHRvIGhlYXIgZnJvbSB5 b3UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdh cmRzPGJyPg0KQWJoaWphbiBCaGF0dGFjaGFyeXlhPGJyPg0KQXNzb2NpYXRlIENvbnN1bHRhbnQ8 YnI+DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NClRhdGEg Q29uc3VsdGFuY3kgU2VydmljZXM8YnI+DQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0 Y3MuY29tPGJyPg0KV2Vic2l0ZTogPC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy50Y3MuY29tLz48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3d3dy50Y3MuY29tPC9mb250Pjwv YT48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpFeHBlcmllbmNlIGNlcnRhaW50eS4gJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7QnVzaW5lc3MgU29sdXRpb25zPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0NvbnN1bHRpbmc8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90 O0RpamssIEVza28mcXVvdDsgJmx0O2Vza28uZGlqa0BwaGlsaXBzLmNvbSZndDsNCndyb3RlIG9u IDA1LzAyLzIwMTYgMDM6MTA6MjQgQU06PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDtEaWpr LCBFc2tvJnF1b3Q7ICZsdDtlc2tvLmRpamtAcGhpbGlwcy5jb20mZ3Q7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgJmx0O2Fi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyBDYzogJnF1b3Q7Y29yZUBpZXRmLm9yZyBXRyZxdW90OyAmbHQ7Y29yZUBp ZXRmLm9yZyZndDssDQpOZXZpbCBCcm93bmxlZSAmbHQ7cmZjLWlzZUByZmMtPGJyPg0KJmd0OyBl ZGl0b3Iub3JnJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEYXRl OiAwNS8wMi8yMDE2IDAzOjEwIEFNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IFN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24N CnRvICplbmFibGUqIHJlc3BvbnNlczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyA8YnI+DQomZ3Q7IEhlbGxvIEFiaGlqYW4sPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmZ3Q7IE1hbmRhdGluZyBzdWNoIHNlcnZlciBiZWhhdmlvdXIgZnJvbSB0aGUNCmNsaWVudCBz aWRlIHdpbGwgYmUgYSBiaXQ8YnI+DQomZ3Q7IG91dC1vZi1zeW5jIHdpdGggdGhlIHNwaXJpdCBv ZiB0aGUgc3BlY2lmaWNhdGlvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgVGhpcyBpcyBub3QgZnVsbHkgY2xlYXIgdG8gbWUgeWV0IOKApiB0aGUgY2xpZW50DQpkb2Vz IG5vdCBtYW5kYXRlIDxicj4NCiZndDsgYW55dGhpbmcgZnJvbSB0aGUgc2VydmVyOyBpdCBqdXN0 IGV4cHJlc3NlcyBpdHMgaW50ZXJlc3QgKDAtYml0cykNCjxicj4NCiZndDsgYW5kIGRpc2ludGVy ZXN0ICgxLWJpdHMpLiBUaGUgc2VydmVyIGNhbiBhbHdheXMgbm90IHBhcnNlIHRoZSBvcHRpb248 YnI+DQomZ3Q7IChlbGVjdGl2ZSkgb3IgY2hvb3NlIG5vdCB0byBib3RoZXIgYWJvdXQgaXQuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoaXMgZG9lcyBrZWVwIHRoZSBj bGllbnQgd2FpdGluZyBmb3IgYSBwb3NzaWJsZQ0KcmVzcG9uc2UgdGhhdCBuZXZlcjxicj4NCiZn dDsgY29tZXM7IGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGluIHRoZSBnZW5lcmFsIG11bHRpY2FzdCBj YXNlIDogdGhlIDxicj4NCiZndDsgY2xpZW50IGNhbiBuZXZlciBrbm93IGlmIG9yIHdoZW4gYSBy ZXNwb25zZSB3aWxsIGNvbWUsIHRoZSBzZXJ2ZXINCjxicj4NCiZndDsgTUFZIGFsd2F5cyBjaG9v c2UgdG8gbm90IHJlc3BvbmQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTbyB3aGF0IEkg cHJvcG9zZSBpcyB0byB1c2UgdGhlICZxdW90O2luZGljYXRpb24NCm9mIGludGVyZXN0JnF1b3Q7 IHRvIHNwZWNpZmljPGJyPg0KJmd0OyByZXNwb25zZSBjbGFzc2VzIGluIGEgbmV3IHdheTsgbmFt ZWx5IHRvIGVuYWJsZSBjZXJ0YWluIHJlc3BvbnNlIDxicj4NCiZndDsgY2xhc3NlcyB0aGF0IGFy ZSBzdXBwcmVzc2VkIGJ5IGRlZmF1bHQuICZuYnNwO0l0IGp1c3QgaGFwcGVucyB0aGF0DQp0aGUg PGJyPg0KJmd0OyBzYW1lIE9wdGlvbiBzeW50YXggaXMgdmVyeSB3ZWxsIHN1aXRlZCBmb3IgdGhh dCBwdXJwb3NlLiBBIHNlcGFyYXRlDQo8YnI+DQomZ3Q7IGRyYWZ0IGNvdWxkIGJlIHdyaXR0ZW4g Zm9yIHRoYXQgcGVyaGFwcyBpZiB5b3UgdGhpbmsgaXQgZG9lcyBub3QgZml0PGJyPg0KJmd0OyBp biBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gb3IgaWYgaXQgaXMgdG9vIGxhdGUg Zm9yIHRoYXQuDQo8YnI+DQomZ3Q7IFRoZSB3ZSBjYW4gcG9pbnQgdG8gdGhlIHN5bnRheCBvZiB0 aGUgTm8tUmVzcG9uc2UgT3B0aW9uIGFuZCByZS11c2UNCjxicj4NCiZndDsgaXQgY29tcGxldGVs eS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHJlZ2FyZHM8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRXNrbzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJv bTogQWJoaWphbiBCaGF0dGFjaGFyeXlhIFs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzphYmhp amFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzphYmhpamFu LmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl0N Cjxicj4NCiZndDsgU2VudDogRnJpZGF5LCBBcHJpbCAyMiwgMjAxNiAxNzoxNzxicj4NCiZndDsg VG86IERpamssIEVza28gJmx0O2Vza28uZGlqa0BwaGlsaXBzLmNvbSZndDs8YnI+DQomZ3Q7IENj OiBjb3JlQGlldGYub3JnIFdHICZsdDtjb3JlQGlldGYub3JnJmd0OzsgTmV2aWwgQnJvd25sZWUg Jmx0O3JmYy1pc2VAcmZjLWVkaXRvci5vcmcmZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogVXNp bmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUqIHJlc3BvbnNl czwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSGkgRXNrbywgPGJyPg0KJmd0OyBUaGFua3Mg Zm9yIHlvdXIgbWFpbC4gPGJyPg0KJmd0OyBGaXJzdCBvZiBhbGwgbGV0IG1lIGp1c3QgYnJpbmcg dGhpcyB0byB5b3VyIChhcyB3ZWxsIGFzIHRoZSBtYWlsaW5nDQo8YnI+DQomZ3Q7IGxpc3Qncykg bm90aWNlIHRoYXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpczogJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGNzLWNv YXAtbm8tcmVzcG9uc2Utb3B0aW9uLTE2LnR4dCI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0 aW9uLTE2LnR4dDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJy Pg0KJmd0OyBUaGlzIHZlcnNpb24gJnF1b3Q7b2ZmaWNpYWxseSZxdW90OyBjbG9zZXMgdGhlIHRl Y2huaWNhbCByZXZpZXdzIGFuZA0KaXMgd2l0aCA8YnI+DQomZ3Q7IHRoZSBSRkMgZWRpdG9yIHRo cm91Z2ggdGhlIElTIHRyYWNrLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTm93IGNvbWluZyB0byB5 b3VyIHVzZSBjYXNlIChhbmQgaW5kZWVkIGl0IGlzIGFuIGludGVyZXN0aW5nIG9uZSkNCjxicj4N CiZndDsgb25lIHRoaW5nIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIGlzIHRoYXQgdGhlIE5vLVJl c3BvbnNlIG9wdGlvbiB3YXM8YnI+DQomZ3Q7IGRlbGliZXJhdGVseSBkZXNpZ25lZCBub3QgdG8g bWFuZGF0ZSBhbnl0aGluZyBmb3IgdGhlIHNlcnZlciBzaWRlDQo8YnI+DQomZ3Q7IG1haW5seSB0 byBlbnN1cmUgdGhhdCBpdCBkb2VzIG5vdCBkaXNydXB0IHRoZSBtYW55IHVzZWZ1bG5lc3Mgb2Yg dGhlPGJyPg0KJmd0OyB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIHN5bWFudGljcy4gVGhlIGRyYWZ0 IGFsbCBhbG9uZyBkZWFscyB3aXRoIHRoZTxicj4NCiZndDsgcmVxdWVzdGluZyBjbGllbnQncyBi ZWhhdmlvdXIgYW5kIGl0cyBleHByZXNzaW9uIG9mIGludGVyZXN0IHRvIHRoZQ0KPGJyPg0KJmd0 OyBzZXJ2ZXIuIFNpbmNlIHRoaXMgb3B0aW9uIGlzIGVsZWN0aXZlIHdlIGxlYXZlIGl0IHVwdG8g dGhlIHNlcnZlcg0KPGJyPg0KJmd0OyBpbXBsZW1lbnRhdGlvbiB0byBob25vdXIgdGhlIGNsaWVu dCdzIGludGVyZXN0LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTm93LCBhcyBwZXIgdXN1YWwgcmVx dWVzdC9yZXNwb25zZSBzeW1hbnRpY3MgdGhlIHJlc3BvbnNlcyBhcmUgPGJyPg0KJmd0OyBhbHdh eXMgZW5hYmxlZC4gVGhlIGJlaGF2aW91ciBpbiBncm91cGNvbW0gc2VydmVyIGluIHRlcm1zIG9m IDxicj4NCiZndDsgc3VwcHJlc3NpbmcgdGhlIHJlc3BvbnNlcyBvbiBpdHMgb3duIGlzIHNvbWV0 aGluZyBzcGVjaWFsIGFuZCwgPGJyPg0KJmd0OyBnZW5lcmFsbHkgc3BlYWtpbmcsIHRoZSBjbGll bnRzIGFyZSBub3QgYXdhcmUgb2Ygc3VjaCBzcGVjaWFsIGJlaGF2aW91ci4NCiZuYnNwOyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgU28sIGl0IHdvdWxkIGJlIGp1c3RpZmllZCB0byBoYW5kbGUgdGhl IHNpdHVhdGlvbiBhdCB0aGUgc2VydmVyJ3MNCjxicj4NCiZndDsgZW5kLiBIZXJlIGlzIHRoZSBp ZGVhOiA8YnI+DQomZ3Q7IFdoaWxlIE5vLVJlc3BvbnNlIGlzIHRvIGV4cHJlc3NlcyBjbGllbnQn cyBkaXMtaW50ZXJlc3QgaW4gc29tZSBvcg0KPGJyPg0KJmd0OyBhbGwgb2YgdGhlIHJlc3BvbnNl cyBkZXBlbmRpbmcgb24gdGhlIG9wdGlvbiB2YWx1ZSwgaXQgaXMgYWxzbyB0cnVlDQo8YnI+DQom Z3Q7IHRoYXQgdGhlIG9wdGlvbiBhdXRvbWF0aWNhbGx5IGV4cHJlc3NlcyBpbnRlcmVzdCBpbiBh bGwgb3RoZXIgPGJyPg0KJmd0OyByZXNwb25zZXMgKG1hcmtlZCBieSAwJ3MgaW4gdGhlIHJlc3Bl Y3RpdmUgcG9zaXRpb25zKS4gVGhlIGNsaWVudA0KaXM8YnI+DQomZ3Q7IGdvaW5nIHRvIHdhaXQg Zm9yIHRoZXNlIHJlc3BvbnNlcyB1cHRvIGEgZ2l2ZW4gdGltZW91dC4gTm93LCBpZiB0aGUNCjxi cj4NCiZndDsgc2VydmVyIGJlaGF2aW91ciBpcyBtb2RpZmllZCBsaWtlIHRoaXMgOiAmcXVvdDtJ IGhhdmUgY2xvc2VkIG15IGRvb3INCmZvciA8YnI+DQomZ3Q7IGFsbCBvdXQgZ29pbmcgcmVzcG9u c2UuICoqQlVUKiosIGlmIEkgc2VlIGEgZmVsbG93IHJlcXVlc3Rpbmcgd2l0aA0KPGJyPg0KJmd0 OyBOby1SZXNwb25zZSBhbmQga2VlcGluZyB3aW5kb3dzIG9wZW4gdG8gc29tZSByZXNwb25zZXMg dGhlbiBJIGFzc3VtZTxicj4NCiZndDsgdGhhdCB0aGlzIGd1eSByZWFsbHkgbmVlZHMgdGhvc2Ug a2luZCBvZiByZXNwb25zZXMuIEluIHRoYXQgY2FzZSBsZXQ8YnI+DQomZ3Q7IG1lIGJlIGxpbmll bnQgYW5kIGxldCBtZSBvcGVuIHRoZSBkb29yIGZvciBzdWNoIHJlc3BvbnNlcy4gVGhpcyA8YnI+ DQomZ3Q7IGZlbGxvdyBtdXN0IGJlIGF2YWlsYWJsZSB0byBsaXN0ZW4gdG8gdGhlbSBhcyBwZXIg dGhlIHByZXNjcmliZWQgPGJyPg0KJmd0OyBiZWhhdmlvdXIgaW4gdGhlIE5vLVJlc3BvbnNlIHNw ZWNpZmljYXRpb24uJnF1b3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTWFuZGF0aW5n IHN1Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBjbGllbnQgc2lkZSB3aWxsIGJlIGEgYml0 DQo8YnI+DQomZ3Q7IG91dC1vZi1zeW5jIHdpdGggdGhlIHNwaXJpdCBvZiB0aGUgc3BlY2lmaWNh dGlvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHM8YnI+DQomZ3Q7IEFiaGlqYW4gQmhh dHRhY2hhcnl5YTxicj4NCiZndDsgQXNzb2NpYXRlIENvbnN1bHRhbnQ8YnI+DQomZ3Q7IFNjaWVu dGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhPGJyPg0KJmd0OyBUYXRhIENvbnN1 bHRhbmN5IFNlcnZpY2VzPGJyPg0KJmd0OyBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0 Y3MuY29tPGJyPg0KJmd0OyBXZWJzaXRlOiA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHA6Ly93d3cu dGNzLmNvbS8+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LnRjcy5jb208L2ZvbnQ+PC90dD48 L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBFeHBlcmllbmNlIGNlcnRhaW50eS4gJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgRnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7 RGlqaywgRXNrbyZxdW90OyAmbHQ7ZXNrby5kaWprQHBoaWxpcHMuY29tJmd0Ow0KPGJyPg0KJmd0 OyBUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWJoaWphbiBCaGF0dGFjaGFyeXlhICZs dDthYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSZndDsNCjxicj4NCiZndDsgQ2M6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO05ldmlsIEJyb3dubGVlICZsdDtyZmMtaXNlQHJmYy1lZGl0 b3Iub3JnJmd0OywNCiZxdW90O2NvcmVAaWV0Zi5vcmcgV0cmcXVvdDsgJmx0Ozxicj4NCiZndDsg Y29yZUBpZXRmLm9yZyZndDsgPGJyPg0KJmd0OyBEYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDswNC8yMi8yMDE2IDA1OjQzIFBNIDxicj4NCiZndDsgU3ViamVjdDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7VXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uDQp0 byAqZW5hYmxlKiByZXNwb25zZXM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBIZWxsbyBBYmhp amFuLDxicj4NCiZndDsgPGJyPg0KJmd0OyBpbiBvdXIgcHJvamVjdCB3ZSBzZWUgYSBjbGVhciB1 c2UgY2FzZSBvZiB1c2luZyB0aGUgTm8tUmVzcG9uc2UgPGJyPg0KJmd0OyBPcHRpb24gdG8gKmVu YWJsZSogY2VydGFpbiByZXNwb25zZXMgdGhhdCBhcmUgYnkgZGVmYXVsdCBzdXBwcmVzc2VkLjxi cj4NCiZndDsgQ29BUCBhbGxvd3Mgc3VwcHJlc3Npb24gb2YgbXVsdGljYXN0IHJlc3BvbnNlcyBi eSBkZWZhdWx0LCB3aGljaCBpcw0KPGJyPg0KJmd0OyB3aGF0IHdlIHVzZSBmb3IgYSBsaWdodGlu ZyBtdWx0aWNhc3QgdXNlIGNhc2UuIEhvd2V2ZXIgZm9yIDxicj4NCiZndDsgZGlhZ25vc3RpYyB1 c2FnZSB3ZSdkIGxpa2UgdG8gZW5hYmxlIHRoZXNlIHJlc3BvbnNlcyBhZ2FpbiB1c2luZyB0aGU8 YnI+DQomZ3Q7IE5vLVJlc3BvbnNlIG9wdGlvbiB3aGljaCBpcyBwZXJmZWN0bHkgc3VpdGVkIGZv ciB0aGF0LiBIb3dldmVyLCB0aGUNCjxicj4NCiZndDsgZHJhZnQgdGV4dCBjdXJyZW50bHkgb25s eSB0YWxrcyBhYm91dCBzdXBwcmVzc2luZyByZXNwb25zZXMgKG5vdCBlbmFibGluZykuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEhlbmNlIG15IHJlcXVlc3Q6IGNvdWxkIHdlIG1vZGlmeS9hZGQgc29t ZSB0ZXh0IHRvIHNob3cgdGhhdCBhbHNvDQo8YnI+DQomZ3Q7IHRoZSBvcHRpb24gY2FuIGJlIHVz ZWQgdG8gZW5hYmxlIHJlc3BvbnNlcyBpbiBjYXNlIHdoZXJlIHRoZXkgYXJlDQo8YnI+DQomZ3Q7 IG5vcm1hbGx5IChieSBkZWZhdWx0IC0tIHNlcnZlciBkZWNpc2lvbikgc3VwcHJlc3NlZD88YnI+ DQomZ3Q7IEp1c3QgdG8gY2xhcmlmeSBzdWNoIHVzYWdlOyB3aGljaCBpcyBxdWl0ZSB1c2VmdWwg aW4gbXkgdmlldy48YnI+DQomZ3Q7IDxicj4NCiZndDsgcmVnYXJkczxicj4NCiZndDsgRXNrbzxi cj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNv bmZpZGVudGlhbCBhbmQNCjxicj4NCiZndDsgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGlj YWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIDxicj4NCiZndDsgc29sZWx5IGZvciB0 aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LA0K PGJyPg0KJmd0OyB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRp bmcsIGRpc3NlbWluYXRpb24sIG9yDQo8YnI+DQomZ3Q7IHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1l c3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIDxicj4NCiZndDsgdW5sYXdm dWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0 IHRoZQ0KPGJyPg0KJmd0OyBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwg Y29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA9PT09PS0tLS0tPT09PT0tLS0tLT09PT09PGJyPg0KJmd0OyBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWw8YnI+DQomZ3Q7IG1lc3Nh Z2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIDxicj4NCiZndDsgY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgPGJyPg0KJmd0OyBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgPGJyPg0K Jmd0OyByZXZpZXcsIGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJy Pg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSA8YnI+ DQomZ3Q7IGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgPGJyPg0KJmd0OyB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIDxicj4NCiZndDsgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBo b25lIGFuZCA8YnI+DQomZ3Q7IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhl IG1lc3NhZ2UgPGJyPg0KJmd0OyBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3U8L2ZvbnQ+ PC90dD4NCg== --=_alternative 001234D765257FA7_=-- From nobody Mon May 2 04:09:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF0D12B052 for ; Mon, 2 May 2016 04:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHonmgWLkKD7 for ; Mon, 2 May 2016 04:09:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2565712B04E for ; Mon, 2 May 2016 04:09:43 -0700 (PDT) Received: from [192.168.10.140] ([213.210.38.194]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lm3H7-1bWFQw3yF7-00ZdH2; Mon, 02 May 2016 13:09:40 +0200 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , Alexey Melnikov References: <52F80F7B-FD08-4C17-8F9C-66BFACEBBF81@isode.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57273572.2030002@gmx.net> Date: Mon, 2 May 2016 13:09:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1lTPi0TKH5gqcU4MqQEitBBCvfurKTK52" X-Provags-ID: V03:K0:IW9PebJ22WbOV9MNZ6Y6m8RHlK3KdV57QNDvCIGGtGGweMSxpBJ GzIU0mzKDQ4yudjFxE8Ts3MCQFJqq9WW3Ju2VZ8a9AY6P/JR/JYlqGBet7j3DLyQuJ91b+T nmdgRM4SxT2jyFy+F5aApnlKqgXs5Uw9Zqfiohlv2iEHffa0o5BQdBZUL3tSDzkmsJ6Z1xX NPlMKXFBuIdV3AF8ACtQA== X-UI-Out-Filterresults: notjunk:1;V01:K0:vSu37o+Ebyo=:FwIyLfvVZshpoCqKf05rIK fZuDQA50Bbx0yuvVIwoMEfDqv2FADPugylfZtsHW6UN6s8vF2oVLRO4ItaCka4goEznN2KZh2 wgthEiBwl8ePkf06vx1/XrpFKWYvxx2iIjAil7VQpM9QRloHu0GNsigrVPuNOb0IfL+3z7FZn 0inJiWSVxN0yNmcv01sjkQk7NWNP1KaHd7ucjhPFH/IEqCb5OHXr7BSgZzHpqk5IgQwv0c9Ju OiRFsZgNyfFN4UgwN7aypaurGMMRAzJleyg8i5QMftOFfim31krQmaqf2aw3wPw+yOEFIExTN jdZU7hW9gP24IMHgproasYSU1jMW1zAH2G9q/A7T4q22tvUvxYhp9c+YPvo1hillLFCjCztZ2 kVyW3XdMD8RWV4YdcTIecJKEER6Dff9JaSI8m0dg7ZTCbRXngSjeTHVjn4oXjcACfN0sUygxj s4RRQYcKpL4Hy5hlq0gBWnnvLUE1l4g5bekuLb4NECl348NuybnoeDvuplopIfSx5ptio5TZo k2Ls/UMsQqxoLKX+XRwqoCTZzSKHMGYCxTm1lQBERp8wU7QVAw91nMWUbOO1hc1aPKlnmjxVg 6t/3FrH7x0+PWq4ZRr6tGOv31Fx2cy0aiSfg+2/zOxUv6r0jv3rBhW7icQjSPdUfxB1oJ2sB6 0UyuxywT9J/VuhoQ9AwPWw/e3DDz6hphn7aREG1+UhVOsljweJ9pLw3lI4cCaK547Q4wUnAdi QmAL2v11nwuid+KQ6Heea0WamfDF1Uq8NsET3cSL0DJFFqRsNV6SaSclZyA= Archived-At: Cc: "core@ietf.org" Subject: Re: [core] New co-chair for CORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 11:09:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1lTPi0TKH5gqcU4MqQEitBBCvfurKTK52 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Congratulation for finding a highly qualified person so quickly! I am looking forward to the progress in the group On 04/28/2016 11:55 AM, Jaime Jim=E9nez wrote: > Hi, >=20 > Thanks, very happy to be aboard and looking forward to help on completi= ng the work. >=20 > Ciao! > - - Jaime Jimenez >=20 >> On 28 Apr 2016, at 12:47, Alexey Melnikov = wrote: >> >> Thank you to Jaime Jim=E9nez for agreeing to co-chair CORE together wi= th Carsten. >> I am looking forward to reviewing more CORE documents for IESG. >> >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --1lTPi0TKH5gqcU4MqQEitBBCvfurKTK52 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXJzVyAAoJEGhJURNOOiAtBAUH/0fDD515v8aq0EdA50WOU5eW iP4jryZY+cBFafOOlHcEMPPwzbXi/Q+IzpKTTybRzTe38+dGAZTqqMqN93CHZwKj 3a4gRQJHozf6xJyeeUYARMnXgJDnw8aY2TMNRJpAaE9b3D7hShU5/vgneDO6JlA2 EcF7TPy+PayF7NNXZoKwoduDIydRWIGxcahhhHPylovtTzxQCUAOsJQ3Cxf/Vr5W W9vPpuz9h7otGnrGOHMQ2Kk9dr/MUYtEHDLPNEwBL25lo7laYHPcIMbZeE0miU7C Ge8PPk0uIGeKuXOKX+69ZTfFySKmweplpAh5gQguKJE9iDOYhiSEuGOqN6XhIzQ= =y2AH -----END PGP SIGNATURE----- --1lTPi0TKH5gqcU4MqQEitBBCvfurKTK52-- From nobody Mon May 2 09:20:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921BB12B04C; Mon, 2 May 2016 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqZCZlB4n2VK; Mon, 2 May 2016 09:20:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D6E12D0A1; Mon, 2 May 2016 09:20:44 -0700 (PDT) Received: from localhost ([::1]:34315 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1axGaM-0002Ag-W1; Mon, 02 May 2016 09:20:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Mon, 02 May 2016 16:20:38 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/408 Message-ID: <065.9de481af4bd4a983e24dbcb906a41c02@trac.tools.ietf.org> X-Trac-Ticket-ID: 408 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, david.navarro@ioterop.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 Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org Resent-Message-Id: <20160502162045.05D6E12D0A1@ietfa.amsl.com> Resent-Date: Mon, 2 May 2016 09:20:44 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #408 (coap-tcp-tls): CoAP over TCP Length Format (New) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.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 2016 16:20:46 -0000 #408: CoAP over TCP Length Format (New) I am currently attending the OMA Device Management (DM) working group meeting. During the presentation of the CoAP over TCP / TLS document David Navarro from IoTerop asked whether we had thought about re-using the existing CoAP header (with a new version number) to ensure larger similiary between the CoAP over UDP and the CoAP over UDP transport. Below is his message; I thought it is worthwhile to discuss it. --------- From: David Navarro [mailto:david.navarro@ioterop.com] Sent: 02 May 2016 17:36 To: Hannes Tschofenig Subject: Hi Hannes, For the sake of compatibility between CoAP/UDP and CoAP/TCP, what about this format ? In red the changes from RFC7252. {{{ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| L | TKL | Code | Payload and Options Length... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }}} Figure 7: Message Format The fields in the header are defined as follows: Version (Ver): 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this specification MUST set this field to 2 (10 binary). Other values are reserved for future versions. Messages with unknown version numbers MUST be silently ignored. Length Type (L): 2-bit unsigned integer. Indicates the length of the variable-length Length field: 00: no Length field 01: 1 byte Length field 10: 2 bytes Length field 11: 4 bytes Length field Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error. Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits), documented as "c.dd" where "c" is a digit from 0 to 7 for the 3-bit subfield and "dd" are two digits from 00 to 31 for the 5-bit subfield. The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.) As a special case, Code 0.00 indicates an Empty message. In case of a request, the Code field indicates the Request Method; in case of a response, a Response Code. Possible values are maintained in the CoAP Code Registries (Section 12.1). The semantics of requests and responses are defined in Section 5. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core-coap- Hannes.Tschofenig@gmx.net | tcp-tls@ietf.org Type: protocol defect | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: core From nobody Mon May 2 12:55:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894E212D518 for ; Mon, 2 May 2016 12:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nt0FJ3XpAi4 for ; Mon, 2 May 2016 12:55:29 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183B312D4FF for ; Mon, 2 May 2016 12:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eBiqYQcxOK6rjOous67DqOMJraAbp8yAwpEH65tWMTM=; b=FhmMCFHz1um0b4g59C3f4o9z96LXxpvD2blUvOcXIiTNecqg0A40EO3FIBv+mg8Np0fPS7gIAcMsjoGJC4ziWfQh9pmvJcU2rQq3S/CrluQiIqrUB6nmcDBojsCDoTFE6kaOrcVL4clrTBZ/WRpWbJeLcPFLwCMlIDb1aRAc6s8= Received: from DB5PR04CA0019.eurprd04.prod.outlook.com (10.164.34.157) by DB4PR04MB363.eurprd04.prod.outlook.com (10.141.236.151) with Microsoft SMTP Server (TLS) id 15.1.485.9; Mon, 2 May 2016 19:55:03 +0000 Received: from AM1FFO11FD035.protection.gbl (2a01:111:f400:7e00::141) by DB5PR04CA0019.outlook.office365.com (2a01:111:e400:598c::29) with Microsoft SMTP Server (TLS) id 15.1.485.9 via Frontend Transport; Mon, 2 May 2016 19:55:02 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; tcs.com; dkim=none (message not signed) header.d=none;tcs.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by AM1FFO11FD035.mail.protection.outlook.com (10.174.64.224) with Microsoft SMTP Server (TLS) id 15.1.477.4 via Frontend Transport; Mon, 2 May 2016 19:55:02 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0171.MGDPHG.emi.philips.com (141.251.190.19) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 2 May 2016 19:55:01 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0477.014; Mon, 2 May 2016 19:55:02 +0000 From: "Dijk, Esko" To: Abhijan Bhattacharyya Thread-Topic: Using draft-tcs-coap-no-response-option to *enable* responses Thread-Index: AdGcj/YQCrN+XzqqSpmFRQBEAJ7w2AAGgNwAAdGkGKAADDQpgAAiU7Hw Date: Mon, 2 May 2016 19:55:01 +0000 Message-ID: References: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.73.250.218] Content-Type: multipart/alternative; boundary="_000_dcc875e1f79c461c9293e37107a04a9eHE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(2980300002)(428002)(189002)(55904004)(85714005)(199003)(374574003)(52084003)(52314003)(377454003)(2900100001)(24736003)(5003600100002)(16601075003)(19625215002)(19625305001)(9326002)(189998001)(10400500002)(2906002)(15975445007)(16796002)(101416001)(92566002)(108616004)(19580395003)(230783001)(2950100001)(19580405001)(5004730100002)(93886004)(110136002)(5890100001)(1220700001)(86362001)(6806005)(5008740100001)(76176999)(84326002)(105586002)(66066001)(19617315012)(33646002)(11100500001)(106466001)(87936001)(54356999)(50986999)(81166005)(16236675004)(4326007)(6116002)(790700001)(512874002)(19300405004)(3846002)(102836003)(586003)(8936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR04MB363; H:011-smtp-out.Philips.com; FPR:; SPF:None; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD035; 1:UJ7G4sS7rvM+n7lciEeDIQ0CG2OAge6Rb1IpAH3fy3YviEL2kkJU5Oi1o/7TQT1dl+B29wPkFQgY8KUVsIAk2YzuGwcsZ2LV14vbjFu2qfvmRxMkvXUYXqNcOKu8WSsmEpP7HCzUZeLnWU46RTf601X8Hlr1zBvhJ9b19u5V/+ocJX+iClX/agBU2yC39FKfkq5RysRzRLiUUpptpLlM5GfgnCD4JaojHbkxVsJK5kgHy932k1AfEpHDF5D7FY194Fl1XyTadOe9Wy447cLNKOM3/YqUeaROoXKnZlzH08XWNT47kVDZ6sUbNy2zwE1TyPD+qOzTUrLlnlqwBeSiNVMe4mXfiFQXFkz6kOWpoOTplbuAOzlw5GfEtVasi4MPF6ZtZZVDCk8khcLcaw2wQZduKx+paoQwV6YOa4ZPnG4IcKImn4EO1sqAHlpETkeD X-MS-Office365-Filtering-Correlation-Id: 16b95d12-3f3b-4f75-7dff-08d372c3a69b X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 2:R6q9ozT1k7isnKDtbGxNtB3IBKQijARuMZh9nZO3OG6AapDXWWyAvsPHmM+7d1HzExbbYw0K1O7+tIxr/3WC6JZAi2lCIf9crOKH4RQ0WzRzUMZOXIJ9ZwUj+KedG8WDz30prqaVvYWTO9YtP77uxNbuhwqx0+pqaGkx7sjA+kERzxo5PIzbIvxLoUpY5rI3; 3:YwfistR1NkSDh0K75MqXBuvjhjguwo93l8WvK75vTEcE70LhsZj6kN4tcnRYrSxiDcqw4qEeSmxUcTjgAFNKF0xv0/JbRN/u9kpaLkwYuW+teYAuwkYQAboxavBavDoFyVBOFl7+9M/9LAdihhCs/rqQ1mF4pTIG871vuSiP9nKzoY1d2TDmdDM9jw4m79F+jV9THaWUf88vuVMxYyw0Q8aaDom2dkOiZv+DmVd9Vh8=; 25:u2aqWftKvxlrRCPSRKhaXEmBc8Bq9XKer88SDi26Ccp2b2CyX8cf2LS82ZMQO6QAPHkol5gcBlyn1FKuRUEENLDznVNxTpXGuMtNqnaWwbfWI9m05OF/QLks9jY8MN+b9FfmBKaCCnSAqVG2nfVLRVfzhbreeyhjOMx79JvtGmxNmqLPH/sxhanqLfHqm2R9DwsMbuKBDt7wOPVMcZG112aPPRWwYrXREau8udrfdkmUyzRXnRWqjG/07Sd5Zyg+QQGNwcpNyQC56obGhzm40ep44gJznx/NXMtRWz3l9NvvL0cVLDGvS7LVR7oyl1yjWTvHhaCqV4FSbWQj8KgUkALPoRLWN+yMjMgoZZdGI10ukwUHS7Zfd+jcfHNHg9Qr82vUAJyb0IWe4GDPPDp0oTapPbiO+NJmdjEosGXgI/b61viSTuo2FSbmGrrZPJca X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB363; X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 20:YbY9ZDbrcPmYqARgUIeqWKpoEvY/7A38V76r87WlqhY5rliSzrtw+v87sTYNpu32F95OaaFk0SGtjCUwUSb0qaVUapWGF0ATMBG000iaj+POXsuSzJj+FhWWFxNZdLuzZAGUs/LGaBR0bBHsq/eMR4kOjBrPP1MM5VCBOa2lwyIVH1yx7ZNobhD5hCosItKPFgix5dskiQU5JjWuZwZ5w9tlxaCwse7WYHNcrzlvVOKM33GJkHw0OwHlA5Q+A/8bkiRDgVPZBJOUsMAF7Xnpi5zBHwePb0+vvaMHGKc2EHUPbPIE1patEFn79jOF8zliL7V+uWv5P+0tZoHNvwWN1je8INqslYq4uFD7sPVE1YW8oPhdHXdkNT60KVuKwY44LQEjE0Ec2zJfSlVpwlZ0D1+sWE0s4uCegn3R07b6L5JZGSmeLnhJoy56biUx7vHPYRLvsjv/9+fJcim28Y5YIzs0LMcx/fWNoGiLq3gRRzXCpKiZZQ+58PgUFvSUqASC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(114017886912203)(220618547472400); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521096)(601004)(2401047)(8121501046)(13018025)(5005006)(13016025)(10201501046)(3002001)(6055026); SRVR:DB4PR04MB363; BCL:0; PCL:0; RULEID:; SRVR:DB4PR04MB363; X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 4:QYxLxmopoIUMa7NAeEA24kVvadf3YYELEaaz0pjVhOcyyMbr0yAYsy+Pku4CwLo++2U3DjJIqWnofm0hbWuoMrhZ9RiJe9yNS3CxToA4pO1LkulfSq7DOimge01rF8YC0bsFt/+LglIO9SX4kvXgIukCu3essRLUnIUp8esXCSTBn1854UCV0Cl9cUYWA9XAEiiOl+2fAabtv8ab9rJYb8DOapEEJdQWfYh3+UxaH4xOD9N28xljckfRfObyBzo6E+x60zqrY/5AFyPKeizVbf7aBCW//1Ou2PnQ3LoZJ/eYva30jK4ZlmqfymTgK0xZN7dUQhffcl8lcGCMjDIRAiSykyEeVpGi7QayBgi1vRMgo0gRyINq4b3eEsLVvPhaPtuFcTcOEP43S3DJzoVp4zS7QF5AtRqMPvuorR9niYXRqSe10EWMdAYSxbyLKImSG7hPN5AXpbdpfEAfN3UjKCrgnRahNHX6E7IJqvY5qiZvgfWqQx5e/UilfIT3qUCxoQxmCdhEKPrvPp3JmUKkGg== X-Forefront-PRVS: 0930AAFAD9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB4PR04MB363; 23:p6a1wJO6d1ZMYaBJFCZP7uw2Wk+W/BqBdI0ravDlFT?= =?us-ascii?Q?dLANHuhHn+e3Lz4xlDUHJ9fnMjXFWzCmo5WkTc7tN74t0UA+cEkKqRTwayv1?= =?us-ascii?Q?+LzjZiKIug1C/xEUmeYk+MePlO3iQLjmBwUv2/LPCUVJEOtIoikAjlppADtD?= =?us-ascii?Q?Lf8gynciX7uxNLI02xgsP9O4yzziaBNFefNxFfkKJrUUlReQZXnQEHOkgQ/b?= =?us-ascii?Q?fXys/v7RYtcA42NmfRwZ0l2YMGv4YsB8Q2CEcbp9VUE7Cf40QqQ8Mor1hQed?= =?us-ascii?Q?3FulzUxjX8k/nA/Mw9FB6EWLtlgJKg1OYapWOGFb4fOrAgPEJe1zb5T8QADn?= =?us-ascii?Q?nDNKKtm0GxpH4uJi5JlXMYV/+mywtgld4bFbbnELo0m01h42siTvOG8kWlcC?= =?us-ascii?Q?uajDKUnl++S1JSoA6JftnpUCMur7WVpyGD6xjoVW0BqZjTEhH4C+ZT1JgWzO?= =?us-ascii?Q?zfoVnbFfi/TXaACiot5L4DgSjSxkXRVzjw63f9tk28LOle76nS6WH+8jwZwv?= =?us-ascii?Q?di++YUY6nsl3XaxHTkPS9FenOIvj1BnGiCIaSXZIcPSiDtdDjvrqgaUddp6Y?= =?us-ascii?Q?hA+Xl3//eGTzV2L1I3OL9uxOHtb0F5La6g9bVQN12YX5E1JCqw5BDVOgef7+?= =?us-ascii?Q?Pg+V0KfoCz/B8wcrBAZYoE4Xz9t/ORgY2KAe6+vl83KRsiG6qLHN9o2mpzDE?= =?us-ascii?Q?3EZMuzLHCH87R5pWS0DNZLzjjx4mbqIDhPszOXuWNPq/zCucOCkSQ0loBoPg?= =?us-ascii?Q?zE2NTmPHnQKUdvQZy2D6ZFILVwRUKpD7xITYG1JgOLxRd/MpXu/fiah88Wy5?= =?us-ascii?Q?KkbPa/3cjRrb6pH9UoniFoQv99i2RFJE4GAcAvzipyqCLpWW7OSx1OL/21NS?= =?us-ascii?Q?C3TqMpPUuJAsveWw1xtnXjNUcWbBJnyL5rAvNyFUXUv5kRNxEy9D6zudTvD0?= =?us-ascii?Q?Jq4iKMvMKkB7CzJhiSqIVlWYDB7Q0mDwZEOkKIL/TiJ59VaDxqnyXTmHgQHa?= =?us-ascii?Q?vxVpeUxkKw5arihtwOhn5dMNGupnkxPtyIPplQCV1DxwwFKvpGwzNTX2lv0+?= =?us-ascii?Q?VbtINydnSkyoiX1psONdgzT3Hhdd0/rQCD4Av1CH0GjvX5Kq94PVi+HyvAAe?= =?us-ascii?Q?LsYxy7tn5nVeHjHz+hmCjoExXRYoF9NZfaD1+RCYiIH6uynrxd6WR4D/bKha?= =?us-ascii?Q?xDA1A7QC8FMoWnCmTiyhk81sLeDDJjsUp7HEPg3P6Mia1Egnm5tk7wRfHIPd?= =?us-ascii?Q?UdshlSyvV3Sy2XL7LfwqqijKWeFCVwSTGs4xA93NnZq3oI3uXQIpEfWsHs1q?= =?us-ascii?Q?q+mIeAPpwIp9uCuoUY0EH8+Ut1hx3g64qXPxqHm2Lae8YV3zSmJj6L5Q1nb5?= =?us-ascii?Q?ac3rtWQvTvWSdpwOeHlXBwqkftur9HDheQhrsPZm4SnnovZjYgRPd/eMupOP?= =?us-ascii?Q?mn6H5CHm/F3MYWdrupfr18TRC8bSQpY8IbvmmsCU5paFogvZDXi0YK2TD+Rp?= =?us-ascii?Q?BlY4X36+mB8DDYTrLLLXp1g7Vzx4kZfEu6+319NkG4x2fNnKcCTuAVBBauBF?= =?us-ascii?Q?pNmWuids/mmE4xfuGIRprHV2e5BTmGO79Uh0D6Rb9E9uUgBvCI0aJxOSGw0X?= =?us-ascii?Q?8+YvFp4JlcdgYyLjrKXQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 5:TGxSsmiwx1BN2HO9/rfA3VSNwAc+M2P/zx2bNf1fXt2W1qksM4yllPvc2BWBJvCNqINdxE+K472rQN3kP48LXCntEh/Wm9y5xPVpZWllzgXYObWJ+HDjLvj9B2tIRt73L4KbLRVEjd/LXHy4Z/j9xg==; 24:JICFfxj6owoqZQISfUAAymJYlPl0aM6guysFEjPHtk+4vpn0pVecK4o5/wfHVK1m/nYL7n+HiJf/qCp+aVOCg/OSubxsM9MNj3BUfeB5YPQ=; 7:SfANVubJIi+beCh5BGYlgqYOAo2allYr/eoKMzUeNRyjzWg6OMarefokAYo0zyGSB0XtLSX39j6Yf3EUKiegZpjV7S0hGmW+8IsECL4BoEPCusi5/LloHPtICAlYP8tKLvi7cw78e9/DMLvQEuZpx4ol7h1i5z7U8fLRG8JPUKkTPI2yX+ZUnpZRG+qBUBhO SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2016 19:55:02.7989 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB363 Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 19:55:33 -0000 --_000_dcc875e1f79c461c9293e37107a04a9eHE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4gIlRoZSBzZXJ2ZXIgTVVTVCBzZW5kIGJhY2sgcmVzcG9uc2VzIG9mIHRoZSBjbGFz c2VzIGZvciB3aGljaCB0aGUgY2xpZW50IGhhcyBub3QgZXhwcmVzc2VkIGFueSBkaXMtaW50ZXJl c3QuIiAtDQpUaGlzIGNvdmVycyBwYXJ0IG9mIG15IHVzZSBjYXNlOyBob3dldmVyIGl0IGlzIG5v dCBjbGVhciBob3cgdGhpcyAiTVVTVCIgaW50ZXJhY3RzIHdpdGggdGhlICJNQVkgc3VwcHJlc3Mi IG9mIFJGQyA3MjUyIGZvciB0aGUgbXVsdGljYXN0IGNhc2UuIENhbiB0aGUgc2VydmVyIHN0aWxs IGRlY2lkZSB0byBzdXBwcmVzcyB0aGUgbXVsdGljYXN0IHJlc3BvbnNlIGV2ZW4gaWYgdGhlIE5v LVJlc3BvbnNlIE9wdGlvbiBzZW50IGJ5IHRoZSBjbGllbnQgc2F5cyBub3QgdG8/IFRoaW5raW5n IGFib3V0IGl0LCBpdCB3b3VsZCBiZSBwZXJoYXBzIGdvb2QgaWYgZHJhZnQtdGNzLWNvYXAtbm8t cmVzcG9uc2Utb3B0aW9uIHdvdWxkIG1ha2UgdGhhdCBjbGVhci4gVGhlICJNVVNUIiBhbmQgdGhl IHVzZSBjYXNlIDQuMi4xIHN1Z2dlc3QgdGhhdCB0aGUgZGVmYXVsdCBzdXBwcmVzc2lvbiBjaG9p Y2VzIG9mIHRoZSBzZXJ2ZXIgYXJlIG92ZXJyaWRkZW4gYnkgdGhlIE5vLVJlc3BvbnNlIG9wdGlv biBidXQgdGhhdCBpcyBub3Qgd3JpdHRlbiBleHBsaWNpdGx5IHlldC4gIElmIHRoYXQgaXMgdGhl IGNhc2UsIG15IHVzZSBjYXNlIGlzIGZ1bGx5IGNvdmVyZWQgYnkgeW91ciBkcmFmdCBJIHRoaW5r Lg0KDQpBbiB1cGRhdGUgb3Igc3VjY2Vzc29yIHRvIHRoZSBHcm91cGNvbW0gUkZDIGNvdWxkIGlu ZGVlZCBkZXNjcmliZSBob3cgdGhlIE5vLVJlc3BvbnNlIE9wdGlvbiBjYW4gYmUgdXNlZCBmb3Ig bXVsdGljYXN0IHVzZSBjYXNlcy4gSXQgd291bGQgYmUgZ3JlYXQgaWYgdGhhdCBjb3VsZCBiZSBk b25lIHdpdGhvdXQgbmVlZGluZyBmdXJ0aGVyIG1vZGlmaWNhdGlvbnMgdG8gZHJhZnQtdGNzLWNv YXAtbm8tcmVzcG9uc2Utb3B0aW9uIQ0KDQpyZWdhcmRzDQpFc2tvDQoNCkZyb206IEFiaGlqYW4g QmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tXQ0KU2Vu dDogTW9uZGF5LCBNYXkgMDIsIDIwMTYgNToxOQ0KVG86IERpamssIEVza28gPGVza28uZGlqa0Bw aGlsaXBzLmNvbT4NCkNjOiBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPjsgTmV2aWwg QnJvd25sZWUgPHJmYy1pc2VAcmZjLWVkaXRvci5vcmc+DQpTdWJqZWN0OiBSRTogVXNpbmcgZHJh ZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUqIHJlc3BvbnNlcw0KSW1w b3J0YW5jZTogSGlnaA0KDQpIaSBFc2tvLA0KVGhlIGV4aXN0aW5nIHZlcnNpb24gLTE2IGhhcyB0 aGUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiAyLjEgKHBhZ2UgNSkgOg0KIlRoZSBzZXJ2ZXIg TVVTVCBzZW5kIGJhY2sgcmVzcG9uc2VzIG9mIHRoZSBjbGFzc2VzIGZvciB3aGljaCB0aGUgY2xp ZW50IGhhcyBub3QgZXhwcmVzc2VkIGFueSBkaXMtaW50ZXJlc3QuIg0KU28sIHRoYXQgd2F5IHRo ZSBjbGllbnQgaGFzIGFjdHVhbGx5IGV4cHJlc3NlZCBpdHMgaW50ZXJlc3QgKG9yIHJlcXVlc3Qg Zm9yIGVuYWJsZW1lbnQpIGluIGFsbCB0aGUgcmVzcG9uc2VzIGZvciB3aGljaCBpdCBoYXMgbm90 IGV4cHJlc3NlZCBleHBsaWNpdCBkaXNpbnRlcmVzdC4gRG9lcyB0aGF0IGhlbHAgdG8gY29udHJv bCB0aGUgc3BlY2lhbCBzZXJ2ZXItc2lkZSBiZWhhdmlvdXIgYXMgdGhlIHNlcnZlciBrbm93cyB3 aGljaCBhbGwgcmVzcG9uc2VzIHRoZSBjbGllbnQgaXMgaW50ZXJlc3RlZCBpbiBhbmQgaXQgTVVT VCBzZW5kIGEgcmVzcG9uc2UgYmFjayA/IEkgc2hhbGwgc3VibWl0IGFub3RoZXIgdmVyc2lvbiB3 aXRoIHNvbWUgZWRpdG9yaWFsIGNoYW5nZXMgYmVmb3JlIHRoZSBkcmFmdCBnb2VzIHRvIElFU0cu IFNvIHdlIGhhdmUgc29tZSBtb3JlIHJvb20gZm9yIG1vZGlmaWNhdGlvbi4gSWYgeW91IGhhdmUg c29tZSBjb21tZW50cyBvbiB0aGlzIGluIHRoZSBsaW5lIG9mIHRoZSBkaXNjdXNzaW9uIHdlIGFy ZSBoYXZpbmcsIHBsZWFzZSBsZXQgdXMga25vdy4gSSBzaGFsbCB3YWl0IGZvciB5b3VyIHZpZXdz IGJlZm9yZSBzdWJtaXR0aW5nIHRoZSB1cGRhdGVkIHZlcnNpb24uDQoNCkFueXdheSwgYSBzZXBh cmF0ZSBkcmFmdCAob3IsIHBvc3NpYmx5LCBhbiB1cGRhdGVkIGdyb3VwY29tbSBSRkM/KSBpcyBh IGdvb2QgaWRlYS4gTm8tUmVzcG9uc2UgYXNzdW1lcyB0aGUgdXN1YWwgcmVxdWVzdC9yZXNwb25z ZSBzeW1hbnRpY3MgYW5kIGl0IG1haW5seSBhZGRyZXNzZXMgdGhlIGNsaWVudCBzaWRlIGJlaGF2 aW91ciBhbmQgaXNzdWVzLiBDb25zaWRlcmluZyBzdWNoIHNwZWNpYWwgYmVoYXZpb3VyIG9mIGdy b3VwY29tbSBzZXJ2ZXJzLCBpdCB3b3VsZCBiZSBnb29kIHRvIGhhbmRsZSBzZXBhcmF0ZWx5Lg0K DQpXYWl0aW5nIHRvIGhlYXIgZnJvbSB5b3UuDQoNClJlZ2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hh cnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtv bGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQpNYWlsdG86IGFiaGlqYW4u YmhhdHRhY2hhcnl5YUB0Y3MuY29tPG1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bT4NCldlYnNpdGU6IGh0dHA6Ly93d3cudGNzLmNvbTxodHRwOi8vd3d3LnRjcy5jb20vPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkV4cGVyaWVuY2UgY2Vy dGFpbnR5LiAgICAgICAgSVQgU2VydmljZXMNCiAgICAgICAgICAgICAgICAgICAgICAgQnVzaW5l c3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRpbmcNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KIkRpamssIEVza28iIDxl c2tvLmRpamtAcGhpbGlwcy5jb208bWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbT4+IHdyb3Rl IG9uIDA1LzAyLzIwMTYgMDM6MTA6MjQgQU06DQoNCj4gRnJvbTogIkRpamssIEVza28iIDxlc2tv LmRpamtAcGhpbGlwcy5jb208bWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbT4+DQo+IFRvOiBB YmhpamFuIEJoYXR0YWNoYXJ5eWEgPGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPG1haWx0 bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT4+DQo+IENjOiAiY29yZUBpZXRmLm9yZyBX RzxtYWlsdG86Y29yZUBpZXRmLm9yZyUyMFdHPiIgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVA aWV0Zi5vcmc+PiwgTmV2aWwgQnJvd25sZWUgPHJmYy1pc2VAcmZjLQ0KPiBlZGl0b3Iub3JnPg0K PiBEYXRlOiAwNS8wMi8yMDE2IDAzOjEwIEFNDQo+IFN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10 Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSogcmVzcG9uc2VzDQo+DQo+IEhl bGxvIEFiaGlqYW4sDQo+DQo+ID4gTWFuZGF0aW5nIHN1Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9t IHRoZSBjbGllbnQgc2lkZSB3aWxsIGJlIGEgYml0DQo+IG91dC1vZi1zeW5jIHdpdGggdGhlIHNw aXJpdCBvZiB0aGUgc3BlY2lmaWNhdGlvbi4NCj4gVGhpcyBpcyBub3QgZnVsbHkgY2xlYXIgdG8g bWUgeWV0IOKApiB0aGUgY2xpZW50IGRvZXMgbm90IG1hbmRhdGUNCj4gYW55dGhpbmcgZnJvbSB0 aGUgc2VydmVyOyBpdCBqdXN0IGV4cHJlc3NlcyBpdHMgaW50ZXJlc3QgKDAtYml0cykNCj4gYW5k IGRpc2ludGVyZXN0ICgxLWJpdHMpLiBUaGUgc2VydmVyIGNhbiBhbHdheXMgbm90IHBhcnNlIHRo ZSBvcHRpb24NCj4gKGVsZWN0aXZlKSBvciBjaG9vc2Ugbm90IHRvIGJvdGhlciBhYm91dCBpdC4N Cj4gVGhpcyBkb2VzIGtlZXAgdGhlIGNsaWVudCB3YWl0aW5nIGZvciBhIHBvc3NpYmxlIHJlc3Bv bnNlIHRoYXQgbmV2ZXINCj4gY29tZXM7IGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGluIHRoZSBnZW5l cmFsIG11bHRpY2FzdCBjYXNlIDogdGhlDQo+IGNsaWVudCBjYW4gbmV2ZXIga25vdyBpZiBvciB3 aGVuIGEgcmVzcG9uc2Ugd2lsbCBjb21lLCB0aGUgc2VydmVyDQo+IE1BWSBhbHdheXMgY2hvb3Nl IHRvIG5vdCByZXNwb25kLg0KPg0KPiBTbyB3aGF0IEkgcHJvcG9zZSBpcyB0byB1c2UgdGhlICJp bmRpY2F0aW9uIG9mIGludGVyZXN0IiB0byBzcGVjaWZpYw0KPiByZXNwb25zZSBjbGFzc2VzIGlu IGEgbmV3IHdheTsgbmFtZWx5IHRvIGVuYWJsZSBjZXJ0YWluIHJlc3BvbnNlDQo+IGNsYXNzZXMg dGhhdCBhcmUgc3VwcHJlc3NlZCBieSBkZWZhdWx0LiAgSXQganVzdCBoYXBwZW5zIHRoYXQgdGhl DQo+IHNhbWUgT3B0aW9uIHN5bnRheCBpcyB2ZXJ5IHdlbGwgc3VpdGVkIGZvciB0aGF0IHB1cnBv c2UuIEEgc2VwYXJhdGUNCj4gZHJhZnQgY291bGQgYmUgd3JpdHRlbiBmb3IgdGhhdCBwZXJoYXBz IGlmIHlvdSB0aGluayBpdCBkb2VzIG5vdCBmaXQNCj4gaW4gZHJhZnQtdGNzLWNvYXAtbm8tcmVz cG9uc2Utb3B0aW9uIG9yIGlmIGl0IGlzIHRvbyBsYXRlIGZvciB0aGF0Lg0KPiBUaGUgd2UgY2Fu IHBvaW50IHRvIHRoZSBzeW50YXggb2YgdGhlIE5vLVJlc3BvbnNlIE9wdGlvbiBhbmQgcmUtdXNl DQo+IGl0IGNvbXBsZXRlbHkuDQo+DQo+IHJlZ2FyZHMNCj4gRXNrbw0KPg0KPiBGcm9tOiBBYmhp amFuIEJoYXR0YWNoYXJ5eWEgW21haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbV0N Cj4gU2VudDogRnJpZGF5LCBBcHJpbCAyMiwgMjAxNiAxNzoxNw0KPiBUbzogRGlqaywgRXNrbyA8 ZXNrby5kaWprQHBoaWxpcHMuY29tPG1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20+Pg0KPiBD YzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4gV0cgPGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOmNvcmVAaWV0Zi5vcmc+PjsgTmV2aWwgQnJvd25sZWUgPHJmYy1pc2VAcmZjLWVkaXRv ci5vcmc8bWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogVXNp bmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUqIHJlc3BvbnNl cw0KPg0KPiBIaSBFc2tvLA0KPiBUaGFua3MgZm9yIHlvdXIgbWFpbC4NCj4gRmlyc3Qgb2YgYWxs IGxldCBtZSBqdXN0IGJyaW5nIHRoaXMgdG8geW91ciAoYXMgd2VsbCBhcyB0aGUgbWFpbGluZw0K PiBsaXN0J3MpIG5vdGljZSB0aGF0IHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXM6 DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10Y3MtY29hcC1u by1yZXNwb25zZS1vcHRpb24tMTYudHh0DQo+DQo+IFRoaXMgdmVyc2lvbiAib2ZmaWNpYWxseSIg Y2xvc2VzIHRoZSB0ZWNobmljYWwgcmV2aWV3cyBhbmQgaXMgd2l0aA0KPiB0aGUgUkZDIGVkaXRv ciB0aHJvdWdoIHRoZSBJUyB0cmFjay4NCj4NCj4gTm93IGNvbWluZyB0byB5b3VyIHVzZSBjYXNl IChhbmQgaW5kZWVkIGl0IGlzIGFuIGludGVyZXN0aW5nIG9uZSkNCj4gb25lIHRoaW5nIHRoYXQg d2Ugc2hvdWxkIGNvbnNpZGVyIGlzIHRoYXQgdGhlIE5vLVJlc3BvbnNlIG9wdGlvbiB3YXMNCj4g ZGVsaWJlcmF0ZWx5IGRlc2lnbmVkIG5vdCB0byBtYW5kYXRlIGFueXRoaW5nIGZvciB0aGUgc2Vy dmVyIHNpZGUNCj4gbWFpbmx5IHRvIGVuc3VyZSB0aGF0IGl0IGRvZXMgbm90IGRpc3J1cHQgdGhl IG1hbnkgdXNlZnVsbmVzcyBvZiB0aGUNCj4gdXN1YWwgcmVxdWVzdC9yZXNwb25zZSBzeW1hbnRp Y3MuIFRoZSBkcmFmdCBhbGwgYWxvbmcgZGVhbHMgd2l0aCB0aGUNCj4gcmVxdWVzdGluZyBjbGll bnQncyBiZWhhdmlvdXIgYW5kIGl0cyBleHByZXNzaW9uIG9mIGludGVyZXN0IHRvIHRoZQ0KPiBz ZXJ2ZXIuIFNpbmNlIHRoaXMgb3B0aW9uIGlzIGVsZWN0aXZlIHdlIGxlYXZlIGl0IHVwdG8gdGhl IHNlcnZlcg0KPiBpbXBsZW1lbnRhdGlvbiB0byBob25vdXIgdGhlIGNsaWVudCdzIGludGVyZXN0 Lg0KPg0KPiBOb3csIGFzIHBlciB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIHN5bWFudGljcyB0aGUg cmVzcG9uc2VzIGFyZQ0KPiBhbHdheXMgZW5hYmxlZC4gVGhlIGJlaGF2aW91ciBpbiBncm91cGNv bW0gc2VydmVyIGluIHRlcm1zIG9mDQo+IHN1cHByZXNzaW5nIHRoZSByZXNwb25zZXMgb24gaXRz IG93biBpcyBzb21ldGhpbmcgc3BlY2lhbCBhbmQsDQo+IGdlbmVyYWxseSBzcGVha2luZywgdGhl IGNsaWVudHMgYXJlIG5vdCBhd2FyZSBvZiBzdWNoIHNwZWNpYWwgYmVoYXZpb3VyLg0KPg0KPiBT bywgaXQgd291bGQgYmUganVzdGlmaWVkIHRvIGhhbmRsZSB0aGUgc2l0dWF0aW9uIGF0IHRoZSBz ZXJ2ZXIncw0KPiBlbmQuIEhlcmUgaXMgdGhlIGlkZWE6DQo+IFdoaWxlIE5vLVJlc3BvbnNlIGlz IHRvIGV4cHJlc3NlcyBjbGllbnQncyBkaXMtaW50ZXJlc3QgaW4gc29tZSBvcg0KPiBhbGwgb2Yg dGhlIHJlc3BvbnNlcyBkZXBlbmRpbmcgb24gdGhlIG9wdGlvbiB2YWx1ZSwgaXQgaXMgYWxzbyB0 cnVlDQo+IHRoYXQgdGhlIG9wdGlvbiBhdXRvbWF0aWNhbGx5IGV4cHJlc3NlcyBpbnRlcmVzdCBp biBhbGwgb3RoZXINCj4gcmVzcG9uc2VzIChtYXJrZWQgYnkgMCdzIGluIHRoZSByZXNwZWN0aXZl IHBvc2l0aW9ucykuIFRoZSBjbGllbnQgaXMNCj4gZ29pbmcgdG8gd2FpdCBmb3IgdGhlc2UgcmVz cG9uc2VzIHVwdG8gYSBnaXZlbiB0aW1lb3V0LiBOb3csIGlmIHRoZQ0KPiBzZXJ2ZXIgYmVoYXZp b3VyIGlzIG1vZGlmaWVkIGxpa2UgdGhpcyA6ICJJIGhhdmUgY2xvc2VkIG15IGRvb3IgZm9yDQo+ IGFsbCBvdXQgZ29pbmcgcmVzcG9uc2UuICoqQlVUKiosIGlmIEkgc2VlIGEgZmVsbG93IHJlcXVl c3Rpbmcgd2l0aA0KPiBOby1SZXNwb25zZSBhbmQga2VlcGluZyB3aW5kb3dzIG9wZW4gdG8gc29t ZSByZXNwb25zZXMgdGhlbiBJIGFzc3VtZQ0KPiB0aGF0IHRoaXMgZ3V5IHJlYWxseSBuZWVkcyB0 aG9zZSBraW5kIG9mIHJlc3BvbnNlcy4gSW4gdGhhdCBjYXNlIGxldA0KPiBtZSBiZSBsaW5pZW50 IGFuZCBsZXQgbWUgb3BlbiB0aGUgZG9vciBmb3Igc3VjaCByZXNwb25zZXMuIFRoaXMNCj4gZmVs bG93IG11c3QgYmUgYXZhaWxhYmxlIHRvIGxpc3RlbiB0byB0aGVtIGFzIHBlciB0aGUgcHJlc2Ny aWJlZA0KPiBiZWhhdmlvdXIgaW4gdGhlIE5vLVJlc3BvbnNlIHNwZWNpZmljYXRpb24uIg0KPg0K PiBNYW5kYXRpbmcgc3VjaCBzZXJ2ZXIgYmVoYXZpb3VyIGZyb20gdGhlIGNsaWVudCBzaWRlIHdp bGwgYmUgYSBiaXQNCj4gb3V0LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZp Y2F0aW9uLg0KPg0KPiBSZWdhcmRzDQo+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiBBc3NvY2lh dGUgQ29uc3VsdGFudA0KPiBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRp YQ0KPiBUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQo+IE1haWx0bzogYWJoaWphbi5iaGF0dGFj aGFyeXlhQHRjcy5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPg0KPiBX ZWJzaXRlOiBodHRwOi8vd3d3LnRjcy5jb208aHR0cDovL3d3dy50Y3MuY29tLz4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRXhwZXJpZW5jZSBjZXJ0 YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0KPiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2lu ZXNzIFNvbHV0aW9ucw0KPiAgICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRpbmcNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4NCj4NCj4NCj4g RnJvbTogICAgICAgICJEaWprLCBFc2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPG1haWx0bzpl c2tvLmRpamtAcGhpbGlwcy5jb20+Pg0KPiBUbzogICAgICAgIEFiaGlqYW4gQmhhdHRhY2hhcnl5 YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hh cnl5YUB0Y3MuY29tPj4NCj4gQ2M6ICAgICAgICBOZXZpbCBCcm93bmxlZSA8cmZjLWlzZUByZmMt ZWRpdG9yLm9yZzxtYWlsdG86cmZjLWlzZUByZmMtZWRpdG9yLm9yZz4+LCAiY29yZUBpZXRmLm9y ZyBXRzxtYWlsdG86Y29yZUBpZXRmLm9yZyUyMFdHPiIgPA0KPiBjb3JlQGlldGYub3JnPG1haWx0 bzpjb3JlQGlldGYub3JnPj4NCj4gRGF0ZTogICAgICAgIDA0LzIyLzIwMTYgMDU6NDMgUE0NCj4g U3ViamVjdDogICAgICAgIFVzaW5nIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0 byAqZW5hYmxlKiByZXNwb25zZXMNCj4NCj4NCj4NCj4NCj4gSGVsbG8gQWJoaWphbiwNCj4NCj4g aW4gb3VyIHByb2plY3Qgd2Ugc2VlIGEgY2xlYXIgdXNlIGNhc2Ugb2YgdXNpbmcgdGhlIE5vLVJl c3BvbnNlDQo+IE9wdGlvbiB0byAqZW5hYmxlKiBjZXJ0YWluIHJlc3BvbnNlcyB0aGF0IGFyZSBi eSBkZWZhdWx0IHN1cHByZXNzZWQuDQo+IENvQVAgYWxsb3dzIHN1cHByZXNzaW9uIG9mIG11bHRp Y2FzdCByZXNwb25zZXMgYnkgZGVmYXVsdCwgd2hpY2ggaXMNCj4gd2hhdCB3ZSB1c2UgZm9yIGEg bGlnaHRpbmcgbXVsdGljYXN0IHVzZSBjYXNlLiBIb3dldmVyIGZvcg0KPiBkaWFnbm9zdGljIHVz YWdlIHdlJ2QgbGlrZSB0byBlbmFibGUgdGhlc2UgcmVzcG9uc2VzIGFnYWluIHVzaW5nIHRoZQ0K PiBOby1SZXNwb25zZSBvcHRpb24gd2hpY2ggaXMgcGVyZmVjdGx5IHN1aXRlZCBmb3IgdGhhdC4g SG93ZXZlciwgdGhlDQo+IGRyYWZ0IHRleHQgY3VycmVudGx5IG9ubHkgdGFsa3MgYWJvdXQgc3Vw cHJlc3NpbmcgcmVzcG9uc2VzIChub3QgZW5hYmxpbmcpLg0KPg0KPiBIZW5jZSBteSByZXF1ZXN0 OiBjb3VsZCB3ZSBtb2RpZnkvYWRkIHNvbWUgdGV4dCB0byBzaG93IHRoYXQgYWxzbw0KPiB0aGUg b3B0aW9uIGNhbiBiZSB1c2VkIHRvIGVuYWJsZSByZXNwb25zZXMgaW4gY2FzZSB3aGVyZSB0aGV5 IGFyZQ0KPiBub3JtYWxseSAoYnkgZGVmYXVsdCAtLSBzZXJ2ZXIgZGVjaXNpb24pIHN1cHByZXNz ZWQ/DQo+IEp1c3QgdG8gY2xhcmlmeSBzdWNoIHVzYWdlOyB3aGljaCBpcyBxdWl0ZSB1c2VmdWwg aW4gbXkgdmlldy4NCj4NCj4gcmVnYXJkcw0KPiBFc2tvDQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNz YWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kDQo+IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFw cGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZA0KPiBzb2xlbHkgZm9yIHRoZSBh ZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsDQo+IHlv dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5h dGlvbiwgb3INCj4gcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCBtYXkgYmUNCj4gdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZQ0KPiBzZW5kZXIgYnkgcmV0dXJuIGUtbWFp bCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KPiA9PT09 PS0tLS0tPT09PT0tLS0tLT09PT09DQo+IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIGUtbWFpbA0KPiBtZXNzYWdlIGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBtYXkg Y29udGFpbg0KPiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91 IGFyZQ0KPiBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVz ZSwNCj4gcmV2aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlpbmcgb2YgdGhlDQo+ IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlDQo+IGFuZC9vciBh dHRhY2htZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYNCj4geW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLA0KPiBwbGVhc2Ugbm90aWZ5IHVz IGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kDQo+IGltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UNCj4gYW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsg eW91DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5 IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRp bmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBl LW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --_000_dcc875e1f79c461c9293e37107a04a9eHE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQp0dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtUaGUg c2VydmVyIE1VU1Qgc2VuZCBiYWNrIHJlc3BvbnNlcyBvZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2gg dGhlIGNsaWVudCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiZxdW90OyAtDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPlRoaXMgY292ZXJzIHBhcnQgb2YgbXkgdXNlIGNhc2U7IGhvd2V2ZXIgaXQgaXMgbm90IGNs ZWFyIGhvdyB0aGlzICZxdW90O01VU1QmcXVvdDsgaW50ZXJhY3RzIHdpdGggdGhlICZxdW90O01B WSBzdXBwcmVzcyZxdW90OyBvZiBSRkMgNzI1MiBmb3IgdGhlIG11bHRpY2FzdCBjYXNlLiBDYW4g dGhlIHNlcnZlciBzdGlsbCBkZWNpZGUgdG8NCiBzdXBwcmVzcyB0aGUgbXVsdGljYXN0IHJlc3Bv bnNlIGV2ZW4gaWYgdGhlIE5vLVJlc3BvbnNlIE9wdGlvbiBzZW50IGJ5IHRoZSBjbGllbnQgc2F5 cyBub3QgdG8/IFRoaW5raW5nIGFib3V0IGl0LCBpdCB3b3VsZCBiZSBwZXJoYXBzIGdvb2QgaWYg ZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHdvdWxkIG1ha2UgdGhhdCBjbGVhci4g VGhlICZxdW90O01VU1QmcXVvdDsgYW5kIHRoZSB1c2UgY2FzZSA0LjIuMSBzdWdnZXN0IHRoYXQg dGhlIGRlZmF1bHQNCiBzdXBwcmVzc2lvbiBjaG9pY2VzIG9mIHRoZSBzZXJ2ZXIgYXJlIG92ZXJy aWRkZW4gYnkgdGhlIE5vLVJlc3BvbnNlIG9wdGlvbiBidXQgdGhhdCBpcyBub3Qgd3JpdHRlbiBl eHBsaWNpdGx5IHlldC4mbmJzcDsgSWYgdGhhdCBpcyB0aGUgY2FzZSwgbXkgdXNlIGNhc2UgaXMg ZnVsbHkgY292ZXJlZCBieSB5b3VyIGRyYWZ0IEkgdGhpbmsuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuIHVw ZGF0ZSBvciBzdWNjZXNzb3IgdG8gdGhlIEdyb3VwY29tbSBSRkMgY291bGQgaW5kZWVkIGRlc2Ny aWJlIGhvdyB0aGUgTm8tUmVzcG9uc2UgT3B0aW9uIGNhbiBiZSB1c2VkIGZvciBtdWx0aWNhc3Qg dXNlIGNhc2VzLiBJdCB3b3VsZCBiZSBncmVhdCBpZiB0aGF0IGNvdWxkIGJlIGRvbmUgd2l0aG91 dA0KIG5lZWRpbmcgZnVydGhlciBtb2RpZmljYXRpb25zIHRvIGRyYWZ0LXRjcy1jb2FwLW5vLXJl c3BvbnNlLW9wdGlvbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXNrbzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWJoaWphbiBCaGF0dGFj aGFyeXlhIFttYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBNYXkgMDIsIDIwMTYgNToxOTxicj4NCjxiPlRvOjwvYj4gRGlqaywg RXNrbyAmbHQ7ZXNrby5kaWprQHBoaWxpcHMuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gY29yZUBp ZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs7IE5ldmlsIEJyb3dubGVlICZsdDtyZmMt aXNlQHJmYy1lZGl0b3Iub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogVXNpbmcgZHJh ZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUqIHJlc3BvbnNlczxicj4N CjxiPkltcG9ydGFuY2U6PC9iPiBIaWdoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5IaSBFc2tvLDwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBl eGlzdGluZyB2ZXJzaW9uIC0xNiBoYXMgdGhlIGZvbGxvd2luZyB0ZXh0IGluIHNlY3Rpb24gMi4x IChwYWdlIDUpIDoNCjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtUaGUgc2VydmVy IE1VU1Qgc2VuZCBiYWNrIHJlc3BvbnNlcyBvZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2ggdGhlIGNs aWVudCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiZxdW90Ow0KPC9zcGFuPjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPlNvLCB0aGF0IHdheSB0aGUgY2xpZW50IGhhcyBhY3R1YWxseSBl eHByZXNzZWQgaXRzIGludGVyZXN0IChvciByZXF1ZXN0IGZvciBlbmFibGVtZW50KSBpbiBhbGwg dGhlIHJlc3BvbnNlcyBmb3Igd2hpY2ggaXQgaGFzIG5vdCBleHByZXNzZWQgZXhwbGljaXQgZGlz aW50ZXJlc3QuIERvZXMgdGhhdCBoZWxwIHRvIGNvbnRyb2wgdGhlIHNwZWNpYWwNCiBzZXJ2ZXIt c2lkZSBiZWhhdmlvdXIgYXMgdGhlIHNlcnZlciBrbm93cyB3aGljaCBhbGwgcmVzcG9uc2VzIHRo ZSBjbGllbnQgaXMgaW50ZXJlc3RlZCBpbiBhbmQgaXQgTVVTVCBzZW5kIGEgcmVzcG9uc2UgYmFj ayA/IEkgc2hhbGwgc3VibWl0IGFub3RoZXIgdmVyc2lvbiB3aXRoIHNvbWUgZWRpdG9yaWFsIGNo YW5nZXMgYmVmb3JlIHRoZSBkcmFmdCBnb2VzIHRvIElFU0cuIFNvIHdlIGhhdmUgc29tZSBtb3Jl IHJvb20gZm9yIG1vZGlmaWNhdGlvbi4NCiBJZiB5b3UgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRo aXMgaW4gdGhlIGxpbmUgb2YgdGhlIGRpc2N1c3Npb24gd2UgYXJlIGhhdmluZywgcGxlYXNlIGxl dCB1cyBrbm93LiBJIHNoYWxsIHdhaXQgZm9yIHlvdXIgdmlld3MgYmVmb3JlIHN1Ym1pdHRpbmcg dGhlIHVwZGF0ZWQgdmVyc2lvbi4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5B bnl3YXksIGEgc2VwYXJhdGUgZHJhZnQgKG9yLCBwb3NzaWJseSwgYW4gdXBkYXRlZCBncm91cGNv bW0gUkZDPykgaXMgYSBnb29kIGlkZWEuIE5vLVJlc3BvbnNlIGFzc3VtZXMgdGhlIHVzdWFsIHJl cXVlc3QvcmVzcG9uc2Ugc3ltYW50aWNzIGFuZCBpdCBtYWlubHkgYWRkcmVzc2VzIHRoZSBjbGll bnQgc2lkZSBiZWhhdmlvdXIgYW5kIGlzc3Vlcy4NCiBDb25zaWRlcmluZyBzdWNoIHNwZWNpYWwg YmVoYXZpb3VyIG9mIGdyb3VwY29tbSBzZXJ2ZXJzLCBpdCB3b3VsZCBiZSBnb29kIHRvIGhhbmRs ZSBzZXBhcmF0ZWx5Ljwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldhaXRpbmcg dG8gaGVhciBmcm9tIHlvdS48L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SZWdh cmRzPGJyPg0KQWJoaWphbiBCaGF0dGFjaGFyeXlhPGJyPg0KQXNzb2NpYXRlIENvbnN1bHRhbnQ8 YnI+DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NClRhdGEg Q29uc3VsdGFuY3kgU2VydmljZXM8YnI+DQpNYWlsdG86IDxhIGhyZWY9Im1haWx0bzphYmhpamFu LmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L2E+ PGJyPg0KV2Vic2l0ZTogPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cudGNzLmNvbS8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPmh0dHA6Ly93d3cudGNzLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpFeHBl cmllbmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjxicj4NCjxicj4NCjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7RGlqaywgRXNrbyZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbSI+ZXNrby5kaWprQHBoaWxpcHMu Y29tPC9hPiZndDsgd3JvdGUgb24gMDUvMDIvMjAxNiAwMzoxMDoyNCBBTTo8L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPGJyPg0KPHR0PiZndDsgRnJvbTogJnF1b3Q7RGlqaywgRXNrbyZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbSI+ZXNrby5kaWprQHBo aWxpcHMuY29tPC9hPiZndDs8L3R0Pjwvc3Bhbj4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyBUbzogQWJoaWphbiBCaGF0dGFjaGFyeXlhICZsdDs8YSBocmVm PSJtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20iPmFiaGlqYW4uYmhhdHRhY2hh cnl5YUB0Y3MuY29tPC9hPiZndDs8L3NwYW4+PC90dD4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyBDYzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0 Zi5vcmclMjBXRyI+Y29yZUBpZXRmLm9yZyBXRzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZndDssIE5ldmlsIEJyb3dubGVlICZs dDtyZmMtaXNlQHJmYy08L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgZWRpdG9y Lm9yZyZndDs8L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mZ3Q7IERhdGU6IDA1LzAyLzIwMTYgMDM6MTAgQU08L3NwYW4+PC90dD4gPGJyPg0KPHR0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IFN1YmplY3Q6IFJFOiBVc2luZyBk cmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSogcmVzcG9uc2VzPC9z cGFuPjwvdHQ+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IEhlbGxvIEFiaGlqYW4sPC90dD48 L3NwYW4+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJz cDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7ICZndDsgTWFuZGF0aW5nIHN1Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBjbGllbnQg c2lkZSB3aWxsIGJlIGEgYml0PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IG91 dC1vZi1zeW5jIHdpdGggdGhlIHNwaXJpdCBvZiB0aGUgc3BlY2lmaWNhdGlvbi48L3R0Pjwvc3Bh bj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IFRoaXMgaXMg bm90IGZ1bGx5IGNsZWFyIHRvIG1lIHlldCDigKYgdGhlIGNsaWVudCBkb2VzIG5vdCBtYW5kYXRl DQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgYW55dGhpbmcgZnJvbSB0aGUg c2VydmVyOyBpdCBqdXN0IGV4cHJlc3NlcyBpdHMgaW50ZXJlc3QgKDAtYml0cykgPC90dD48YnI+ DQo8dHQ+Jmd0OyBhbmQgZGlzaW50ZXJlc3QgKDEtYml0cykuIFRoZSBzZXJ2ZXIgY2FuIGFsd2F5 cyBub3QgcGFyc2UgdGhlIG9wdGlvbjwvdHQ+PGJyPg0KPHR0PiZndDsgKGVsZWN0aXZlKSBvciBj aG9vc2Ugbm90IHRvIGJvdGhlciBhYm91dCBpdC48L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IFRoaXMgZG9lcyBrZWVwIHRoZSBjbGllbnQg d2FpdGluZyBmb3IgYSBwb3NzaWJsZSByZXNwb25zZSB0aGF0IG5ldmVyPC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxicj4NCjx0dD4mZ3Q7IGNvbWVzOyBidXQgdGhhdCBpcyB0aGUgc2FtZSBpbiB0aGUg Z2VuZXJhbCBtdWx0aWNhc3QgY2FzZSA6IHRoZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IGNsaWVudCBj YW4gbmV2ZXIga25vdyBpZiBvciB3aGVuIGEgcmVzcG9uc2Ugd2lsbCBjb21lLCB0aGUgc2VydmVy IDwvdHQ+PGJyPg0KPHR0PiZndDsgTUFZIGFsd2F5cyBjaG9vc2UgdG8gbm90IHJlc3BvbmQuPC90 dD48L3NwYW4+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAm bmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7IFNvIHdoYXQgSSBwcm9wb3NlIGlzIHRvIHVzZSB0aGUgJnF1b3Q7aW5kaWNhdGlvbiBv ZiBpbnRlcmVzdCZxdW90OyB0byBzcGVjaWZpYzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8 dHQ+Jmd0OyByZXNwb25zZSBjbGFzc2VzIGluIGEgbmV3IHdheTsgbmFtZWx5IHRvIGVuYWJsZSBj ZXJ0YWluIHJlc3BvbnNlIDwvdHQ+PGJyPg0KPHR0PiZndDsgY2xhc3NlcyB0aGF0IGFyZSBzdXBw cmVzc2VkIGJ5IGRlZmF1bHQuICZuYnNwO0l0IGp1c3QgaGFwcGVucyB0aGF0IHRoZSA8L3R0Pjxi cj4NCjx0dD4mZ3Q7IHNhbWUgT3B0aW9uIHN5bnRheCBpcyB2ZXJ5IHdlbGwgc3VpdGVkIGZvciB0 aGF0IHB1cnBvc2UuIEEgc2VwYXJhdGUgPC90dD48YnI+DQo8dHQ+Jmd0OyBkcmFmdCBjb3VsZCBi ZSB3cml0dGVuIGZvciB0aGF0IHBlcmhhcHMgaWYgeW91IHRoaW5rIGl0IGRvZXMgbm90IGZpdDwv dHQ+PGJyPg0KPHR0PiZndDsgaW4gZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIG9y IGlmIGl0IGlzIHRvbyBsYXRlIGZvciB0aGF0LiA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFRoZSB3ZSBj YW4gcG9pbnQgdG8gdGhlIHN5bnRheCBvZiB0aGUgTm8tUmVzcG9uc2UgT3B0aW9uIGFuZCByZS11 c2UgPC90dD48YnI+DQo8dHQ+Jmd0OyBpdCBjb21wbGV0ZWx5LjwvdHQ+PC9zcGFuPiA8YnI+DQo8 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+ IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyByZWdhcmRzPC9z cGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBF c2tvPC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7IEZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbPC9zcGFuPjwvdHQ+PGEg aHJlZj0ibWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tIj48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPm1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bTwvc3Bhbj48L3R0PjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl0NCjwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDIy LCAyMDE2IDE3OjE3PC90dD48YnI+DQo8dHQ+Jmd0OyBUbzogRGlqaywgRXNrbyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbSI+ZXNrby5kaWprQHBoaWxpcHMuY29tPC9h PiZndDs8L3R0Pjxicj4NCjx0dD4mZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4gV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3Jn Ij5jb3JlQGlldGYub3JnPC9hPiZndDs7IE5ldmlsIEJyb3dubGVlICZsdDs8YSBocmVmPSJtYWls dG86cmZjLWlzZUByZmMtZWRpdG9yLm9yZyI+cmZjLWlzZUByZmMtZWRpdG9yLm9yZzwvYT4mZ3Q7 PC90dD48YnI+DQo8dHQ+Jmd0OyBTdWJqZWN0OiBSZTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8t cmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUqIHJlc3BvbnNlczwvdHQ+PC9zcGFuPg0KPGJyPg0K PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0 PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgSGkgRXNrbywg PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IFRoYW5rcyBmb3IgeW91ciBtYWls LiA8L3R0Pjxicj4NCjx0dD4mZ3Q7IEZpcnN0IG9mIGFsbCBsZXQgbWUganVzdCBicmluZyB0aGlz IHRvIHlvdXIgKGFzIHdlbGwgYXMgdGhlIG1haWxpbmcgPC90dD48YnI+DQo8dHQ+Jmd0OyBsaXN0 J3MpIG5vdGljZSB0aGF0IHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXM6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC90dD48YnI+DQo8dHQ+Jmd0OyA8 L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uLTE2LnR4dCI+PHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uLTE2LnR4dDwvc3Bhbj48L3R0PjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBUaGlzIHZlcnNpb24g JnF1b3Q7b2ZmaWNpYWxseSZxdW90OyBjbG9zZXMgdGhlIHRlY2huaWNhbCByZXZpZXdzIGFuZCBp cyB3aXRoIDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhlIFJGQyBlZGl0b3IgdGhyb3VnaCB0aGUgSVMg dHJhY2suIDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBOb3cgY29taW5n IHRvIHlvdXIgdXNlIGNhc2UgKGFuZCBpbmRlZWQgaXQgaXMgYW4gaW50ZXJlc3Rpbmcgb25lKSA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IG9uZSB0aGluZyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBpcyB0 aGF0IHRoZSBOby1SZXNwb25zZSBvcHRpb24gd2FzPC90dD48YnI+DQo8dHQ+Jmd0OyBkZWxpYmVy YXRlbHkgZGVzaWduZWQgbm90IHRvIG1hbmRhdGUgYW55dGhpbmcgZm9yIHRoZSBzZXJ2ZXIgc2lk ZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IG1haW5seSB0byBlbnN1cmUgdGhhdCBpdCBkb2VzIG5vdCBk aXNydXB0IHRoZSBtYW55IHVzZWZ1bG5lc3Mgb2YgdGhlPC90dD48YnI+DQo8dHQ+Jmd0OyB1c3Vh bCByZXF1ZXN0L3Jlc3BvbnNlIHN5bWFudGljcy4gVGhlIGRyYWZ0IGFsbCBhbG9uZyBkZWFscyB3 aXRoIHRoZTwvdHQ+PGJyPg0KPHR0PiZndDsgcmVxdWVzdGluZyBjbGllbnQncyBiZWhhdmlvdXIg YW5kIGl0cyBleHByZXNzaW9uIG9mIGludGVyZXN0IHRvIHRoZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7 IHNlcnZlci4gU2luY2UgdGhpcyBvcHRpb24gaXMgZWxlY3RpdmUgd2UgbGVhdmUgaXQgdXB0byB0 aGUgc2VydmVyIDwvdHQ+PGJyPg0KPHR0PiZndDsgaW1wbGVtZW50YXRpb24gdG8gaG9ub3VyIHRo ZSBjbGllbnQncyBpbnRlcmVzdC4gPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4m Z3Q7IE5vdywgYXMgcGVyIHVzdWFsIHJlcXVlc3QvcmVzcG9uc2Ugc3ltYW50aWNzIHRoZSByZXNw b25zZXMgYXJlIDwvdHQ+PGJyPg0KPHR0PiZndDsgYWx3YXlzIGVuYWJsZWQuIFRoZSBiZWhhdmlv dXIgaW4gZ3JvdXBjb21tIHNlcnZlciBpbiB0ZXJtcyBvZiA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHN1 cHByZXNzaW5nIHRoZSByZXNwb25zZXMgb24gaXRzIG93biBpcyBzb21ldGhpbmcgc3BlY2lhbCBh bmQsIDwvdHQ+PGJyPg0KPHR0PiZndDsgZ2VuZXJhbGx5IHNwZWFraW5nLCB0aGUgY2xpZW50cyBh cmUgbm90IGF3YXJlIG9mIHN1Y2ggc3BlY2lhbCBiZWhhdmlvdXIuICZuYnNwOyA8L3R0Pg0KPGJy Pg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBTbywgaXQgd291bGQgYmUganVzdGlmaWVk IHRvIGhhbmRsZSB0aGUgc2l0dWF0aW9uIGF0IHRoZSBzZXJ2ZXIncyA8L3R0Pjxicj4NCjx0dD4m Z3Q7IGVuZC4gSGVyZSBpcyB0aGUgaWRlYTogPC90dD48YnI+DQo8dHQ+Jmd0OyBXaGlsZSBOby1S ZXNwb25zZSBpcyB0byBleHByZXNzZXMgY2xpZW50J3MgZGlzLWludGVyZXN0IGluIHNvbWUgb3Ig PC90dD48YnI+DQo8dHQ+Jmd0OyBhbGwgb2YgdGhlIHJlc3BvbnNlcyBkZXBlbmRpbmcgb24gdGhl IG9wdGlvbiB2YWx1ZSwgaXQgaXMgYWxzbyB0cnVlIDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhhdCB0 aGUgb3B0aW9uIGF1dG9tYXRpY2FsbHkgZXhwcmVzc2VzIGludGVyZXN0IGluIGFsbCBvdGhlciA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IHJlc3BvbnNlcyAobWFya2VkIGJ5IDAncyBpbiB0aGUgcmVzcGVj dGl2ZSBwb3NpdGlvbnMpLiBUaGUgY2xpZW50IGlzPC90dD48YnI+DQo8dHQ+Jmd0OyBnb2luZyB0 byB3YWl0IGZvciB0aGVzZSByZXNwb25zZXMgdXB0byBhIGdpdmVuIHRpbWVvdXQuIE5vdywgaWYg dGhlIDwvdHQ+PGJyPg0KPHR0PiZndDsgc2VydmVyIGJlaGF2aW91ciBpcyBtb2RpZmllZCBsaWtl IHRoaXMgOiAmcXVvdDtJIGhhdmUgY2xvc2VkIG15IGRvb3IgZm9yIDwvdHQ+PGJyPg0KPHR0PiZn dDsgYWxsIG91dCBnb2luZyByZXNwb25zZS4gKipCVVQqKiwgaWYgSSBzZWUgYSBmZWxsb3cgcmVx dWVzdGluZyB3aXRoIDwvdHQ+PGJyPg0KPHR0PiZndDsgTm8tUmVzcG9uc2UgYW5kIGtlZXBpbmcg d2luZG93cyBvcGVuIHRvIHNvbWUgcmVzcG9uc2VzIHRoZW4gSSBhc3N1bWU8L3R0Pjxicj4NCjx0 dD4mZ3Q7IHRoYXQgdGhpcyBndXkgcmVhbGx5IG5lZWRzIHRob3NlIGtpbmQgb2YgcmVzcG9uc2Vz LiBJbiB0aGF0IGNhc2UgbGV0PC90dD48YnI+DQo8dHQ+Jmd0OyBtZSBiZSBsaW5pZW50IGFuZCBs ZXQgbWUgb3BlbiB0aGUgZG9vciBmb3Igc3VjaCByZXNwb25zZXMuIFRoaXMgPC90dD48YnI+DQo8 dHQ+Jmd0OyBmZWxsb3cgbXVzdCBiZSBhdmFpbGFibGUgdG8gbGlzdGVuIHRvIHRoZW0gYXMgcGVy IHRoZSBwcmVzY3JpYmVkIDwvdHQ+PGJyPg0KPHR0PiZndDsgYmVoYXZpb3VyIGluIHRoZSBOby1S ZXNwb25zZSBzcGVjaWZpY2F0aW9uLiZxdW90OyAmbmJzcDsgPC90dD48YnI+DQo8dHQ+Jmd0OyA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IE1hbmRhdGluZyBzdWNoIHNlcnZlciBiZWhhdmlvdXIgZnJvbSB0 aGUgY2xpZW50IHNpZGUgd2lsbCBiZSBhIGJpdCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IG91dC1vZi1z eW5jIHdpdGggdGhlIHNwaXJpdCBvZiB0aGUgc3BlY2lmaWNhdGlvbi4gPC90dD48YnI+DQo8dHQ+ Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFJlZ2FyZHM8L3R0Pjxicj4NCjx0dD4mZ3Q7IEFiaGlq YW4gQmhhdHRhY2hhcnl5YTwvdHQ+PGJyPg0KPHR0PiZndDsgQXNzb2NpYXRlIENvbnN1bHRhbnQ8 L3R0Pjxicj4NCjx0dD4mZ3Q7IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIElu ZGlhPC90dD48YnI+DQo8dHQ+Jmd0OyBUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPC90dD48YnI+ DQo8dHQ+Jmd0OyBNYWlsdG86IDxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFA dGNzLmNvbSI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L2E+PC90dD48YnI+DQo8dHQ+ Jmd0OyBXZWJzaXRlOiA8L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LnRjcy5jb20vIj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHA6Ly93d3cudGNzLmNvbTwvc3Bh bj48L3R0PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L3R0Pjxicj4NCjx0dD4mZ3Q7IEV4cGVyaWVuY2UgY2Vy dGFpbnR5LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJVCBTZXJ2aWNlczwvdHQ+PGJyPg0K PHR0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtCdXNpbmVzcyBTb2x1dGlvbnM8L3R0 Pjxicj4NCjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q29uc3VsdGluZzwvdHQ+ PGJyPg0KPHR0PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+ Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgRnJvbTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7RGlqaywgRXNrbyZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbSI+ZXNrby5kaWprQHBoaWxpcHMuY29tPC9hPiZn dDsNCjwvdHQ+PGJyPg0KPHR0PiZndDsgVG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Fi aGlqYW4gQmhhdHRhY2hhcnl5YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hh cnl5YUB0Y3MuY29tIj5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvYT4mZ3Q7DQo8L3R0 Pjxicj4NCjx0dD4mZ3Q7IENjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOZXZpbCBCcm93 bmxlZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmciPnJmYy1pc2VA cmZjLWVkaXRvci5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5v cmclMjBXRyI+Y29yZUBpZXRmLm9yZyBXRzwvYT4mcXVvdDsgJmx0OzwvdHQ+PGJyPg0KPHR0PiZn dDsgPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0OyA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IERhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzA0LzIy LzIwMTYgMDU6NDMgUE0gPC90dD48YnI+DQo8dHQ+Jmd0OyBTdWJqZWN0OiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gdG8g KmVuYWJsZSogcmVzcG9uc2VzPC90dD48L3NwYW4+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7 IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4m Z3Q7IEhlbGxvIEFiaGlqYW4sPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7 IGluIG91ciBwcm9qZWN0IHdlIHNlZSBhIGNsZWFyIHVzZSBjYXNlIG9mIHVzaW5nIHRoZSBOby1S ZXNwb25zZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IE9wdGlvbiB0byAqZW5hYmxlKiBjZXJ0YWluIHJl c3BvbnNlcyB0aGF0IGFyZSBieSBkZWZhdWx0IHN1cHByZXNzZWQuPC90dD48YnI+DQo8dHQ+Jmd0 OyBDb0FQIGFsbG93cyBzdXBwcmVzc2lvbiBvZiBtdWx0aWNhc3QgcmVzcG9uc2VzIGJ5IGRlZmF1 bHQsIHdoaWNoIGlzIDwvdHQ+PGJyPg0KPHR0PiZndDsgd2hhdCB3ZSB1c2UgZm9yIGEgbGlnaHRp bmcgbXVsdGljYXN0IHVzZSBjYXNlLiBIb3dldmVyIGZvciA8L3R0Pjxicj4NCjx0dD4mZ3Q7IGRp YWdub3N0aWMgdXNhZ2Ugd2UnZCBsaWtlIHRvIGVuYWJsZSB0aGVzZSByZXNwb25zZXMgYWdhaW4g dXNpbmcgdGhlPC90dD48YnI+DQo8dHQ+Jmd0OyBOby1SZXNwb25zZSBvcHRpb24gd2hpY2ggaXMg cGVyZmVjdGx5IHN1aXRlZCBmb3IgdGhhdC4gSG93ZXZlciwgdGhlIDwvdHQ+PGJyPg0KPHR0PiZn dDsgZHJhZnQgdGV4dCBjdXJyZW50bHkgb25seSB0YWxrcyBhYm91dCBzdXBwcmVzc2luZyByZXNw b25zZXMgKG5vdCBlbmFibGluZykuPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4m Z3Q7IEhlbmNlIG15IHJlcXVlc3Q6IGNvdWxkIHdlIG1vZGlmeS9hZGQgc29tZSB0ZXh0IHRvIHNo b3cgdGhhdCBhbHNvIDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhlIG9wdGlvbiBjYW4gYmUgdXNlZCB0 byBlbmFibGUgcmVzcG9uc2VzIGluIGNhc2Ugd2hlcmUgdGhleSBhcmUgPC90dD48YnI+DQo8dHQ+ Jmd0OyBub3JtYWxseSAoYnkgZGVmYXVsdCAtLSBzZXJ2ZXIgZGVjaXNpb24pIHN1cHByZXNzZWQ/ PC90dD48YnI+DQo8dHQ+Jmd0OyBKdXN0IHRvIGNsYXJpZnkgc3VjaCB1c2FnZTsgd2hpY2ggaXMg cXVpdGUgdXNlZnVsIGluIG15IHZpZXcuPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0 dD4mZ3Q7IHJlZ2FyZHM8L3R0Pjxicj4NCjx0dD4mZ3Q7IEVza288L3R0Pjxicj4NCjx0dD4mZ3Q7 IDwvdHQ+PGJyPg0KPHR0PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0 Pjxicj4NCjx0dD4mZ3Q7IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdl IG1heSBiZSBjb25maWRlbnRpYWwgYW5kIDwvdHQ+PGJyPg0KPHR0PiZndDsgbGVnYWxseSBwcm90 ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIDwvdHQ+ PGJyPg0KPHR0PiZndDsgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3Ig PC90dD48YnI+DQo8dHQ+Jmd0OyByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHVubGF3ZnVsLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg PC90dD48YnI+DQo8dHQ+Jmd0OyBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBh bGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLjwvdHQ+PC9zcGFuPg0KPGJyPg0KPHR0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ID09PT09LS0tLS09PT09PS0tLS0t PT09PT08L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsPC90dD48YnI+DQo8dHQ+Jmd0OyBtZXNz YWdlIGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBtYXkgY29udGFpbiA8L3R0Pjxicj4NCjx0dD4m Z3Q7IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIDwv dHQ+PGJyPg0KPHR0PiZndDsgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1p bmF0aW9uLCB1c2UsIDwvdHQ+PGJyPg0KPHR0PiZndDsgcmV2aWV3LCBkaXN0cmlidXRpb24sIHBy aW50aW5nIG9yIGNvcHlpbmcgb2YgdGhlIDwvdHQ+PGJyPg0KPHR0PiZndDsgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgPC90dD48YnI+DQo8dHQ+Jmd0OyBhbmQv b3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIDwvdHQ+PGJy Pg0KPHR0PiZndDsgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9y IHRlbGVwaG9uZSBhbmQgPC90dD48YnI+DQo8dHQ+Jmd0OyBpbW1lZGlhdGVseSBhbmQgcGVybWFu ZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIDwvdHQ+PGJyPg0KPHR0PiZndDsgYW5kIGFueSBhdHRh Y2htZW50cy4gVGhhbmsgeW91PC90dD48L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwg YW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBp cyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkDQogdGhhdCBhbnkg dXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBt ZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRl ciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFs IG1lc3NhZ2UuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_dcc875e1f79c461c9293e37107a04a9eHE1PR9001MB0170MGDPHGem_-- From nobody Mon May 2 14:07:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D569912D65D; Mon, 2 May 2016 14:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcbTamJ7mK10; Mon, 2 May 2016 14:07:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D70512D65B; Mon, 2 May 2016 14:07:44 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u42L7gsP024820 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 May 2016 16:07:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Carsten Bormann" Date: Mon, 02 May 2016 16:07:42 -0500 Message-ID: <36297CC7-050B-437F-BE50-D591BFA31210@nostrum.com> In-Reply-To: <5723AFEE.3060608@tzi.org> References: <20160421140904.19594.51871.idtracker@ietfa.amsl.com> <5723AFEE.3060608@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Ben Campbell's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 21:07:46 -0000 Hi, I think this addresses most of my comments, save the ones I already said I would not push. But I want to make sure I understand one point correctly (below): On 29 Apr 2016, at 14:03, Carsten Bormann wrote: [...] > > Reinforced by new text in the intro to section 2 (page 5). > >> - 2.5, 2nd paragraph, last sentence: >> Should I read this to mean that the reduction in block size is >> retroactive? That could use some elaboration. (I thought I read >> comments >> in the examples suggesting such a reduction would _not_ be >> retroactive). > > I'm still not sure how to address this. Let me restate the question in the form of an example. Let's say a client requests a block size of N, and receives the block 0. But the server indicates a preference for a block size if N/2. The client honors that preference on the next transfer. Is the next block numbered 1 or 2? I understand from this sentence the answer would be the latter. That seems to indicate the first block is recounted as 2 blocks--which is what I mean by retroactive. But I _thought_ I had read text elsewhere in the document indicating the block numbering would stay the same, implying that the client would count a block 0 of size N and a block 1 of size N/2. But I cannot find that text now, and may have misread something. The rest of the document is pretty clear that block sizes all have to be the same. So this is probably okay as it is. [...] From nobody Tue May 3 01:40:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0DA12D0A1 for ; Tue, 3 May 2016 01:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elGWcy1ON0jP for ; Tue, 3 May 2016 01:40:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91AF12D643 for ; Tue, 3 May 2016 01:40:00 -0700 (PDT) Received: from localhost ([::1]:53687 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1axVs1-0005gY-Vl; Tue, 03 May 2016 01:39:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Tue, 03 May 2016 08:39:53 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/409 Message-ID: <065.865b9837ab99aed6c309ae6125f98820@trac.tools.ietf.org> X-Trac-Ticket-ID: 409 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, Hannes.Tschofenig@gmx.net, achim.kraus@bosch-si.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 Resent-To: draft-ietf-core-block@ietf.org Resent-Message-Id: <20160503084000.D91AF12D643@ietfa.amsl.com> Resent-Date: Tue, 3 May 2016 01:40:00 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP Connections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.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 2016 08:40:05 -0000 #409: CoAP over TCP: Multiple Simultaneous TCP Connections CoAP has been designed to support small data transmissions. For device management it is, however, necessary to also deal with the transmission of larger payloads as well. Such larger payloads may be, for example, firmware/software updates. The maximum payload size of CoAP is determined by the length field of the length field provided in the UDP header. It is ~64KB. For practical purposes the usable payload size is, however, much smaller due to performance issues introduced by fragmentation provided at the IP layer and/or adaption layers. For this reason the block-wise transfer mechanism has been defined. Block-wise transfer is a mechanism that can be used to transfer larger payloads by chunking them into smaller parts (each part with a maximum size of 1024 bytes each). The block-wise transfer depends on CoAP and therefore uses the stop-and-wait defined in RFC 7252 (as a simple congestion control mechanism). The transfer of large payloads does, however, not block the transmission of other pending messages since they can easily be interleaved due to the nature of the block-wise transfer design. When large payloads are transferred by CoAP over TCP then a large transfer blocks any other requests unless multiple TCP connections are opened. The question is therefore what should the CoAP over TCP state regarding the use of multiple TCP connections? Using multiple TCP connection increases RAM requirements; a single TCP connection introduces head-of-line blocking. When CoAP over TCP is used with Block-wise transport in combination with BERT, see https://tools.ietf.org/html/draft-bormann-core-block-bert-00, then the previously described problem of large transfers that block other ongoing activities is (partially) mitigated. BERT changes the interpretation of the length information and changes it as a multiple of 1024 bytes (and thus increasing the size of the chunks). The question is therefore whether CoAP over TCP should recommend the use of Block-wise Transfer for large file transfers and incorporate BERT into the CoAP over TCP draft. (I would like to thank Achim Kraus for raising this issue during the OMA face-to-face meeting.) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core- Hannes.Tschofenig@gmx.net | block@tools.ietf.org Type: protocol defect | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: core From nobody Tue May 3 05:01:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C610F12D763; Tue, 3 May 2016 05:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPFpB_6ei7kE; Tue, 3 May 2016 05:01:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D973912D112; Tue, 3 May 2016 05:01:45 -0700 (PDT) Received: from localhost ([::1]:35631 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1axZ1G-0006fc-SE; Tue, 03 May 2016 05:01:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Tue, 03 May 2016 12:01:38 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/409#comment:1 Message-ID: <080.3b258d7ae5f6ebaebfbfb0c750f05c47@trac.tools.ietf.org> References: <065.865b9837ab99aed6c309ae6125f98820@trac.tools.ietf.org> X-Trac-Ticket-ID: 409 In-Reply-To: <065.865b9837ab99aed6c309ae6125f98820@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, achim.kraus@bosch-si.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 Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org Resent-Message-Id: <20160503120145.D973912D112@ietfa.amsl.com> Resent-Date: Tue, 3 May 2016 05:01:45 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #409 (coap-tcp-tls): CoAP over TCP: Multiple Simultaneous TCP Connections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.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 2016 12:01:52 -0000 #409: CoAP over TCP: Multiple Simultaneous TCP Connections Changes (by Hannes.Tschofenig@gmx.net): * owner: draft-ietf-core-block@tools.ietf.org => draft-ietf-core-coap-tcp- tls@ietf.org * type: protocol defect => protocol enhancement * component: block => coap-tcp-tls -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core-coap- Hannes.Tschofenig@gmx.net | tcp-tls@ietf.org Type: protocol enhancement | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: core From nobody Tue May 3 12:53:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956812D859 for ; Tue, 3 May 2016 12:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0t7G8oXhZg0 for ; Tue, 3 May 2016 12:52:56 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4D312D0DC for ; Tue, 3 May 2016 12:52:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQDg/ihX/wQXEqxehAt9uiEBDYFxBBcBCoVuAhyBXRQBAQEBAQEBgQyEQQEBAQMBGglLCwULCwcGBAMBAQEhBwMCAgJECQgGCwgbiAcWqnQBAQFlkHkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhHdnhQ+EIgEBBSILCQyCHDgTGIIuBY5LhFmEcoFVhCeFY4QhFzeDf4hdhiSJDh4BAYQ1ZIZ+BwKBNQEBAQ X-IPAS-Result: A2DPAQDg/ihX/wQXEqxehAt9uiEBDYFxBBcBCoVuAhyBXRQBAQEBAQEBgQyEQQEBAQMBGglLCwULCwcGBAMBAQEhBwMCAgJECQgGCwgbiAcWqnQBAQFlkHkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhHdnhQ+EIgEBBSILCQyCHDgTGIIuBY5LhFmEcoFVhCeFY4QhFzeDf4hdhiSJDh4BAYQ1ZIZ+BwKBNQEBAQ X-IronPort-AV: E=Sophos;i="5.24,573,1454956200"; d="scan'208";a="80330753" X-DISCLAIMER: FALSE In-Reply-To: References: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com> To: "Dijk, Esko" MIME-Version: 1.0 X-KeepSent: BA05A6EC:9C238DC2-65257FA8:006A8F53; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 4 May 2016 01:22:45 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF956 | April 21, 2016) at 05/04/2016 01:22:47, Serialize complete at 05/04/2016 01:22:47 Content-Type: multipart/alternative; boundary="=_alternative 006D32BB65257FA8_=" Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 19:53:01 -0000 This is a multipart message in MIME format. --=_alternative 006D32BB65257FA8_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRXNrbywNClRoYW5rcyBmb3IgcmVzcG9uZGluZy4gVGhlIGRpc2N1c3Npb24gaXMgbGVhZGlu ZyB0byBleGFjdGx5IHdoYXQgSSB3YXMgDQp0aGlua2luZyBhYm91dC4NClNvLCBpZiB3ZSBlbmhh bmNlIHRoZSB0ZXh0IGFzIGJlbG93IHdvdWxkIGl0IGJlIGdvb2QgZm9yIHRoZSBwdXJwb3NlPyAN ClBsZWFzZSBjb21tZW50Lg0KDQoiVGhlIHNlcnZlciBNVVNUIHNlbmQgYmFjayByZXNwb25zZXMg b2YgdGhlIGNsYXNzZXMgZm9yIHdoaWNoIHRoZSBjbGllbnQgDQpoYXMgbm90IGV4cHJlc3NlZCBh bnkgZGlzLWludGVyZXN0LiBUaGVyZSBhcmUgaW5zdGFuY2VzIHdoZXJlIGEgc2VydmVyLCBvbiAN Cml0cyBvd24sIG1heSBkZWNpZGUgdG8gc3VwcHJlc3MgcmVzcG9uc2VzIGxpa2UgdGhlIG11bHRp Y2FzdCBzZXJ2ZXJzIGFzIA0KZGVzY3JpYmVkIGluIHNlY3Rpb24gMi43IG9mICBbUkZDNzM5MF0u IElmIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMgYSByZXF1ZXN0IA0Kd2l0aCBOby1SZXNwb25zZSBzaG93 aW5nICdpbnRlcmVzdCcgaW4gY2VydGFpbiByZXNwb25zZXMgdGhlbiBzdWNoIA0KYmVoYXZpb3Vy IG9mIHN1cHByZXNzaW5nIHJlc3BvbnNlcyBieSBzZXJ2ZXJzIE1VU1QgYmUgb3Zlci1yaWRkZW4g Zm9yIA0KdGhvc2UgcmVzcG9uc2VzIHdoaWNoIGFyZSBvZiBpbnRlcmVzdCB0byB0aGUgY2xpZW50 LiBUaGUgc2VydmVyIE1VU1Qgc2VuZCANCnRob3NlIHJlc3BvbnNlcyBmb3Igd2hpY2ggdGhlIGNs aWVudCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzaW50ZXJlc3QgDQooaS5lLiwgZXhwcmVzc2Vk ICdpbnRlcmVzdCcpLiBTbywgZm9yIGV4YW1wbGUsIGlmIGEgbXVsdGljYXN0IHNlcnZlciANCmRl Y2lkZXMgdG8gc3VwcHJlc3MgYWxsIHJlc3BvbnNlcyBhbmQgcmVjZWl2ZXMgYSByZXF1ZXN0IHdp dGggTm8tUmVzcG9uc2UgDQpvcHRpb24gZXhwcmVzc2luZyBkaXNpbnRlcmVzdCBvbmx5IGluIHN1 Y2Nlc3MgcmVzcG9uc2VzIGJ1dCBub3QgaW4gZXJyb3JzIA0KdGhlbiB0aGUgc2VydmVyIE1VU1Qg c2VuZCBiYWNrIGEgcmVzcG9uc2UgaWYgdGhlIGNvbmNlcm5lZCByZXF1ZXN0IGNhdXNlcyANCmFu IGVycm9yLiAiDQoNCiBIb3BlZnVsbHksIHRoaXMgd2lsbCBzb2x2ZSBhIHBvdGVudGlhbCBwcm9i bGVtIHdoZW4gdGhlIGNsaWVudCBhY3R1YWxseSANCndhbnRzIHRvIGRlYnVnIHRoZSBsaWdodHMg dGhyb3VnaCBncmFudWxhciBOby1SZXNwb25zZSBidXQgdGhlIHNlcnZlcnMgDQpkZWNpZGUgbm90 IHRvIHNlbmQgYSByZXNwb25zZSBhcyBkZWZhdWx0IGJlaGF2aW91ciBhbmQgdGhlIGNsaWVudCBp cyBuZXZlciANCmF3YXJlIG9mIHRoYXQuIEhvd2V2ZXIsIGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhl IGFib3ZlIGNvdWxkIGJlIA0KcmVjaXByb2NhdGVkIGJ5IHNvbWUgc3BlY2lmaWNhdGlvbiB3aGlj aCBkZWFscyB3aXRoIHRoZSBzZXJ2ZXItc2lkZSANCmJlaGF2aW91ci4NCg0KV2FpdGluZyB0byBo ZWFyIGZyb20geW91Lg0KDQpSZWdhcmRzDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWENCkFzc29jaWF0 ZSBDb25zdWx0YW50DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0K VGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlcw0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFA dGNzLmNvbQ0KV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgSVQgU2Vy dmljZXMNCiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAg ICAgICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KDQoiRGlqaywgRXNrbyIgPGVza28uZGlqa0BwaGlsaXBzLmNv bT4gd3JvdGUgb24gMDUvMDMvMjAxNiAwMToyNTowMSBBTToNCg0KPiBGcm9tOiAiRGlqaywgRXNr byIgPGVza28uZGlqa0BwaGlsaXBzLmNvbT4NCj4gVG86IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSA8 YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+DQo+IENjOiAiY29yZUBpZXRmLm9yZyBXRyIg PGNvcmVAaWV0Zi5vcmc+LCBOZXZpbCBCcm93bmxlZSA8cmZjLWlzZUByZmMtDQo+IGVkaXRvci5v cmc+DQo+IERhdGU6IDA1LzAzLzIwMTYgMDE6MjUgQU0NCj4gU3ViamVjdDogUkU6IFVzaW5nIGRy YWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiANCnJlc3BvbnNlcw0K PiANCj4gSGksDQo+IA0KPiA+ICJUaGUgc2VydmVyIE1VU1Qgc2VuZCBiYWNrIHJlc3BvbnNlcyBv ZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2ggdGhlIA0KPiBjbGllbnQgaGFzIG5vdCBleHByZXNzZWQg YW55IGRpcy1pbnRlcmVzdC4iIC0gDQo+IFRoaXMgY292ZXJzIHBhcnQgb2YgbXkgdXNlIGNhc2U7 IGhvd2V2ZXIgaXQgaXMgbm90IGNsZWFyIGhvdyB0aGlzIA0KPiAiTVVTVCIgaW50ZXJhY3RzIHdp dGggdGhlICJNQVkgc3VwcHJlc3MiIG9mIFJGQyA3MjUyIGZvciB0aGUgDQo+IG11bHRpY2FzdCBj YXNlLiBDYW4gdGhlIHNlcnZlciBzdGlsbCBkZWNpZGUgdG8gc3VwcHJlc3MgdGhlIA0KPiBtdWx0 aWNhc3QgcmVzcG9uc2UgZXZlbiBpZiB0aGUgTm8tUmVzcG9uc2UgT3B0aW9uIHNlbnQgYnkgdGhl IGNsaWVudA0KPiBzYXlzIG5vdCB0bz8gVGhpbmtpbmcgYWJvdXQgaXQsIGl0IHdvdWxkIGJlIHBl cmhhcHMgZ29vZCBpZiBkcmFmdC0NCj4gdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHdvdWxk IG1ha2UgdGhhdCBjbGVhci4gVGhlICJNVVNUIiBhbmQgDQo+IHRoZSB1c2UgY2FzZSA0LjIuMSBz dWdnZXN0IHRoYXQgdGhlIGRlZmF1bHQgc3VwcHJlc3Npb24gY2hvaWNlcyBvZiANCj4gdGhlIHNl cnZlciBhcmUgb3ZlcnJpZGRlbiBieSB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9uIGJ1dCB0aGF0IGlz IG5vdCANCj4gd3JpdHRlbiBleHBsaWNpdGx5IHlldC4gIElmIHRoYXQgaXMgdGhlIGNhc2UsIG15 IHVzZSBjYXNlIGlzIGZ1bGx5IA0KPiBjb3ZlcmVkIGJ5IHlvdXIgZHJhZnQgSSB0aGluay4NCj4g DQo+IEFuIHVwZGF0ZSBvciBzdWNjZXNzb3IgdG8gdGhlIEdyb3VwY29tbSBSRkMgY291bGQgaW5k ZWVkIGRlc2NyaWJlIA0KPiBob3cgdGhlIE5vLVJlc3BvbnNlIE9wdGlvbiBjYW4gYmUgdXNlZCBm b3IgbXVsdGljYXN0IHVzZSBjYXNlcy4gSXQgDQo+IHdvdWxkIGJlIGdyZWF0IGlmIHRoYXQgY291 bGQgYmUgZG9uZSB3aXRob3V0IG5lZWRpbmcgZnVydGhlciANCj4gbW9kaWZpY2F0aW9ucyB0byBk cmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24hDQo+IA0KPiByZWdhcmRzDQo+IEVza28N Cj4gDQo+IEZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRh Y2hhcnl5YUB0Y3MuY29tXSANCj4gU2VudDogTW9uZGF5LCBNYXkgMDIsIDIwMTYgNToxOQ0KPiBU bzogRGlqaywgRXNrbyA8ZXNrby5kaWprQHBoaWxpcHMuY29tPg0KPiBDYzogY29yZUBpZXRmLm9y ZyBXRyA8Y29yZUBpZXRmLm9yZz47IE5ldmlsIEJyb3dubGVlIA0KPHJmYy1pc2VAcmZjLWVkaXRv ci5vcmc+DQo+IFN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1v cHRpb24gdG8gKmVuYWJsZSogDQpyZXNwb25zZXMNCj4gSW1wb3J0YW5jZTogSGlnaA0KPiANCj4g SGkgRXNrbywgDQo+IFRoZSBleGlzdGluZyB2ZXJzaW9uIC0xNiBoYXMgdGhlIGZvbGxvd2luZyB0 ZXh0IGluIHNlY3Rpb24gMi4xIChwYWdlIDUpIA0KOiANCj4gIlRoZSBzZXJ2ZXIgTVVTVCBzZW5k IGJhY2sgcmVzcG9uc2VzIG9mIHRoZSBjbGFzc2VzIGZvciB3aGljaCB0aGUgDQo+IGNsaWVudCBo YXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiIgDQo+IFNvLCB0aGF0IHdheSB0aGUg Y2xpZW50IGhhcyBhY3R1YWxseSBleHByZXNzZWQgaXRzIGludGVyZXN0IChvciANCj4gcmVxdWVz dCBmb3IgZW5hYmxlbWVudCkgaW4gYWxsIHRoZSByZXNwb25zZXMgZm9yIHdoaWNoIGl0IGhhcyBu b3QgDQo+IGV4cHJlc3NlZCBleHBsaWNpdCBkaXNpbnRlcmVzdC4gRG9lcyB0aGF0IGhlbHAgdG8g Y29udHJvbCB0aGUgDQo+IHNwZWNpYWwgc2VydmVyLXNpZGUgYmVoYXZpb3VyIGFzIHRoZSBzZXJ2 ZXIga25vd3Mgd2hpY2ggYWxsIA0KPiByZXNwb25zZXMgdGhlIGNsaWVudCBpcyBpbnRlcmVzdGVk IGluIGFuZCBpdCBNVVNUIHNlbmQgYSByZXNwb25zZSANCj4gYmFjayA/IEkgc2hhbGwgc3VibWl0 IGFub3RoZXIgdmVyc2lvbiB3aXRoIHNvbWUgZWRpdG9yaWFsIGNoYW5nZXMgDQo+IGJlZm9yZSB0 aGUgZHJhZnQgZ29lcyB0byBJRVNHLiBTbyB3ZSBoYXZlIHNvbWUgbW9yZSByb29tIGZvciANCj4g bW9kaWZpY2F0aW9uLiBJZiB5b3UgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoaXMgaW4gdGhlIGxp bmUgb2YgdGhlIA0KPiBkaXNjdXNzaW9uIHdlIGFyZSBoYXZpbmcsIHBsZWFzZSBsZXQgdXMga25v dy4gSSBzaGFsbCB3YWl0IGZvciB5b3VyIA0KPiB2aWV3cyBiZWZvcmUgc3VibWl0dGluZyB0aGUg dXBkYXRlZCB2ZXJzaW9uLiANCj4gDQo+IEFueXdheSwgYSBzZXBhcmF0ZSBkcmFmdCAob3IsIHBv c3NpYmx5LCBhbiB1cGRhdGVkIGdyb3VwY29tbSBSRkM/KSANCj4gaXMgYSBnb29kIGlkZWEuIE5v LVJlc3BvbnNlIGFzc3VtZXMgdGhlIHVzdWFsIHJlcXVlc3QvcmVzcG9uc2UgDQo+IHN5bWFudGlj cyBhbmQgaXQgbWFpbmx5IGFkZHJlc3NlcyB0aGUgY2xpZW50IHNpZGUgYmVoYXZpb3VyIGFuZCAN Cj4gaXNzdWVzLiBDb25zaWRlcmluZyBzdWNoIHNwZWNpYWwgYmVoYXZpb3VyIG9mIGdyb3VwY29t bSBzZXJ2ZXJzLCBpdCANCj4gd291bGQgYmUgZ29vZCB0byBoYW5kbGUgc2VwYXJhdGVseS4gDQo+ IA0KPiBXYWl0aW5nIHRvIGhlYXIgZnJvbSB5b3UuIA0KPiANCj4gUmVnYXJkcw0KPiBBYmhpamFu IEJoYXR0YWNoYXJ5eWENCj4gQXNzb2NpYXRlIENvbnN1bHRhbnQNCj4gU2NpZW50aXN0LCBJbm5v dmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENCj4gVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlcw0K PiBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQo+IFdlYnNpdGU6IGh0dHA6 Ly93d3cudGNzLmNvbQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBFeHBlcmllbmNlIGNlcnRhaW50eS4gICAgICAgIElUIFNlcnZpY2VzDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgQ29uc3VsdGluZw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiANCj4gDQo+ICJEaWprLCBFc2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPiB3 cm90ZSBvbiAwNS8wMi8yMDE2IDAzOjEwOjI0IEFNOg0KPiANCj4gPiBGcm9tOiAiRGlqaywgRXNr byIgPGVza28uZGlqa0BwaGlsaXBzLmNvbT4gDQo+ID4gVG86IEFiaGlqYW4gQmhhdHRhY2hhcnl5 YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+IA0KPiA+IENjOiAiY29yZUBpZXRmLm9y ZyBXRyIgPGNvcmVAaWV0Zi5vcmc+LCBOZXZpbCBCcm93bmxlZSA8cmZjLWlzZUByZmMtDQo+ID4g ZWRpdG9yLm9yZz4gDQo+ID4gRGF0ZTogMDUvMDIvMjAxNiAwMzoxMCBBTSANCj4gPiBTdWJqZWN0 OiBSRTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUq IA0KcmVzcG9uc2VzIA0KPiA+IA0KPiA+IEhlbGxvIEFiaGlqYW4sIA0KPiA+IA0KPiA+ID4gTWFu ZGF0aW5nIHN1Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBjbGllbnQgc2lkZSB3aWxsIGJl IGEgYml0DQo+ID4gb3V0LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZpY2F0 aW9uLiANCj4gPiBUaGlzIGlzIG5vdCBmdWxseSBjbGVhciB0byBtZSB5ZXQg4oCmIHRoZSBjbGll bnQgZG9lcyBub3QgbWFuZGF0ZSANCj4gPiBhbnl0aGluZyBmcm9tIHRoZSBzZXJ2ZXI7IGl0IGp1 c3QgZXhwcmVzc2VzIGl0cyBpbnRlcmVzdCAoMC1iaXRzKSANCj4gPiBhbmQgZGlzaW50ZXJlc3Qg KDEtYml0cykuIFRoZSBzZXJ2ZXIgY2FuIGFsd2F5cyBub3QgcGFyc2UgdGhlIG9wdGlvbg0KPiA+ IChlbGVjdGl2ZSkgb3IgY2hvb3NlIG5vdCB0byBib3RoZXIgYWJvdXQgaXQuIA0KPiA+IFRoaXMg ZG9lcyBrZWVwIHRoZSBjbGllbnQgd2FpdGluZyBmb3IgYSBwb3NzaWJsZSByZXNwb25zZSB0aGF0 IG5ldmVyDQo+ID4gY29tZXM7IGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGluIHRoZSBnZW5lcmFsIG11 bHRpY2FzdCBjYXNlIDogdGhlIA0KPiA+IGNsaWVudCBjYW4gbmV2ZXIga25vdyBpZiBvciB3aGVu IGEgcmVzcG9uc2Ugd2lsbCBjb21lLCB0aGUgc2VydmVyIA0KPiA+IE1BWSBhbHdheXMgY2hvb3Nl IHRvIG5vdCByZXNwb25kLiANCj4gPiANCj4gPiBTbyB3aGF0IEkgcHJvcG9zZSBpcyB0byB1c2Ug dGhlICJpbmRpY2F0aW9uIG9mIGludGVyZXN0IiB0byBzcGVjaWZpYw0KPiA+IHJlc3BvbnNlIGNs YXNzZXMgaW4gYSBuZXcgd2F5OyBuYW1lbHkgdG8gZW5hYmxlIGNlcnRhaW4gcmVzcG9uc2UgDQo+ ID4gY2xhc3NlcyB0aGF0IGFyZSBzdXBwcmVzc2VkIGJ5IGRlZmF1bHQuICBJdCBqdXN0IGhhcHBl bnMgdGhhdCB0aGUgDQo+ID4gc2FtZSBPcHRpb24gc3ludGF4IGlzIHZlcnkgd2VsbCBzdWl0ZWQg Zm9yIHRoYXQgcHVycG9zZS4gQSBzZXBhcmF0ZSANCj4gPiBkcmFmdCBjb3VsZCBiZSB3cml0dGVu IGZvciB0aGF0IHBlcmhhcHMgaWYgeW91IHRoaW5rIGl0IGRvZXMgbm90IGZpdA0KPiA+IGluIGRy YWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiBvciBpZiBpdCBpcyB0b28gbGF0ZSBmb3Ig dGhhdC4gDQo+ID4gVGhlIHdlIGNhbiBwb2ludCB0byB0aGUgc3ludGF4IG9mIHRoZSBOby1SZXNw b25zZSBPcHRpb24gYW5kIHJlLXVzZSANCj4gPiBpdCBjb21wbGV0ZWx5LiANCj4gPiANCj4gPiBy ZWdhcmRzIA0KPiA+IEVza28gDQo+ID4gDQo+ID4gRnJvbTogQWJoaWphbiBCaGF0dGFjaGFyeXlh IFttYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb21dIA0KPiA+IFNlbnQ6IEZyaWRh eSwgQXByaWwgMjIsIDIwMTYgMTc6MTcNCj4gPiBUbzogRGlqaywgRXNrbyA8ZXNrby5kaWprQHBo aWxpcHMuY29tPg0KPiA+IENjOiBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPjsgTmV2 aWwgQnJvd25sZWUgDQo8cmZjLWlzZUByZmMtZWRpdG9yLm9yZw0KPiA+DQo+ID4gU3ViamVjdDog UmU6IFVzaW5nIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiAN CnJlc3BvbnNlcyANCj4gPiANCj4gPiBIaSBFc2tvLCANCj4gPiBUaGFua3MgZm9yIHlvdXIgbWFp bC4gDQo+ID4gRmlyc3Qgb2YgYWxsIGxldCBtZSBqdXN0IGJyaW5nIHRoaXMgdG8geW91ciAoYXMg d2VsbCBhcyB0aGUgbWFpbGluZyANCj4gPiBsaXN0J3MpIG5vdGljZSB0aGF0IHRoZSBsYXRlc3Qg dmVyc2lvbiBvZiB0aGUgZHJhZnQgaXM6IA0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS0NCj4gb3B0aW9uLTE2LnR4dA0K PiA+IA0KPiA+IFRoaXMgdmVyc2lvbiAib2ZmaWNpYWxseSIgY2xvc2VzIHRoZSB0ZWNobmljYWwg cmV2aWV3cyBhbmQgaXMgd2l0aCANCj4gPiB0aGUgUkZDIGVkaXRvciB0aHJvdWdoIHRoZSBJUyB0 cmFjay4gDQo+ID4gDQo+ID4gTm93IGNvbWluZyB0byB5b3VyIHVzZSBjYXNlIChhbmQgaW5kZWVk IGl0IGlzIGFuIGludGVyZXN0aW5nIG9uZSkgDQo+ID4gb25lIHRoaW5nIHRoYXQgd2Ugc2hvdWxk IGNvbnNpZGVyIGlzIHRoYXQgdGhlIE5vLVJlc3BvbnNlIG9wdGlvbiB3YXMNCj4gPiBkZWxpYmVy YXRlbHkgZGVzaWduZWQgbm90IHRvIG1hbmRhdGUgYW55dGhpbmcgZm9yIHRoZSBzZXJ2ZXIgc2lk ZSANCj4gPiBtYWlubHkgdG8gZW5zdXJlIHRoYXQgaXQgZG9lcyBub3QgZGlzcnVwdCB0aGUgbWFu eSB1c2VmdWxuZXNzIG9mIHRoZQ0KPiA+IHVzdWFsIHJlcXVlc3QvcmVzcG9uc2Ugc3ltYW50aWNz LiBUaGUgZHJhZnQgYWxsIGFsb25nIGRlYWxzIHdpdGggdGhlDQo+ID4gcmVxdWVzdGluZyBjbGll bnQncyBiZWhhdmlvdXIgYW5kIGl0cyBleHByZXNzaW9uIG9mIGludGVyZXN0IHRvIHRoZSANCj4g PiBzZXJ2ZXIuIFNpbmNlIHRoaXMgb3B0aW9uIGlzIGVsZWN0aXZlIHdlIGxlYXZlIGl0IHVwdG8g dGhlIHNlcnZlciANCj4gPiBpbXBsZW1lbnRhdGlvbiB0byBob25vdXIgdGhlIGNsaWVudCdzIGlu dGVyZXN0LiANCj4gPiANCj4gPiBOb3csIGFzIHBlciB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIHN5 bWFudGljcyB0aGUgcmVzcG9uc2VzIGFyZSANCj4gPiBhbHdheXMgZW5hYmxlZC4gVGhlIGJlaGF2 aW91ciBpbiBncm91cGNvbW0gc2VydmVyIGluIHRlcm1zIG9mIA0KPiA+IHN1cHByZXNzaW5nIHRo ZSByZXNwb25zZXMgb24gaXRzIG93biBpcyBzb21ldGhpbmcgc3BlY2lhbCBhbmQsIA0KPiA+IGdl bmVyYWxseSBzcGVha2luZywgdGhlIGNsaWVudHMgYXJlIG5vdCBhd2FyZSBvZiBzdWNoIHNwZWNp YWwgDQpiZWhhdmlvdXIuIA0KPiA+IA0KPiA+IFNvLCBpdCB3b3VsZCBiZSBqdXN0aWZpZWQgdG8g aGFuZGxlIHRoZSBzaXR1YXRpb24gYXQgdGhlIHNlcnZlcidzIA0KPiA+IGVuZC4gSGVyZSBpcyB0 aGUgaWRlYTogDQo+ID4gV2hpbGUgTm8tUmVzcG9uc2UgaXMgdG8gZXhwcmVzc2VzIGNsaWVudCdz IGRpcy1pbnRlcmVzdCBpbiBzb21lIG9yIA0KPiA+IGFsbCBvZiB0aGUgcmVzcG9uc2VzIGRlcGVu ZGluZyBvbiB0aGUgb3B0aW9uIHZhbHVlLCBpdCBpcyBhbHNvIHRydWUgDQo+ID4gdGhhdCB0aGUg b3B0aW9uIGF1dG9tYXRpY2FsbHkgZXhwcmVzc2VzIGludGVyZXN0IGluIGFsbCBvdGhlciANCj4g PiByZXNwb25zZXMgKG1hcmtlZCBieSAwJ3MgaW4gdGhlIHJlc3BlY3RpdmUgcG9zaXRpb25zKS4g VGhlIGNsaWVudCBpcw0KPiA+IGdvaW5nIHRvIHdhaXQgZm9yIHRoZXNlIHJlc3BvbnNlcyB1cHRv IGEgZ2l2ZW4gdGltZW91dC4gTm93LCBpZiB0aGUgDQo+ID4gc2VydmVyIGJlaGF2aW91ciBpcyBt b2RpZmllZCBsaWtlIHRoaXMgOiAiSSBoYXZlIGNsb3NlZCBteSBkb29yIGZvciANCj4gPiBhbGwg b3V0IGdvaW5nIHJlc3BvbnNlLiAqKkJVVCoqLCBpZiBJIHNlZSBhIGZlbGxvdyByZXF1ZXN0aW5n IHdpdGggDQo+ID4gTm8tUmVzcG9uc2UgYW5kIGtlZXBpbmcgd2luZG93cyBvcGVuIHRvIHNvbWUg cmVzcG9uc2VzIHRoZW4gSSBhc3N1bWUNCj4gPiB0aGF0IHRoaXMgZ3V5IHJlYWxseSBuZWVkcyB0 aG9zZSBraW5kIG9mIHJlc3BvbnNlcy4gSW4gdGhhdCBjYXNlIGxldA0KPiA+IG1lIGJlIGxpbmll bnQgYW5kIGxldCBtZSBvcGVuIHRoZSBkb29yIGZvciBzdWNoIHJlc3BvbnNlcy4gVGhpcyANCj4g PiBmZWxsb3cgbXVzdCBiZSBhdmFpbGFibGUgdG8gbGlzdGVuIHRvIHRoZW0gYXMgcGVyIHRoZSBw cmVzY3JpYmVkIA0KPiA+IGJlaGF2aW91ciBpbiB0aGUgTm8tUmVzcG9uc2Ugc3BlY2lmaWNhdGlv bi4iIA0KPiA+IA0KPiA+IE1hbmRhdGluZyBzdWNoIHNlcnZlciBiZWhhdmlvdXIgZnJvbSB0aGUg Y2xpZW50IHNpZGUgd2lsbCBiZSBhIGJpdCANCj4gPiBvdXQtb2Ytc3luYyB3aXRoIHRoZSBzcGly aXQgb2YgdGhlIHNwZWNpZmljYXRpb24uIA0KPiA+IA0KPiA+IFJlZ2FyZHMNCj4gPiBBYmhpamFu IEJoYXR0YWNoYXJ5eWENCj4gPiBBc3NvY2lhdGUgQ29uc3VsdGFudA0KPiA+IFNjaWVudGlzdCwg SW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQo+ID4gVGF0YSBDb25zdWx0YW5jeSBTZXJ2 aWNlcw0KPiA+IE1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20NCj4gPiBXZWJz aXRlOiBodHRwOi8vd3d3LnRjcy5jb20NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IEV4cGVyaWVuY2UgY2VydGFpbnR5LiAgICAgICAgSVQgU2Vy dmljZXMNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KPiA+ ICAgICAgICAgICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4g RnJvbTogICAgICAgICJEaWprLCBFc2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPiANCj4gPiBU bzogICAgICAgIEFiaGlqYW4gQmhhdHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRj cy5jb20+IA0KPiA+IENjOiAgICAgICAgTmV2aWwgQnJvd25sZWUgPHJmYy1pc2VAcmZjLWVkaXRv ci5vcmc+LCAiY29yZUBpZXRmLm9yZyBXRyIgDQo8DQo+ID4gY29yZUBpZXRmLm9yZz4gDQo+ID4g RGF0ZTogICAgICAgIDA0LzIyLzIwMTYgMDU6NDMgUE0gDQo+ID4gU3ViamVjdDogICAgICAgIFVz aW5nIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byANCj4gKmVuYWJsZSogcmVz cG9uc2VzIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEhlbGxvIEFiaGlqYW4sDQo+ID4g DQo+ID4gaW4gb3VyIHByb2plY3Qgd2Ugc2VlIGEgY2xlYXIgdXNlIGNhc2Ugb2YgdXNpbmcgdGhl IE5vLVJlc3BvbnNlIA0KPiA+IE9wdGlvbiB0byAqZW5hYmxlKiBjZXJ0YWluIHJlc3BvbnNlcyB0 aGF0IGFyZSBieSBkZWZhdWx0IHN1cHByZXNzZWQuDQo+ID4gQ29BUCBhbGxvd3Mgc3VwcHJlc3Np b24gb2YgbXVsdGljYXN0IHJlc3BvbnNlcyBieSBkZWZhdWx0LCB3aGljaCBpcyANCj4gPiB3aGF0 IHdlIHVzZSBmb3IgYSBsaWdodGluZyBtdWx0aWNhc3QgdXNlIGNhc2UuIEhvd2V2ZXIgZm9yIA0K PiA+IGRpYWdub3N0aWMgdXNhZ2Ugd2UnZCBsaWtlIHRvIGVuYWJsZSB0aGVzZSByZXNwb25zZXMg YWdhaW4gdXNpbmcgdGhlDQo+ID4gTm8tUmVzcG9uc2Ugb3B0aW9uIHdoaWNoIGlzIHBlcmZlY3Rs eSBzdWl0ZWQgZm9yIHRoYXQuIEhvd2V2ZXIsIHRoZSANCj4gPiBkcmFmdCB0ZXh0IGN1cnJlbnRs eSBvbmx5IHRhbGtzIGFib3V0IHN1cHByZXNzaW5nIHJlc3BvbnNlcyAobm90IA0KZW5hYmxpbmcp Lg0KPiA+IA0KPiA+IEhlbmNlIG15IHJlcXVlc3Q6IGNvdWxkIHdlIG1vZGlmeS9hZGQgc29tZSB0 ZXh0IHRvIHNob3cgdGhhdCBhbHNvIA0KPiA+IHRoZSBvcHRpb24gY2FuIGJlIHVzZWQgdG8gZW5h YmxlIHJlc3BvbnNlcyBpbiBjYXNlIHdoZXJlIHRoZXkgYXJlIA0KPiA+IG5vcm1hbGx5IChieSBk ZWZhdWx0IC0tIHNlcnZlciBkZWNpc2lvbikgc3VwcHJlc3NlZD8NCj4gPiBKdXN0IHRvIGNsYXJp Znkgc3VjaCB1c2FnZTsgd2hpY2ggaXMgcXVpdGUgdXNlZnVsIGluIG15IHZpZXcuDQo+ID4gDQo+ ID4gcmVnYXJkcw0KPiA+IEVza28NCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1h eSBiZSBjb25maWRlbnRpYWwgYW5kIA0KPiA+IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxp Y2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCANCj4gPiBzb2xlbHkgZm9yIHRoZSBh ZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIA0KPiA+ IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2Vt aW5hdGlvbiwgb3IgDQo+ID4gcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgDQo+ID4gdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSANCj4gPiBzZW5kZXIgYnkg cmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCANCm1l c3NhZ2UuIA0KPiA+ID09PT09LS0tLS09PT09PS0tLS0tPT09PT0NCj4gPiBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwNCj4gPiBtZXNzYWdlIGFuZC9vciBh dHRhY2htZW50cyB0byBpdCBtYXkgY29udGFpbiANCj4gPiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSANCj4gPiBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgDQo+ID4gcmV2aWV3LCBkaXN0cmlidXRpb24s IHByaW50aW5nIG9yIGNvcHlpbmcgb2YgdGhlIA0KPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIGUtbWFpbCBtZXNzYWdlIA0KPiA+IGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUg c3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgDQo+ID4geW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCANCj4gPiBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFp bCBvciB0ZWxlcGhvbmUgYW5kIA0KPiA+IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxl dGUgdGhlIG1lc3NhZ2UgDQo+ID4gYW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91IA0KPiAN Cj4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZp ZGVudGlhbCBhbmQgDQo+IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBU aGUgbWVzc2FnZSBpcyBpbnRlbmRlZCANCj4gc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCANCj4geW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciANCj4g cmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgDQo+IHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgY29udGFjdCB0aGUgDQo+IHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0 cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= --=_alternative 006D32BB65257FA8_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVza28sPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHJlc3BvbmRpbmcuIFRoZSBkaXNj dXNzaW9uDQppcyBsZWFkaW5nIHRvIGV4YWN0bHkgd2hhdCBJIHdhcyB0aGlua2luZyBhYm91dC48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvLCBpZiB3ZSBlbmhh bmNlIHRoZSB0ZXh0IGFzIGJlbG93DQp3b3VsZCBpdCBiZSBnb29kIGZvciB0aGUgcHVycG9zZT8g UGxlYXNlIGNvbW1lbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mcXVvdDtUaGUgc2VydmVyIE1VU1Qgc2VuZCBiYWNrIHJlc3BvbnNlcw0Kb2YgdGhl IGNsYXNzZXMgZm9yIHdoaWNoIHRoZSBjbGllbnQgaGFzIG5vdCBleHByZXNzZWQgYW55IGRpcy1p bnRlcmVzdC4NClRoZXJlIGFyZSBpbnN0YW5jZXMgd2hlcmUgYSBzZXJ2ZXIsIG9uIGl0cyBvd24s IG1heSBkZWNpZGUgdG8gc3VwcHJlc3MNCnJlc3BvbnNlcyBsaWtlIHRoZSBtdWx0aWNhc3Qgc2Vy dmVycyBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAyLjcgb2YgJm5ic3A7W1JGQzczOTBdLg0KSWYg dGhlIHNlcnZlciByZWNlaXZlcyBhIHJlcXVlc3Qgd2l0aCBOby1SZXNwb25zZSBzaG93aW5nICdp bnRlcmVzdCcgaW4NCmNlcnRhaW4gcmVzcG9uc2VzIHRoZW4gc3VjaCBiZWhhdmlvdXIgb2Ygc3Vw cHJlc3NpbmcgcmVzcG9uc2VzIGJ5IHNlcnZlcnMNCk1VU1QgYmUgb3Zlci1yaWRkZW4gZm9yIHRo b3NlIHJlc3BvbnNlcyB3aGljaCBhcmUgb2YgaW50ZXJlc3QgdG8gdGhlIGNsaWVudC4NClRoZSBz ZXJ2ZXIgTVVTVCBzZW5kIHRob3NlIHJlc3BvbnNlcyBmb3Igd2hpY2ggdGhlIGNsaWVudCBoYXMg bm90IGV4cHJlc3NlZA0KYW55IGRpc2ludGVyZXN0IChpLmUuLCBleHByZXNzZWQgJ2ludGVyZXN0 JykuIFNvLCBmb3IgZXhhbXBsZSwgaWYgYSBtdWx0aWNhc3QNCnNlcnZlciBkZWNpZGVzIHRvIHN1 cHByZXNzIGFsbCByZXNwb25zZXMgYW5kIHJlY2VpdmVzIGEgcmVxdWVzdCB3aXRoIE5vLVJlc3Bv bnNlDQpvcHRpb24gZXhwcmVzc2luZyBkaXNpbnRlcmVzdCBvbmx5IGluIHN1Y2Nlc3MgcmVzcG9u c2VzIGJ1dCBub3QgaW4gZXJyb3JzDQp0aGVuIHRoZSBzZXJ2ZXIgTVVTVCBzZW5kIGJhY2sgYSBy ZXNwb25zZSBpZiB0aGUgY29uY2VybmVkIHJlcXVlc3QgY2F1c2VzDQphbiBlcnJvci4gJnF1b3Q7 PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDtI b3BlZnVsbHksIHRoaXMgd2lsbCBzb2x2ZSBhIHBvdGVudGlhbA0KcHJvYmxlbSB3aGVuIHRoZSBj bGllbnQgYWN0dWFsbHkgd2FudHMgdG8gZGVidWcgdGhlIGxpZ2h0cyB0aHJvdWdoIGdyYW51bGFy DQpOby1SZXNwb25zZSBidXQgdGhlIHNlcnZlcnMgZGVjaWRlIG5vdCB0byBzZW5kIGEgcmVzcG9u c2UgYXMgZGVmYXVsdCBiZWhhdmlvdXINCmFuZCB0aGUgY2xpZW50IGlzIG5ldmVyIGF3YXJlIG9m IHRoYXQuIEhvd2V2ZXIsIGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlDQphYm92ZSBjb3VsZCBiZSBy ZWNpcHJvY2F0ZWQgYnkgc29tZSBzcGVjaWZpY2F0aW9uIHdoaWNoIGRlYWxzIHdpdGggdGhlDQpz ZXJ2ZXItc2lkZSBiZWhhdmlvdXIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5XYWl0aW5nIHRvIGhlYXIgZnJvbSB5b3UuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzPGJyPg0KQWJoaWphbiBCaGF0 dGFjaGFyeXlhPGJyPg0KQXNzb2NpYXRlIENvbnN1bHRhbnQ8YnI+DQpTY2llbnRpc3QsIElubm92 YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NClRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXM8 YnI+DQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPGJyPg0KV2Vic2l0ZTog PC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy50Y3MuY29tLz48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+aHR0cDovL3d3dy50Y3MuY29tPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpFeHBlcmllbmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7SVQgU2VydmljZXM8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QnVzaW5lc3Mg U29sdXRpb25zPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvZm9u dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O0RpamssIEVza28mcXVvdDsgJmx0 O2Vza28uZGlqa0BwaGlsaXBzLmNvbSZndDsNCndyb3RlIG9uIDA1LzAzLzIwMTYgMDE6MjU6MDEg QU06PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDtEaWprLCBFc2tvJnF1b3Q7ICZsdDtlc2tv LmRpamtAcGhpbGlwcy5jb20mZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgJmx0O2FiaGlqYW4uYmhhdHRhY2hhcnl5YUB0 Y3MuY29tJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDYzogJnF1 b3Q7Y29yZUBpZXRmLm9yZyBXRyZxdW90OyAmbHQ7Y29yZUBpZXRmLm9yZyZndDssDQpOZXZpbCBC cm93bmxlZSAmbHQ7cmZjLWlzZUByZmMtPGJyPg0KJmd0OyBlZGl0b3Iub3JnJmd0OzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEYXRlOiAwNS8wMy8yMDE2IDAxOjI1IEFN PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFN1YmplY3Q6IFJFOiBVc2lu ZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24NCnRvICplbmFibGUqIHJlc3BvbnNl czwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEhpLDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyAmcXVvdDtUaGUgc2VydmVyIE1VU1Qgc2Vu ZCBiYWNrIHJlc3BvbnNlcw0Kb2YgdGhlIGNsYXNzZXMgZm9yIHdoaWNoIHRoZSA8YnI+DQomZ3Q7 IGNsaWVudCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiZxdW90OyAtIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGlzIGNvdmVycyBwYXJ0IG9mIG15 IHVzZSBjYXNlOyBob3dldmVyIGl0IGlzDQpub3QgY2xlYXIgaG93IHRoaXMgPGJyPg0KJmd0OyAm cXVvdDtNVVNUJnF1b3Q7IGludGVyYWN0cyB3aXRoIHRoZSAmcXVvdDtNQVkgc3VwcHJlc3MmcXVv dDsgb2YgUkZDDQo3MjUyIGZvciB0aGUgPGJyPg0KJmd0OyBtdWx0aWNhc3QgY2FzZS4gQ2FuIHRo ZSBzZXJ2ZXIgc3RpbGwgZGVjaWRlIHRvIHN1cHByZXNzIHRoZSA8YnI+DQomZ3Q7IG11bHRpY2Fz dCByZXNwb25zZSBldmVuIGlmIHRoZSBOby1SZXNwb25zZSBPcHRpb24gc2VudCBieSB0aGUgY2xp ZW50PGJyPg0KJmd0OyBzYXlzIG5vdCB0bz8gVGhpbmtpbmcgYWJvdXQgaXQsIGl0IHdvdWxkIGJl IHBlcmhhcHMgZ29vZCBpZiBkcmFmdC08YnI+DQomZ3Q7IHRjcy1jb2FwLW5vLXJlc3BvbnNlLW9w dGlvbiB3b3VsZCBtYWtlIHRoYXQgY2xlYXIuIFRoZSAmcXVvdDtNVVNUJnF1b3Q7DQphbmQgPGJy Pg0KJmd0OyB0aGUgdXNlIGNhc2UgNC4yLjEgc3VnZ2VzdCB0aGF0IHRoZSBkZWZhdWx0IHN1cHBy ZXNzaW9uIGNob2ljZXMgb2YNCjxicj4NCiZndDsgdGhlIHNlcnZlciBhcmUgb3ZlcnJpZGRlbiBi eSB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9uIGJ1dCB0aGF0IGlzIG5vdA0KPGJyPg0KJmd0OyB3cml0 dGVuIGV4cGxpY2l0bHkgeWV0LiAmbmJzcDtJZiB0aGF0IGlzIHRoZSBjYXNlLCBteSB1c2UgY2Fz ZSBpcw0KZnVsbHkgPGJyPg0KJmd0OyBjb3ZlcmVkIGJ5IHlvdXIgZHJhZnQgSSB0aGluay48L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFuIHVwZGF0ZSBvciBzdWNjZXNzb3IgdG8gdGhlIEdy b3VwY29tbSBSRkMgY291bGQNCmluZGVlZCBkZXNjcmliZSA8YnI+DQomZ3Q7IGhvdyB0aGUgTm8t UmVzcG9uc2UgT3B0aW9uIGNhbiBiZSB1c2VkIGZvciBtdWx0aWNhc3QgdXNlIGNhc2VzLiBJdA0K PGJyPg0KJmd0OyB3b3VsZCBiZSBncmVhdCBpZiB0aGF0IGNvdWxkIGJlIGRvbmUgd2l0aG91dCBu ZWVkaW5nIGZ1cnRoZXIgPGJyPg0KJmd0OyBtb2RpZmljYXRpb25zIHRvIGRyYWZ0LXRjcy1jb2Fw LW5vLXJlc3BvbnNlLW9wdGlvbiE8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHJlZ2FyZHM8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRXNrbzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgRnJvbTogQWJoaWphbiBCaGF0dGFjaGFyeXlhIFs8L2ZvbnQ+PC90dD48 YSBocmVmPW1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT48dHQ+PGZvbnQgc2l6 ZT0yPm1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvZm9udD48L3R0PjwvYT48 dHQ+PGZvbnQgc2l6ZT0yPl0NCjxicj4NCiZndDsgU2VudDogTW9uZGF5LCBNYXkgMDIsIDIwMTYg NToxOTxicj4NCiZndDsgVG86IERpamssIEVza28gJmx0O2Vza28uZGlqa0BwaGlsaXBzLmNvbSZn dDs8YnI+DQomZ3Q7IENjOiBjb3JlQGlldGYub3JnIFdHICZsdDtjb3JlQGlldGYub3JnJmd0Ozsg TmV2aWwgQnJvd25sZWUgJmx0O3JmYy1pc2VAcmZjLWVkaXRvci5vcmcmZ3Q7PGJyPg0KJmd0OyBT dWJqZWN0OiBSRTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICpl bmFibGUqIHJlc3BvbnNlczxicj4NCiZndDsgSW1wb3J0YW5jZTogSGlnaDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgSGkgRXNrbywgPGJyPg0KJmd0OyBUaGUgZXhpc3RpbmcgdmVyc2lvbiAt MTYgaGFzIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBzZWN0aW9uIDIuMSAocGFnZQ0KNSkgOiA8YnI+ DQomZ3Q7ICZxdW90O1RoZSBzZXJ2ZXIgTVVTVCBzZW5kIGJhY2sgcmVzcG9uc2VzIG9mIHRoZSBj bGFzc2VzIGZvciB3aGljaA0KdGhlIDxicj4NCiZndDsgY2xpZW50IGhhcyBub3QgZXhwcmVzc2Vk IGFueSBkaXMtaW50ZXJlc3QuJnF1b3Q7IDxicj4NCiZndDsgU28sIHRoYXQgd2F5IHRoZSBjbGll bnQgaGFzIGFjdHVhbGx5IGV4cHJlc3NlZCBpdHMgaW50ZXJlc3QgKG9yIDxicj4NCiZndDsgcmVx dWVzdCBmb3IgZW5hYmxlbWVudCkgaW4gYWxsIHRoZSByZXNwb25zZXMgZm9yIHdoaWNoIGl0IGhh cyBub3QNCjxicj4NCiZndDsgZXhwcmVzc2VkIGV4cGxpY2l0IGRpc2ludGVyZXN0LiBEb2VzIHRo YXQgaGVscCB0byBjb250cm9sIHRoZSA8YnI+DQomZ3Q7IHNwZWNpYWwgc2VydmVyLXNpZGUgYmVo YXZpb3VyIGFzIHRoZSBzZXJ2ZXIga25vd3Mgd2hpY2ggYWxsIDxicj4NCiZndDsgcmVzcG9uc2Vz IHRoZSBjbGllbnQgaXMgaW50ZXJlc3RlZCBpbiBhbmQgaXQgTVVTVCBzZW5kIGEgcmVzcG9uc2UN Cjxicj4NCiZndDsgYmFjayA/IEkgc2hhbGwgc3VibWl0IGFub3RoZXIgdmVyc2lvbiB3aXRoIHNv bWUgZWRpdG9yaWFsIGNoYW5nZXMNCjxicj4NCiZndDsgYmVmb3JlIHRoZSBkcmFmdCBnb2VzIHRv IElFU0cuIFNvIHdlIGhhdmUgc29tZSBtb3JlIHJvb20gZm9yIDxicj4NCiZndDsgbW9kaWZpY2F0 aW9uLiBJZiB5b3UgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoaXMgaW4gdGhlIGxpbmUgb2YgdGhl DQo8YnI+DQomZ3Q7IGRpc2N1c3Npb24gd2UgYXJlIGhhdmluZywgcGxlYXNlIGxldCB1cyBrbm93 LiBJIHNoYWxsIHdhaXQgZm9yIHlvdXINCjxicj4NCiZndDsgdmlld3MgYmVmb3JlIHN1Ym1pdHRp bmcgdGhlIHVwZGF0ZWQgdmVyc2lvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFueXdheSwgYSBz ZXBhcmF0ZSBkcmFmdCAob3IsIHBvc3NpYmx5LCBhbiB1cGRhdGVkIGdyb3VwY29tbSBSRkM/KQ0K PGJyPg0KJmd0OyBpcyBhIGdvb2QgaWRlYS4gTm8tUmVzcG9uc2UgYXNzdW1lcyB0aGUgdXN1YWwg cmVxdWVzdC9yZXNwb25zZSA8YnI+DQomZ3Q7IHN5bWFudGljcyBhbmQgaXQgbWFpbmx5IGFkZHJl c3NlcyB0aGUgY2xpZW50IHNpZGUgYmVoYXZpb3VyIGFuZCA8YnI+DQomZ3Q7IGlzc3Vlcy4gQ29u c2lkZXJpbmcgc3VjaCBzcGVjaWFsIGJlaGF2aW91ciBvZiBncm91cGNvbW0gc2VydmVycywgaXQN Cjxicj4NCiZndDsgd291bGQgYmUgZ29vZCB0byBoYW5kbGUgc2VwYXJhdGVseS4gPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFdhaXRpbmcgdG8gaGVhciBmcm9tIHlvdS4gPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFJlZ2FyZHM8YnI+DQomZ3Q7IEFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCiZndDsgQXNz b2NpYXRlIENvbnN1bHRhbnQ8YnI+DQomZ3Q7IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtv bGthdGEsIEluZGlhPGJyPg0KJmd0OyBUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KJmd0 OyBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPGJyPg0KJmd0OyBXZWJzaXRl OiA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+PHR0Pjxmb250IHNpemU9 Mj5odHRwOi8vd3d3LnRjcy5jb208L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyBFeHBlcmllbmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQg U2VydmljZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNv bHV0aW9uczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7Q29uc3VsdGluZzxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmcXVvdDtEaWprLCBFc2tvJnF1b3Q7ICZsdDtl c2tvLmRpamtAcGhpbGlwcy5jb20mZ3Q7IHdyb3RlIG9uIDA1LzAyLzIwMTYNCjAzOjEwOjI0IEFN Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206ICZxdW90O0RpamssIEVza28mcXVvdDsg Jmx0O2Vza28uZGlqa0BwaGlsaXBzLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRvOiBBYmhpamFu IEJoYXR0YWNoYXJ5eWEgJmx0O2FiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tJmd0Ow0KPGJy Pg0KJmd0OyAmZ3Q7IENjOiAmcXVvdDtjb3JlQGlldGYub3JnIFdHJnF1b3Q7ICZsdDtjb3JlQGll dGYub3JnJmd0OywgTmV2aWwNCkJyb3dubGVlICZsdDtyZmMtaXNlQHJmYy08YnI+DQomZ3Q7ICZn dDsgZWRpdG9yLm9yZyZndDsgPGJyPg0KJmd0OyAmZ3Q7IERhdGU6IDA1LzAyLzIwMTYgMDM6MTAg QU0gPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1y ZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSoNCnJlc3BvbnNlcyA8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IEhlbGxvIEFiaGlqYW4sIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgTWFuZGF0aW5nIHN1Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBj bGllbnQgc2lkZSB3aWxsDQpiZSBhIGJpdDxicj4NCiZndDsgJmd0OyBvdXQtb2Ytc3luYyB3aXRo IHRoZSBzcGlyaXQgb2YgdGhlIHNwZWNpZmljYXRpb24uIDxicj4NCiZndDsgJmd0OyBUaGlzIGlz IG5vdCBmdWxseSBjbGVhciB0byBtZSB5ZXQg4oCmIHRoZSBjbGllbnQgZG9lcyBub3QgbWFuZGF0 ZQ0KPGJyPg0KJmd0OyAmZ3Q7IGFueXRoaW5nIGZyb20gdGhlIHNlcnZlcjsgaXQganVzdCBleHBy ZXNzZXMgaXRzIGludGVyZXN0ICgwLWJpdHMpDQo8YnI+DQomZ3Q7ICZndDsgYW5kIGRpc2ludGVy ZXN0ICgxLWJpdHMpLiBUaGUgc2VydmVyIGNhbiBhbHdheXMgbm90IHBhcnNlIHRoZQ0Kb3B0aW9u PGJyPg0KJmd0OyAmZ3Q7IChlbGVjdGl2ZSkgb3IgY2hvb3NlIG5vdCB0byBib3RoZXIgYWJvdXQg aXQuIDxicj4NCiZndDsgJmd0OyBUaGlzIGRvZXMga2VlcCB0aGUgY2xpZW50IHdhaXRpbmcgZm9y IGEgcG9zc2libGUgcmVzcG9uc2UgdGhhdA0KbmV2ZXI8YnI+DQomZ3Q7ICZndDsgY29tZXM7IGJ1 dCB0aGF0IGlzIHRoZSBzYW1lIGluIHRoZSBnZW5lcmFsIG11bHRpY2FzdCBjYXNlIDogdGhlDQo8 YnI+DQomZ3Q7ICZndDsgY2xpZW50IGNhbiBuZXZlciBrbm93IGlmIG9yIHdoZW4gYSByZXNwb25z ZSB3aWxsIGNvbWUsIHRoZSBzZXJ2ZXINCjxicj4NCiZndDsgJmd0OyBNQVkgYWx3YXlzIGNob29z ZSB0byBub3QgcmVzcG9uZC4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg U28gd2hhdCBJIHByb3Bvc2UgaXMgdG8gdXNlIHRoZSAmcXVvdDtpbmRpY2F0aW9uIG9mIGludGVy ZXN0JnF1b3Q7DQp0byBzcGVjaWZpYzxicj4NCiZndDsgJmd0OyByZXNwb25zZSBjbGFzc2VzIGlu IGEgbmV3IHdheTsgbmFtZWx5IHRvIGVuYWJsZSBjZXJ0YWluIHJlc3BvbnNlDQo8YnI+DQomZ3Q7 ICZndDsgY2xhc3NlcyB0aGF0IGFyZSBzdXBwcmVzc2VkIGJ5IGRlZmF1bHQuICZuYnNwO0l0IGp1 c3QgaGFwcGVucw0KdGhhdCB0aGUgPGJyPg0KJmd0OyAmZ3Q7IHNhbWUgT3B0aW9uIHN5bnRheCBp cyB2ZXJ5IHdlbGwgc3VpdGVkIGZvciB0aGF0IHB1cnBvc2UuIEEgc2VwYXJhdGUNCjxicj4NCiZn dDsgJmd0OyBkcmFmdCBjb3VsZCBiZSB3cml0dGVuIGZvciB0aGF0IHBlcmhhcHMgaWYgeW91IHRo aW5rIGl0IGRvZXMNCm5vdCBmaXQ8YnI+DQomZ3Q7ICZndDsgaW4gZHJhZnQtdGNzLWNvYXAtbm8t cmVzcG9uc2Utb3B0aW9uIG9yIGlmIGl0IGlzIHRvbyBsYXRlIGZvcg0KdGhhdC4gPGJyPg0KJmd0 OyAmZ3Q7IFRoZSB3ZSBjYW4gcG9pbnQgdG8gdGhlIHN5bnRheCBvZiB0aGUgTm8tUmVzcG9uc2Ug T3B0aW9uIGFuZA0KcmUtdXNlIDxicj4NCiZndDsgJmd0OyBpdCBjb21wbGV0ZWx5LiA8YnI+DQom Z3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyByZWdhcmRzIDxicj4NCiZndDsgJmd0OyBF c2tvIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206IEFiaGlqYW4g QmhhdHRhY2hhcnl5YSBbPC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFj aGFyeXlhQHRjcy5jb20+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFy eXlhQHRjcy5jb208L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj5dDQo8YnI+DQomZ3Q7 ICZndDsgU2VudDogRnJpZGF5LCBBcHJpbCAyMiwgMjAxNiAxNzoxNzxicj4NCiZndDsgJmd0OyBU bzogRGlqaywgRXNrbyAmbHQ7ZXNrby5kaWprQHBoaWxpcHMuY29tJmd0Ozxicj4NCiZndDsgJmd0 OyBDYzogY29yZUBpZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs7IE5ldmlsIEJyb3du bGVlICZsdDtyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24g dG8gKmVuYWJsZSoNCnJlc3BvbnNlcyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsg Jmd0OyBIaSBFc2tvLCA8YnI+DQomZ3Q7ICZndDsgVGhhbmtzIGZvciB5b3VyIG1haWwuIDxicj4N CiZndDsgJmd0OyBGaXJzdCBvZiBhbGwgbGV0IG1lIGp1c3QgYnJpbmcgdGhpcyB0byB5b3VyIChh cyB3ZWxsIGFzIHRoZSBtYWlsaW5nDQo8YnI+DQomZ3Q7ICZndDsgbGlzdCdzKSBub3RpY2UgdGhh dCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzOiAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPC9mb250PjwvdHQ+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRjcy1jb2FwLW5v LXJlc3BvbnNlLSI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2UtPC9mb250PjwvdHQ+PC9hPjx0dD48 Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBvcHRpb24tMTYudHh0PGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBUaGlzIHZlcnNpb24gJnF1b3Q7b2ZmaWNpYWxseSZxdW90OyBjbG9zZXMgdGhl IHRlY2huaWNhbCByZXZpZXdzDQphbmQgaXMgd2l0aCA8YnI+DQomZ3Q7ICZndDsgdGhlIFJGQyBl ZGl0b3IgdGhyb3VnaCB0aGUgSVMgdHJhY2suIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgTm93IGNvbWluZyB0byB5b3VyIHVzZSBjYXNlIChhbmQgaW5kZWVkIGl0IGlzIGFuIGludGVy ZXN0aW5nDQpvbmUpIDxicj4NCiZndDsgJmd0OyBvbmUgdGhpbmcgdGhhdCB3ZSBzaG91bGQgY29u c2lkZXIgaXMgdGhhdCB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9uDQp3YXM8YnI+DQomZ3Q7ICZndDsg ZGVsaWJlcmF0ZWx5IGRlc2lnbmVkIG5vdCB0byBtYW5kYXRlIGFueXRoaW5nIGZvciB0aGUgc2Vy dmVyDQpzaWRlIDxicj4NCiZndDsgJmd0OyBtYWlubHkgdG8gZW5zdXJlIHRoYXQgaXQgZG9lcyBu b3QgZGlzcnVwdCB0aGUgbWFueSB1c2VmdWxuZXNzDQpvZiB0aGU8YnI+DQomZ3Q7ICZndDsgdXN1 YWwgcmVxdWVzdC9yZXNwb25zZSBzeW1hbnRpY3MuIFRoZSBkcmFmdCBhbGwgYWxvbmcgZGVhbHMg d2l0aA0KdGhlPGJyPg0KJmd0OyAmZ3Q7IHJlcXVlc3RpbmcgY2xpZW50J3MgYmVoYXZpb3VyIGFu ZCBpdHMgZXhwcmVzc2lvbiBvZiBpbnRlcmVzdA0KdG8gdGhlIDxicj4NCiZndDsgJmd0OyBzZXJ2 ZXIuIFNpbmNlIHRoaXMgb3B0aW9uIGlzIGVsZWN0aXZlIHdlIGxlYXZlIGl0IHVwdG8gdGhlIHNl cnZlcg0KPGJyPg0KJmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9uIHRvIGhvbm91ciB0aGUgY2xpZW50 J3MgaW50ZXJlc3QuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTm93LCBhcyBwZXIg dXN1YWwgcmVxdWVzdC9yZXNwb25zZSBzeW1hbnRpY3MgdGhlIHJlc3BvbnNlcyBhcmUNCjxicj4N CiZndDsgJmd0OyBhbHdheXMgZW5hYmxlZC4gVGhlIGJlaGF2aW91ciBpbiBncm91cGNvbW0gc2Vy dmVyIGluIHRlcm1zIG9mDQo8YnI+DQomZ3Q7ICZndDsgc3VwcHJlc3NpbmcgdGhlIHJlc3BvbnNl cyBvbiBpdHMgb3duIGlzIHNvbWV0aGluZyBzcGVjaWFsIGFuZCwNCjxicj4NCiZndDsgJmd0OyBn ZW5lcmFsbHkgc3BlYWtpbmcsIHRoZSBjbGllbnRzIGFyZSBub3QgYXdhcmUgb2Ygc3VjaCBzcGVj aWFsDQpiZWhhdmlvdXIuICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNv LCBpdCB3b3VsZCBiZSBqdXN0aWZpZWQgdG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gYXQgdGhlIHNl cnZlcidzDQo8YnI+DQomZ3Q7ICZndDsgZW5kLiBIZXJlIGlzIHRoZSBpZGVhOiA8YnI+DQomZ3Q7 ICZndDsgV2hpbGUgTm8tUmVzcG9uc2UgaXMgdG8gZXhwcmVzc2VzIGNsaWVudCdzIGRpcy1pbnRl cmVzdCBpbiBzb21lDQpvciA8YnI+DQomZ3Q7ICZndDsgYWxsIG9mIHRoZSByZXNwb25zZXMgZGVw ZW5kaW5nIG9uIHRoZSBvcHRpb24gdmFsdWUsIGl0IGlzIGFsc28NCnRydWUgPGJyPg0KJmd0OyAm Z3Q7IHRoYXQgdGhlIG9wdGlvbiBhdXRvbWF0aWNhbGx5IGV4cHJlc3NlcyBpbnRlcmVzdCBpbiBh bGwgb3RoZXINCjxicj4NCiZndDsgJmd0OyByZXNwb25zZXMgKG1hcmtlZCBieSAwJ3MgaW4gdGhl IHJlc3BlY3RpdmUgcG9zaXRpb25zKS4gVGhlIGNsaWVudA0KaXM8YnI+DQomZ3Q7ICZndDsgZ29p bmcgdG8gd2FpdCBmb3IgdGhlc2UgcmVzcG9uc2VzIHVwdG8gYSBnaXZlbiB0aW1lb3V0LiBOb3cs DQppZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IHNlcnZlciBiZWhhdmlvdXIgaXMgbW9kaWZpZWQgbGlr ZSB0aGlzIDogJnF1b3Q7SSBoYXZlIGNsb3NlZA0KbXkgZG9vciBmb3IgPGJyPg0KJmd0OyAmZ3Q7 IGFsbCBvdXQgZ29pbmcgcmVzcG9uc2UuICoqQlVUKiosIGlmIEkgc2VlIGEgZmVsbG93IHJlcXVl c3RpbmcNCndpdGggPGJyPg0KJmd0OyAmZ3Q7IE5vLVJlc3BvbnNlIGFuZCBrZWVwaW5nIHdpbmRv d3Mgb3BlbiB0byBzb21lIHJlc3BvbnNlcyB0aGVuIEkNCmFzc3VtZTxicj4NCiZndDsgJmd0OyB0 aGF0IHRoaXMgZ3V5IHJlYWxseSBuZWVkcyB0aG9zZSBraW5kIG9mIHJlc3BvbnNlcy4gSW4gdGhh dCBjYXNlDQpsZXQ8YnI+DQomZ3Q7ICZndDsgbWUgYmUgbGluaWVudCBhbmQgbGV0IG1lIG9wZW4g dGhlIGRvb3IgZm9yIHN1Y2ggcmVzcG9uc2VzLiBUaGlzDQo8YnI+DQomZ3Q7ICZndDsgZmVsbG93 IG11c3QgYmUgYXZhaWxhYmxlIHRvIGxpc3RlbiB0byB0aGVtIGFzIHBlciB0aGUgcHJlc2NyaWJl ZA0KPGJyPg0KJmd0OyAmZ3Q7IGJlaGF2aW91ciBpbiB0aGUgTm8tUmVzcG9uc2Ugc3BlY2lmaWNh dGlvbi4mcXVvdDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTWFuZGF0 aW5nIHN1Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBjbGllbnQgc2lkZSB3aWxsIGJlDQph IGJpdCA8YnI+DQomZ3Q7ICZndDsgb3V0LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBz cGVjaWZpY2F0aW9uLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFJlZ2FyZHM8YnI+ DQomZ3Q7ICZndDsgQWJoaWphbiBCaGF0dGFjaGFyeXlhPGJyPg0KJmd0OyAmZ3Q7IEFzc29jaWF0 ZSBDb25zdWx0YW50PGJyPg0KJmd0OyAmZ3Q7IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtv bGthdGEsIEluZGlhPGJyPg0KJmd0OyAmZ3Q7IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXM8YnI+ DQomZ3Q7ICZndDsgTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4NCiZn dDsgJmd0OyBXZWJzaXRlOiA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+ PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LnRjcy5jb208L2ZvbnQ+PC90dD48L2E+PHR0Pjxm b250IHNpemU9Mj48YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtEaWprLCBFc2tvJnF1b3Q7 ICZsdDtlc2tvLmRpamtAcGhpbGlwcy5jb20mZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgVG86ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FiaGlqYW4gQmhhdHRhY2hhcnl5YSAmbHQ7YWJoaWphbi5i aGF0dGFjaGFyeXlhQHRjcy5jb20mZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgQ2M6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO05ldmlsIEJyb3dubGVlICZsdDtyZmMtaXNlQHJmYy1lZGl0b3Iub3Jn Jmd0OywNCiZxdW90O2NvcmVAaWV0Zi5vcmcgV0cmcXVvdDsgJmx0Ozxicj4NCiZndDsgJmd0OyBj b3JlQGlldGYub3JnJmd0OyA8YnI+DQomZ3Q7ICZndDsgRGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7MDQvMjIvMjAxNiAwNTo0MyBQTSA8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Ut b3B0aW9uDQp0byA8YnI+DQomZ3Q7ICplbmFibGUqIHJlc3BvbnNlcyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEhlbGxvIEFiaGlqYW4sPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBpbiBv dXIgcHJvamVjdCB3ZSBzZWUgYSBjbGVhciB1c2UgY2FzZSBvZiB1c2luZyB0aGUgTm8tUmVzcG9u c2UNCjxicj4NCiZndDsgJmd0OyBPcHRpb24gdG8gKmVuYWJsZSogY2VydGFpbiByZXNwb25zZXMg dGhhdCBhcmUgYnkgZGVmYXVsdCBzdXBwcmVzc2VkLjxicj4NCiZndDsgJmd0OyBDb0FQIGFsbG93 cyBzdXBwcmVzc2lvbiBvZiBtdWx0aWNhc3QgcmVzcG9uc2VzIGJ5IGRlZmF1bHQsIHdoaWNoDQpp cyA8YnI+DQomZ3Q7ICZndDsgd2hhdCB3ZSB1c2UgZm9yIGEgbGlnaHRpbmcgbXVsdGljYXN0IHVz ZSBjYXNlLiBIb3dldmVyIGZvciA8YnI+DQomZ3Q7ICZndDsgZGlhZ25vc3RpYyB1c2FnZSB3ZSdk IGxpa2UgdG8gZW5hYmxlIHRoZXNlIHJlc3BvbnNlcyBhZ2FpbiB1c2luZw0KdGhlPGJyPg0KJmd0 OyAmZ3Q7IE5vLVJlc3BvbnNlIG9wdGlvbiB3aGljaCBpcyBwZXJmZWN0bHkgc3VpdGVkIGZvciB0 aGF0LiBIb3dldmVyLA0KdGhlIDxicj4NCiZndDsgJmd0OyBkcmFmdCB0ZXh0IGN1cnJlbnRseSBv bmx5IHRhbGtzIGFib3V0IHN1cHByZXNzaW5nIHJlc3BvbnNlcyAobm90DQplbmFibGluZykuPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBIZW5jZSBteSByZXF1ZXN0OiBjb3VsZCB3ZSBt b2RpZnkvYWRkIHNvbWUgdGV4dCB0byBzaG93IHRoYXQNCmFsc28gPGJyPg0KJmd0OyAmZ3Q7IHRo ZSBvcHRpb24gY2FuIGJlIHVzZWQgdG8gZW5hYmxlIHJlc3BvbnNlcyBpbiBjYXNlIHdoZXJlIHRo ZXkNCmFyZSA8YnI+DQomZ3Q7ICZndDsgbm9ybWFsbHkgKGJ5IGRlZmF1bHQgLS0gc2VydmVyIGRl Y2lzaW9uKSBzdXBwcmVzc2VkPzxicj4NCiZndDsgJmd0OyBKdXN0IHRvIGNsYXJpZnkgc3VjaCB1 c2FnZTsgd2hpY2ggaXMgcXVpdGUgdXNlZnVsIGluIG15IHZpZXcuPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyByZWdhcmRzPGJyPg0KJmd0OyAmZ3Q7IEVza288YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyAmZ3Q7IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBj b25maWRlbnRpYWwNCmFuZCA8YnI+DQomZ3Q7ICZndDsgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIg YXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkDQo8YnI+DQomZ3Q7ICZndDsg c29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LA0KPGJyPg0KJmd0OyAmZ3Q7IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwNCm9yIDxicj4NCiZndDsgJmd0OyBy ZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZQ0KPGJyPg0KJmd0OyAmZ3Q7IHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdA0KdGhlIDxicj4NCiZndDsgJmd0OyBzZW5kZXIg YnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbA0K bWVzc2FnZS4gPGJyPg0KJmd0OyAmZ3Q7ID09PT09LS0tLS09PT09PS0tLS0tPT09PT08YnI+DQom Z3Q7ICZndDsgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWls PGJyPg0KJmd0OyAmZ3Q7IG1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250 YWluIDxicj4NCiZndDsgJmd0OyBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv bi4gSWYgeW91IGFyZSA8YnI+DQomZ3Q7ICZndDsgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIDxicj4NCiZndDsgJmd0OyByZXZpZXcsIGRpc3RyaWJ1 dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIDxicj4NCiZndDsgJmd0OyBhbmQv b3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIDxicj4NCiZn dDsgJmd0OyB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDxi cj4NCiZndDsgJmd0OyBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhv bmUgYW5kIDxicj4NCiZndDsgJmd0OyBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRl IHRoZSBtZXNzYWdlIDxicj4NCiZndDsgJmd0OyBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5 b3UgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlh bCBhbmQNCjxicj4NCiZndDsgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcu IFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIDxicj4NCiZndDsgc29sZWx5IGZvciB0aGUgYWRkcmVz c2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LA0KPGJyPg0KJmd0 OyB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3Nl bWluYXRpb24sIG9yDQo8YnI+DQomZ3Q7IHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMg c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIDxicj4NCiZndDsgdW5sYXdmdWwuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZQ0KPGJy Pg0KJmd0OyBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9m IHRoZSBvcmlnaW5hbCBtZXNzYWdlLjwvZm9udD48L3R0Pg0K --=_alternative 006D32BB65257FA8_=-- From nobody Tue May 3 14:14:43 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FAE12D901 for ; Tue, 3 May 2016 14:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, URIBL_BLACK=1.7] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYIiDnSXbb1I for ; Tue, 3 May 2016 14:14:37 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC1512D907 for ; Tue, 3 May 2016 14:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X/V4v/BbU/sBWgeP0cHSqFlaqWK7U0juL8ipjXHk7f0=; b=BnPOhaF+DqF3p/nrAgZIU2b57rW1h7G6gpqnOqbjfDU8Ou+anjc43NcIHNhxtHZ24SNJLWHicAbT1QGSMIh1gai6jpx/Xg9+DabIbikvQNNJB3rLsR0AfZyvMwfkZbg8WDH6E91mcaGkDYlA0L6TVscUB3xcssayji4LLpceG9c= Received: from HE1PR0401CA0020.eurprd04.prod.outlook.com (10.166.116.158) by VI1PR04MB1584.eurprd04.prod.outlook.com (10.164.84.142) with Microsoft SMTP Server (TLS) id 15.1.485.9; Tue, 3 May 2016 21:14:09 +0000 Received: from AM1FFO11FD023.protection.gbl (2a01:111:f400:7e00::197) by HE1PR0401CA0020.outlook.office365.com (2a01:111:e400:c512::30) with Microsoft SMTP Server (TLS) id 15.1.485.9 via Frontend Transport; Tue, 3 May 2016 21:14:09 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; tcs.com; dkim=none (message not signed) header.d=none;tcs.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by AM1FFO11FD023.mail.protection.outlook.com (10.174.64.212) with Microsoft SMTP Server (TLS) id 15.1.477.4 via Frontend Transport; Tue, 3 May 2016 21:14:09 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0172.MGDPHG.emi.philips.com (141.251.190.20) with Microsoft SMTP Server (TLS) id 15.1.477.8; Tue, 3 May 2016 21:14:08 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0477.015; Tue, 3 May 2016 21:14:08 +0000 From: "Dijk, Esko" To: Abhijan Bhattacharyya Thread-Topic: Using draft-tcs-coap-no-response-option to *enable* responses Thread-Index: AdGcj/YQCrN+XzqqSpmFRQBEAJ7w2AAGgNwAAdGkGKAADDQpgAAiU7HwADKsxYAAAhrcgA== Date: Tue, 3 May 2016 21:14:08 +0000 Message-ID: References: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.73.250.218] X-MS-Office365-Filtering-Correlation-Id: 013b72ee-7b94-4c88-e938-08d37397de3c Content-Type: multipart/alternative; boundary="_000_fb9c8baf329b4cc6a4c890d84b0236dfHE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(428002)(374574003)(189002)(199003)(377454003)(19580395003)(19580405001)(230783001)(19300405004)(105586002)(106466001)(76176999)(54356999)(5890100001)(24736003)(5004730100002)(50986999)(4326007)(8936002)(1220700001)(16236675004)(2906002)(33646002)(108616004)(19625215002)(19617315012)(19625305001)(512874002)(9326002)(81166005)(16601075003)(16796002)(5008740100001)(92566002)(66066001)(586003)(102836003)(3846002)(87936001)(6806005)(84326002)(189998001)(15975445007)(93886004)(2950100001)(2900100001)(110136002)(11100500001)(101416001)(10400500002)(86362001)(790700001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB1584; H:011-smtp-out.Philips.com; FPR:; SPF:None; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD023; 1:nudxvgv7VtEH/NLR45o8AqiH77J+yguu96MFOIJvd2FlzjurFMZLsnCoFaczFcaDXQt4iDg4HbvFTTRHaQKMOIum/puwdIxIULSH2aFCPxdneGca7LQa6RoLAqn5n+60hTlTXq/vvsQAF27MWNhpPwi2J1o9AjD3gGO2qtpzBLR/iimh5BRgpO39vfDjshRHjcJvHHDNSWNRcDLta4Dadlo5RtPOM4kWIlFog6m7TBxNa2pxA2xc6o9EVxPOJGnLsxgzUjdtr9WfmBhsJIGK7DngVXYTupJxwsoCcWyRcZ3nZZU+W9GXd1HSgHXUD1d5t+TWkOlGktxqwRhvxEWPjhbwZbtIk9ISXbZW7BfRN0VJlrDdxJrfh2AJ3rsQWPV/ruVqpdaOE+g2btcxPqcV08R0trMrA+eMA68FYQPLb/ijEdme6G/QCQuu+HYuns37 X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 2:CIFUh61B/7ybZ/aeiwNhUHmslSh4/YAFdqs+9sHyftDwzMgDzb1YM4LCLNJ44GURvxTPx+qHb/LmM+X1yiuuPthSzPLr+HKlkHqRCc5gy23b4TcDOF8bjVty0ehAzCPGstZfwLkGtZpz40wc54pQGnjmzCc68O9evx8LWuGTf76PTCYZwP5wy40vUsVrp89x; 3:f/OObQKaIEl2sBPloxpEp84aPyad7uSYEW+BMk+AaFFCaVmF4Y0Zncq/NWjrktIkNiBZwns0YTuDgF4VX8ngl6PyyJ2Ryo45dj1jtQ63zFosA863H5djwUs8YAqDgcs8XNjSIT1wBGdyJWmUhNZvV0QGnbefWNtpa80erDUZxPXDxhqnW3Uv4ZAuhi07EvJjGj6CqvgKOJLVkBa/l73EV6e14dpotOKLv06SQDHsg4U=; 25:ZJUtPh1sRp9jIdenlsCQAPH9WRQqZ1/5Gu9Mg4YE6TZQlNWQOXyKM+msIxy5MC3CC44TnLxTzIRE6+zuMm6fpejnURzU15FIT6jOODJGQ3DFxzAgsJk5SURO6b8047qjneVeWY2AJ+0FsES/XU3SYGBxSDSbe1p4UsOaDASUjjcPlIj2GtS0+3LGsS9tDbl7xMcezzxsd1H2f0SSUnucmb612aLM0ZVdVu4aA1kkFbCZmdaOWL2/wh6Tlh4/5UjwmQ5VXkRChq2lydpqbR7sczguYXF/gbl01S+jNmk4XiVdwOB/9/hDyjnKmk3Y+AH70/aSlHwCmF6aI7eL6cvIW+4/NldCZbnZHsUmZOf76OJ882zFfv3BYlQucW4eGRBCphkr+Sbo0ljyKO6RqXlKrXkt3J74NbuHoGrjyrkMDycxIWZwJznbyvOOgok4XQYY X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB1584; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 20:wEOVssZgk+AruuYPFt0akVdLNSu5BJI9kLo5ZKmch7d7vkKoCcQzx1/QRD3oemMC2P1qQqRrve2vXsOuy2pCQpyMkcE3ybNNj6nYBEQwoxl97M4fb6dgbyimR4OyTxhA3G7RW7B1sWPiz/eblRkJnYHz3cTK/dR7mhSX0ZbOawmJnBhj21LVhqdqMtyGtAOgT3ne9BsNMGOW66XRnvABvm4EeuCtdA/UPD/cDSPCTVWDIleuHhg9m+2nihnkplmoNwKhtSFwSNCkfVYiAngJUJ7QsBEjN6Qiqpptozf0Uw2MARdptNwOU+Dd9ZkNPEcN1TShVzrciObtA2rCotSkrcf+189riMBBEqyTJ/55Cob4PUCUtdCD/5K9/ZuBXbhfDwqNHEgqY6yod6zvpgq4ADDAxtIG6PlpVOeVInCfGT56ifZFDStK+qo40x69JHmANjzMgugOYSZMwEIzPxst3lPXDT0/Xoafb5typKICCW/9EpsFagaIXQvOUK0oGTZL X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(114017886912203)(220618547472400); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521096)(601004)(2401047)(13018025)(13016025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:VI1PR04MB1584; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB1584; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 4:1uFKWN0NnYgu1rMQBJcRpQdO49vNrypkziVIaEg+LbGq4UXsRFBmEsh4lqSl9ievKIIg8C0h0GJMzMWPLBGaBz//xP8WfuxMn4zCX1JYENYhsfXDKQmYipfi8PV/E9wBbdCd+E1g5StlSYHVfj0697TmVDx7NZZ7P02XpUGWumEm/FEO0oflSSIDH/jPQgxrv6ZQKluF2oF3oGpy58LIgKaHiAj6eSIHVq35JSWfFWJ1/gEK6RJEAiEGgqOA8VanX/CGLpOut/QNCOx7B33RM85zzNmxogAvQIp4DAO2qPmvGD8UoiqrqSJ7mQTYseUY1o0LshUK9laSZF4MDYt2Sep4LFkj13EJ2H36zodLzSUZ7qx6vzMcRsStjMD2OiWlKAXYwRdLQyXCPQ19hKbFpDJLnFtRasGm4nc88wG8ktiKDbWBKK10qay3iq2VjTyk5pz4auW90DqXKvkKnxeUgLJiSqIYYGj/A4hiOFAqD8KBJF1s+fU0i3Uyc471AHwyohn+QkSDtftoFR04A+rMUw== X-Forefront-PRVS: 0931CB1479 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR04MB1584; 23:PgmIwxoD6AUZgCLIIxqyh8kkdwNgwAxShP12XqHo3?= =?us-ascii?Q?3l54dkw8NriCvwP9y4B4i1DDAcYFeckl3pGWINJ0GTAMERQUHB7FIir1u73n?= =?us-ascii?Q?KsoxsXjPsuHJbfs+gcCpcD8GjZ67lvwseOysCc7e2r4YW/LIm0wLRzV8Lako?= =?us-ascii?Q?0wSqkH6QCvmsxq53Z+IbDaQgumv958msTI6sJxO3A8+N7gOlmJMJxOsms6zN?= =?us-ascii?Q?z68NyWC66yqn4OPot4H8dAbART8x8RtBgXw8sd7T0lkxFUDX3V3/YsTvmH75?= =?us-ascii?Q?clcza16ENtKNtk1zhZyP5K0/53sX1+rU+z5Zl738MXVVm7QkD1PaNQC70kvj?= =?us-ascii?Q?Jj5EoWazsdMGuWLkU9lFVjKQRVtA5i1BFyQgDwrt6e6cqp3v4bIF2gf3uw2A?= =?us-ascii?Q?f2lNLYG/PVgPMSEc0W+YODA/JzlvFAqM4uJdMFqdZf/9jV1sIW4T30BiwIaR?= =?us-ascii?Q?PyMwnI3zOclUjFt/2Bn7XlWf+M6HoJfGUpB1hA6Tl2L1yweGjNntam8kMxds?= =?us-ascii?Q?mp64gG9zFc0Rmlr2T0QZhN3VW9xhHddhqh0A5K1h244etNpKawePFyp9bhQM?= =?us-ascii?Q?E31WIIAHhN3a5Gr57KtfcX9VZXDXimuXeSe4bfmQD+KevQZV09oyPUetsgbR?= =?us-ascii?Q?5cfP2Q1Y4YQx4/9AHpYnSetm/NwGYqqmaLP2YeOP4LOiI9FU1JAOK13mO2UP?= =?us-ascii?Q?KSBClIVKr7tNfOvwm+s7owadxqTb1+M1leYIKOCcO4srx5uX+KzHwo46nEwI?= =?us-ascii?Q?R0xlcAHdDLpL/G4zLZ6n2aDV57GHCFtXB6qgk4fnpZlODkStdwN4QuuvYMoS?= =?us-ascii?Q?YcggEmA8thq05n9h6V05cdvdFmNDByUzLQUJkU6DUo09njKByfyiiH47dzn/?= =?us-ascii?Q?sL1gH+BQfvOtynG6j8rC/MWYmI4DYvRSW8RfNYI79/jBuZfrO6kDj/CTI0gi?= =?us-ascii?Q?l0HFyqI9kQD1Icyzil/D1JEJZESf7GfmrkcDorXd2vpeXFmJL/VTFD2net79?= =?us-ascii?Q?ugWKrTZbG1y2pEO7/zMowUfvDQkPCvCCu6GXLiJvMF/U/nY5E5JLn66nhY3H?= =?us-ascii?Q?Y+YDxG+F5Vv027xcdyry6wJspkrE+R+/PPGTP/HR8WqnEsGo95Plko5yPceI?= =?us-ascii?Q?tC6/nK1qVpBtIs8Kmers3TkP5wfu7KC6SZZWDsUAuJrgzPdfpu98E1ct9E8A?= =?us-ascii?Q?y5RMz31F80J7roEhoY8VdfzpnRiTgq9I7F8NqIV5MnYkpnXVYnzzpFKeQjUy?= =?us-ascii?Q?6JQIkqztnWZpaK0nnH/e3sghCEN6sSc7Imjks5NBT2dzIoaw2/5L9WYAa1rR?= =?us-ascii?Q?ql9XkDqHdo8jIJjbHrcOFNbLQN9mDLZaW+LGlZ+l1WuIej8pcafoSHS30T4S?= =?us-ascii?Q?MaToI94ZhwrzOyiW9hzE8O9kJiW6cSrsRXoYb3Iukv7Yb2B?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1584; 5:bF2kPEmoMLZTAPiuVY98OUH8NZd+cRqq7p3+F4O/jU27XCGSo8Sakc9wQ8RPMkef+3EFawTMedA/kzb7H5yLqo3lqAlD6keuBbjuUFkfsmUrvNdwzhAj9n2TlinceujjSnWeJ72kgGL2/TW0ylNA+w==; 24:gRFltWRNyy/dLsPgRigK6IdcJHqEltoTYYyBqfF3IAJdTwmCmFCGp1HHBcLgs6N1rUYbsXENmAFWU+qgh7mxR5wX2gzkppfM0RiiiZZUI4o=; 7:L/+0OLA453pYTJzBoi2Rpbs7g4VKtRlvnorwNgiw2oi5D1iTYJkyfQYV4dPVgcElefsH7Dojy0R2b1It3wb2hHcc/L8EHmzl5SoSV6ig3Xjs6ujRBGcsjN6MbS6U0Jhm0/s3E9rsfb8UtkTx32rjvds/JLN3cd9tTDxqIGdG/hLZkJjWv/f+A+K6n9qHEaAI SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2016 21:14:09.4381 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB1584 Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 21:14:42 -0000 --_000_fb9c8baf329b4cc6a4c890d84b0236dfHE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWJoaWphbiwNCg0KQWdyZWVkOyBiZWxvdyBhIHByb3Bvc2VkIHVwZGF0ZWQgdGV4dCB0 aGF0IHNlcGFyYXRlcyB0aGUgZXhhbXBsZSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIHBhcnQuIFRo ZSBudW1iZXIgb2YgTVVTVHMgaXMgYWxzbyByZWR1Y2VkIHRvIHR3by4gKE1pZ2h0IGJlIGV2ZW4g cmVkdWNlZCB0byBvbmUg4oCTIG9ubHkgdGhlIGZpcnN0LCBidXQgbGVhdmluZyB0aGF0IHRvIHRo ZSBlZGl0aW5nIHByb2Nlc3PigKYgSSB0aGluayBhbiBleGFtcGxlIHR5cGljYWxseSBkb2VzIG5v dCBoYXZlIGEgTVVTVCkNCg0KLS0tDQpUaGUgc2VydmVyIE1VU1Qgc2VuZCBiYWNrIHJlc3BvbnNl cyBvZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2ggdGhlIGNsaWVudCBoYXMgbm90IGV4cHJlc3NlZCBh bnkgZGlzaW50ZXJlc3QuIFRoZXJlIGFyZSBpbnN0YW5jZXMgd2hlcmUgYSBzZXJ2ZXIsIG9uIGl0 cyBvd24sIGRlY2lkZXMgdG8gc3VwcHJlc3MgcmVzcG9uc2VzIGxpa2UgdGhlIG11bHRpY2FzdCBz ZXJ2ZXJzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuNyBvZiAgW1JGQzczOTBdLiBJZiBzdWNoIGEg c2VydmVyIHJlY2VpdmVzIGEgcmVxdWVzdCB3aXRoIGEgTm8tUmVzcG9uc2UgT3B0aW9uIHNob3dp bmcgaW50ZXJlc3QgaW4gc3BlY2lmaWMgcmVzcG9uc2UgY2xhc3NlcywgdGhlbiBhbnkgZGVmYXVs dCBiZWhhdmlvdXIgb2Ygc3VwcHJlc3NpbmcgcmVzcG9uc2VzIOKAkyBpZiBwcmVzZW50IOKAkyBN VVNUIGJlIG92ZXJyaWRkZW4gdG8gZGVsaXZlciB0aG9zZSByZXNwb25zZXMgd2hpY2ggYXJlIG9m IGludGVyZXN0IHRvIHRoZSBjbGllbnQuDQoNClNvLCBmb3IgZXhhbXBsZSwgaWYgYSBtdWx0aWNh c3Qgc2VydmVyIHN1cHByZXNzZXMgYWxsIHJlc3BvbnNlcyBieSBkZWZhdWx0IGFuZCByZWNlaXZl cyBhIHJlcXVlc3Qgd2l0aCBhIE5vLVJlc3BvbnNlIE9wdGlvbiBleHByZXNzaW5nIGRpc2ludGVy ZXN0IGluIDIueHggc3VjY2VzcyByZXNwb25zZXMsIGFuZCBpbnRlcmVzdCBpbiBlcnJvciByZXNw b25zZXMgNC54eC81Lnh4LCB0aGVuIHRoZSBzZXJ2ZXIgbXVzdCBzZW5kIGJhY2sgYSByZXNwb25z ZSBpZiB0aGUgY29uY2VybmVkIHJlcXVlc3QgY2F1c2VkIGFuIGVycm9yLg0KLS0tDQoNCnJlZ2Fy ZHMsDQpFc2tvDQoNCkZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4u YmhhdHRhY2hhcnl5YUB0Y3MuY29tXQ0KU2VudDogVHVlc2RheSwgTWF5IDAzLCAyMDE2IDIxOjUz DQpUbzogRGlqaywgRXNrbyA8ZXNrby5kaWprQHBoaWxpcHMuY29tPg0KQ2M6IGNvcmVAaWV0Zi5v cmcgV0cgPGNvcmVAaWV0Zi5vcmc+OyBOZXZpbCBCcm93bmxlZSA8cmZjLWlzZUByZmMtZWRpdG9y Lm9yZz4NClN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRp b24gdG8gKmVuYWJsZSogcmVzcG9uc2VzDQoNCkhpIEVza28sDQpUaGFua3MgZm9yIHJlc3BvbmRp bmcuIFRoZSBkaXNjdXNzaW9uIGlzIGxlYWRpbmcgdG8gZXhhY3RseSB3aGF0IEkgd2FzIHRoaW5r aW5nIGFib3V0Lg0KU28sIGlmIHdlIGVuaGFuY2UgdGhlIHRleHQgYXMgYmVsb3cgd291bGQgaXQg YmUgZ29vZCBmb3IgdGhlIHB1cnBvc2U/IFBsZWFzZSBjb21tZW50Lg0KDQoiVGhlIHNlcnZlciBN VVNUIHNlbmQgYmFjayByZXNwb25zZXMgb2YgdGhlIGNsYXNzZXMgZm9yIHdoaWNoIHRoZSBjbGll bnQgaGFzIG5vdCBleHByZXNzZWQgYW55IGRpcy1pbnRlcmVzdC4gVGhlcmUgYXJlIGluc3RhbmNl cyB3aGVyZSBhIHNlcnZlciwgb24gaXRzIG93biwgbWF5IGRlY2lkZSB0byBzdXBwcmVzcyByZXNw b25zZXMgbGlrZSB0aGUgbXVsdGljYXN0IHNlcnZlcnMgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24g Mi43IG9mICBbUkZDNzM5MF0uIElmIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMgYSByZXF1ZXN0IHdpdGgg Tm8tUmVzcG9uc2Ugc2hvd2luZyAnaW50ZXJlc3QnIGluIGNlcnRhaW4gcmVzcG9uc2VzIHRoZW4g c3VjaCBiZWhhdmlvdXIgb2Ygc3VwcHJlc3NpbmcgcmVzcG9uc2VzIGJ5IHNlcnZlcnMgTVVTVCBi ZSBvdmVyLXJpZGRlbiBmb3IgdGhvc2UgcmVzcG9uc2VzIHdoaWNoIGFyZSBvZiBpbnRlcmVzdCB0 byB0aGUgY2xpZW50LiBUaGUgc2VydmVyIE1VU1Qgc2VuZCB0aG9zZSByZXNwb25zZXMgZm9yIHdo aWNoIHRoZSBjbGllbnQgaGFzIG5vdCBleHByZXNzZWQgYW55IGRpc2ludGVyZXN0IChpLmUuLCBl eHByZXNzZWQgJ2ludGVyZXN0JykuIFNvLCBmb3IgZXhhbXBsZSwgaWYgYSBtdWx0aWNhc3Qgc2Vy dmVyIGRlY2lkZXMgdG8gc3VwcHJlc3MgYWxsIHJlc3BvbnNlcyBhbmQgcmVjZWl2ZXMgYSByZXF1 ZXN0IHdpdGggTm8tUmVzcG9uc2Ugb3B0aW9uIGV4cHJlc3NpbmcgZGlzaW50ZXJlc3Qgb25seSBp biBzdWNjZXNzIHJlc3BvbnNlcyBidXQgbm90IGluIGVycm9ycyB0aGVuIHRoZSBzZXJ2ZXIgTVVT VCBzZW5kIGJhY2sgYSByZXNwb25zZSBpZiB0aGUgY29uY2VybmVkIHJlcXVlc3QgY2F1c2VzIGFu IGVycm9yLiAiDQoNCiBIb3BlZnVsbHksIHRoaXMgd2lsbCBzb2x2ZSBhIHBvdGVudGlhbCBwcm9i bGVtIHdoZW4gdGhlIGNsaWVudCBhY3R1YWxseSB3YW50cyB0byBkZWJ1ZyB0aGUgbGlnaHRzIHRo cm91Z2ggZ3JhbnVsYXIgTm8tUmVzcG9uc2UgYnV0IHRoZSBzZXJ2ZXJzIGRlY2lkZSBub3QgdG8g c2VuZCBhIHJlc3BvbnNlIGFzIGRlZmF1bHQgYmVoYXZpb3VyIGFuZCB0aGUgY2xpZW50IGlzIG5l dmVyIGF3YXJlIG9mIHRoYXQuIEhvd2V2ZXIsIGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGFib3Zl IGNvdWxkIGJlIHJlY2lwcm9jYXRlZCBieSBzb21lIHNwZWNpZmljYXRpb24gd2hpY2ggZGVhbHMg d2l0aCB0aGUgc2VydmVyLXNpZGUgYmVoYXZpb3VyLg0KDQpXYWl0aW5nIHRvIGhlYXIgZnJvbSB5 b3UuDQoNClJlZ2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRh bnQNClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1 bHRhbmN5IFNlcnZpY2VzDQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPG1h aWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT4NCldlYnNpdGU6IGh0dHA6Ly93d3cu dGNzLmNvbTxodHRwOi8vd3d3LnRjcy5jb20vPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkV4cGVyaWVuY2UgY2VydGFpbnR5LiAgICAgICAgSVQgU2Vydmlj ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAg ICAgICAgICAgICAgIENvbnN1bHRpbmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCg0KIkRpamssIEVza28iIDxlc2tvLmRpamtAcGhpbGlwcy5jb208bWFp bHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbT4+IHdyb3RlIG9uIDA1LzAzLzIwMTYgMDE6MjU6MDEg QU06DQoNCj4gRnJvbTogIkRpamssIEVza28iIDxlc2tvLmRpamtAcGhpbGlwcy5jb208bWFpbHRv OmVza28uZGlqa0BwaGlsaXBzLmNvbT4+DQo+IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgPGFi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPG1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFA dGNzLmNvbT4+DQo+IENjOiAiY29yZUBpZXRmLm9yZyBXRzxtYWlsdG86Y29yZUBpZXRmLm9yZyUy MFdHPiIgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+PiwgTmV2aWwgQnJvd25s ZWUgPHJmYy1pc2VAcmZjLQ0KPiBlZGl0b3Iub3JnPg0KPiBEYXRlOiAwNS8wMy8yMDE2IDAxOjI1 IEFNDQo+IFN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRp b24gdG8gKmVuYWJsZSogcmVzcG9uc2VzDQo+DQo+IEhpLA0KPg0KPiA+ICJUaGUgc2VydmVyIE1V U1Qgc2VuZCBiYWNrIHJlc3BvbnNlcyBvZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2ggdGhlDQo+IGNs aWVudCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiIgLQ0KPiBUaGlzIGNvdmVy cyBwYXJ0IG9mIG15IHVzZSBjYXNlOyBob3dldmVyIGl0IGlzIG5vdCBjbGVhciBob3cgdGhpcw0K PiAiTVVTVCIgaW50ZXJhY3RzIHdpdGggdGhlICJNQVkgc3VwcHJlc3MiIG9mIFJGQyA3MjUyIGZv ciB0aGUNCj4gbXVsdGljYXN0IGNhc2UuIENhbiB0aGUgc2VydmVyIHN0aWxsIGRlY2lkZSB0byBz dXBwcmVzcyB0aGUNCj4gbXVsdGljYXN0IHJlc3BvbnNlIGV2ZW4gaWYgdGhlIE5vLVJlc3BvbnNl IE9wdGlvbiBzZW50IGJ5IHRoZSBjbGllbnQNCj4gc2F5cyBub3QgdG8/IFRoaW5raW5nIGFib3V0 IGl0LCBpdCB3b3VsZCBiZSBwZXJoYXBzIGdvb2QgaWYgZHJhZnQtDQo+IHRjcy1jb2FwLW5vLXJl c3BvbnNlLW9wdGlvbiB3b3VsZCBtYWtlIHRoYXQgY2xlYXIuIFRoZSAiTVVTVCIgYW5kDQo+IHRo ZSB1c2UgY2FzZSA0LjIuMSBzdWdnZXN0IHRoYXQgdGhlIGRlZmF1bHQgc3VwcHJlc3Npb24gY2hv aWNlcyBvZg0KPiB0aGUgc2VydmVyIGFyZSBvdmVycmlkZGVuIGJ5IHRoZSBOby1SZXNwb25zZSBv cHRpb24gYnV0IHRoYXQgaXMgbm90DQo+IHdyaXR0ZW4gZXhwbGljaXRseSB5ZXQuICBJZiB0aGF0 IGlzIHRoZSBjYXNlLCBteSB1c2UgY2FzZSBpcyBmdWxseQ0KPiBjb3ZlcmVkIGJ5IHlvdXIgZHJh ZnQgSSB0aGluay4NCj4NCj4gQW4gdXBkYXRlIG9yIHN1Y2Nlc3NvciB0byB0aGUgR3JvdXBjb21t IFJGQyBjb3VsZCBpbmRlZWQgZGVzY3JpYmUNCj4gaG93IHRoZSBOby1SZXNwb25zZSBPcHRpb24g Y2FuIGJlIHVzZWQgZm9yIG11bHRpY2FzdCB1c2UgY2FzZXMuIEl0DQo+IHdvdWxkIGJlIGdyZWF0 IGlmIHRoYXQgY291bGQgYmUgZG9uZSB3aXRob3V0IG5lZWRpbmcgZnVydGhlcg0KPiBtb2RpZmlj YXRpb25zIHRvIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiENCj4NCj4gcmVnYXJk cw0KPiBFc2tvDQo+DQo+IEZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlq YW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tXQ0KPiBTZW50OiBNb25kYXksIE1heSAwMiwgMjAxNiA1 OjE5DQo+IFRvOiBEaWprLCBFc2tvIDxlc2tvLmRpamtAcGhpbGlwcy5jb208bWFpbHRvOmVza28u ZGlqa0BwaGlsaXBzLmNvbT4+DQo+IENjOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYu b3JnPiBXRyA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+OyBOZXZpbCBCcm93 bmxlZSA8cmZjLWlzZUByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWlzZUByZmMtZWRpdG9yLm9y Zz4+DQo+IFN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRp b24gdG8gKmVuYWJsZSogcmVzcG9uc2VzDQo+IEltcG9ydGFuY2U6IEhpZ2gNCj4NCj4gSGkgRXNr bywNCj4gVGhlIGV4aXN0aW5nIHZlcnNpb24gLTE2IGhhcyB0aGUgZm9sbG93aW5nIHRleHQgaW4g c2VjdGlvbiAyLjEgKHBhZ2UgNSkgOg0KPiAiVGhlIHNlcnZlciBNVVNUIHNlbmQgYmFjayByZXNw b25zZXMgb2YgdGhlIGNsYXNzZXMgZm9yIHdoaWNoIHRoZQ0KPiBjbGllbnQgaGFzIG5vdCBleHBy ZXNzZWQgYW55IGRpcy1pbnRlcmVzdC4iDQo+IFNvLCB0aGF0IHdheSB0aGUgY2xpZW50IGhhcyBh Y3R1YWxseSBleHByZXNzZWQgaXRzIGludGVyZXN0IChvcg0KPiByZXF1ZXN0IGZvciBlbmFibGVt ZW50KSBpbiBhbGwgdGhlIHJlc3BvbnNlcyBmb3Igd2hpY2ggaXQgaGFzIG5vdA0KPiBleHByZXNz ZWQgZXhwbGljaXQgZGlzaW50ZXJlc3QuIERvZXMgdGhhdCBoZWxwIHRvIGNvbnRyb2wgdGhlDQo+ IHNwZWNpYWwgc2VydmVyLXNpZGUgYmVoYXZpb3VyIGFzIHRoZSBzZXJ2ZXIga25vd3Mgd2hpY2gg YWxsDQo+IHJlc3BvbnNlcyB0aGUgY2xpZW50IGlzIGludGVyZXN0ZWQgaW4gYW5kIGl0IE1VU1Qg c2VuZCBhIHJlc3BvbnNlDQo+IGJhY2sgPyBJIHNoYWxsIHN1Ym1pdCBhbm90aGVyIHZlcnNpb24g d2l0aCBzb21lIGVkaXRvcmlhbCBjaGFuZ2VzDQo+IGJlZm9yZSB0aGUgZHJhZnQgZ29lcyB0byBJ RVNHLiBTbyB3ZSBoYXZlIHNvbWUgbW9yZSByb29tIGZvcg0KPiBtb2RpZmljYXRpb24uIElmIHlv dSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhpcyBpbiB0aGUgbGluZSBvZiB0aGUNCj4gZGlzY3Vz c2lvbiB3ZSBhcmUgaGF2aW5nLCBwbGVhc2UgbGV0IHVzIGtub3cuIEkgc2hhbGwgd2FpdCBmb3Ig eW91cg0KPiB2aWV3cyBiZWZvcmUgc3VibWl0dGluZyB0aGUgdXBkYXRlZCB2ZXJzaW9uLg0KPg0K PiBBbnl3YXksIGEgc2VwYXJhdGUgZHJhZnQgKG9yLCBwb3NzaWJseSwgYW4gdXBkYXRlZCBncm91 cGNvbW0gUkZDPykNCj4gaXMgYSBnb29kIGlkZWEuIE5vLVJlc3BvbnNlIGFzc3VtZXMgdGhlIHVz dWFsIHJlcXVlc3QvcmVzcG9uc2UNCj4gc3ltYW50aWNzIGFuZCBpdCBtYWlubHkgYWRkcmVzc2Vz IHRoZSBjbGllbnQgc2lkZSBiZWhhdmlvdXIgYW5kDQo+IGlzc3Vlcy4gQ29uc2lkZXJpbmcgc3Vj aCBzcGVjaWFsIGJlaGF2aW91ciBvZiBncm91cGNvbW0gc2VydmVycywgaXQNCj4gd291bGQgYmUg Z29vZCB0byBoYW5kbGUgc2VwYXJhdGVseS4NCj4NCj4gV2FpdGluZyB0byBoZWFyIGZyb20geW91 Lg0KPg0KPiBSZWdhcmRzDQo+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiBBc3NvY2lhdGUgQ29u c3VsdGFudA0KPiBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0KPiBU YXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQo+IE1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlh QHRjcy5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPg0KPiBXZWJzaXRl OiBodHRwOi8vd3d3LnRjcy5jb208aHR0cDovL3d3dy50Y3MuY29tLz4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRXhwZXJpZW5jZSBjZXJ0YWludHku ICAgICAgICBJVCBTZXJ2aWNlcw0KPiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNv bHV0aW9ucw0KPiAgICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRpbmcNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4NCj4gIkRpamssIEVza28i IDxlc2tvLmRpamtAcGhpbGlwcy5jb208bWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbT4+IHdy b3RlIG9uIDA1LzAyLzIwMTYgMDM6MTA6MjQgQU06DQo+DQo+ID4gRnJvbTogIkRpamssIEVza28i IDxlc2tvLmRpamtAcGhpbGlwcy5jb208bWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbT4+DQo+ ID4gVG86IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5j b208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPj4NCj4gPiBDYzogImNvcmVA aWV0Zi5vcmcgV0c8bWFpbHRvOmNvcmVAaWV0Zi5vcmclMjBXRz4iIDxjb3JlQGlldGYub3JnPG1h aWx0bzpjb3JlQGlldGYub3JnPj4sIE5ldmlsIEJyb3dubGVlIDxyZmMtaXNlQHJmYy0NCj4gPiBl ZGl0b3Iub3JnPg0KPiA+IERhdGU6IDA1LzAyLzIwMTYgMDM6MTAgQU0NCj4gPiBTdWJqZWN0OiBS RTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUqIHJl c3BvbnNlcw0KPiA+DQo+ID4gSGVsbG8gQWJoaWphbiwNCj4gPg0KPiA+ID4gTWFuZGF0aW5nIHN1 Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBjbGllbnQgc2lkZSB3aWxsIGJlIGEgYml0DQo+ ID4gb3V0LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0KPiA+ IFRoaXMgaXMgbm90IGZ1bGx5IGNsZWFyIHRvIG1lIHlldCDigKYgdGhlIGNsaWVudCBkb2VzIG5v dCBtYW5kYXRlDQo+ID4gYW55dGhpbmcgZnJvbSB0aGUgc2VydmVyOyBpdCBqdXN0IGV4cHJlc3Nl cyBpdHMgaW50ZXJlc3QgKDAtYml0cykNCj4gPiBhbmQgZGlzaW50ZXJlc3QgKDEtYml0cykuIFRo ZSBzZXJ2ZXIgY2FuIGFsd2F5cyBub3QgcGFyc2UgdGhlIG9wdGlvbg0KPiA+IChlbGVjdGl2ZSkg b3IgY2hvb3NlIG5vdCB0byBib3RoZXIgYWJvdXQgaXQuDQo+ID4gVGhpcyBkb2VzIGtlZXAgdGhl IGNsaWVudCB3YWl0aW5nIGZvciBhIHBvc3NpYmxlIHJlc3BvbnNlIHRoYXQgbmV2ZXINCj4gPiBj b21lczsgYnV0IHRoYXQgaXMgdGhlIHNhbWUgaW4gdGhlIGdlbmVyYWwgbXVsdGljYXN0IGNhc2Ug OiB0aGUNCj4gPiBjbGllbnQgY2FuIG5ldmVyIGtub3cgaWYgb3Igd2hlbiBhIHJlc3BvbnNlIHdp bGwgY29tZSwgdGhlIHNlcnZlcg0KPiA+IE1BWSBhbHdheXMgY2hvb3NlIHRvIG5vdCByZXNwb25k Lg0KPiA+DQo+ID4gU28gd2hhdCBJIHByb3Bvc2UgaXMgdG8gdXNlIHRoZSAiaW5kaWNhdGlvbiBv ZiBpbnRlcmVzdCIgdG8gc3BlY2lmaWMNCj4gPiByZXNwb25zZSBjbGFzc2VzIGluIGEgbmV3IHdh eTsgbmFtZWx5IHRvIGVuYWJsZSBjZXJ0YWluIHJlc3BvbnNlDQo+ID4gY2xhc3NlcyB0aGF0IGFy ZSBzdXBwcmVzc2VkIGJ5IGRlZmF1bHQuICBJdCBqdXN0IGhhcHBlbnMgdGhhdCB0aGUNCj4gPiBz YW1lIE9wdGlvbiBzeW50YXggaXMgdmVyeSB3ZWxsIHN1aXRlZCBmb3IgdGhhdCBwdXJwb3NlLiBB IHNlcGFyYXRlDQo+ID4gZHJhZnQgY291bGQgYmUgd3JpdHRlbiBmb3IgdGhhdCBwZXJoYXBzIGlm IHlvdSB0aGluayBpdCBkb2VzIG5vdCBmaXQNCj4gPiBpbiBkcmFmdC10Y3MtY29hcC1uby1yZXNw b25zZS1vcHRpb24gb3IgaWYgaXQgaXMgdG9vIGxhdGUgZm9yIHRoYXQuDQo+ID4gVGhlIHdlIGNh biBwb2ludCB0byB0aGUgc3ludGF4IG9mIHRoZSBOby1SZXNwb25zZSBPcHRpb24gYW5kIHJlLXVz ZQ0KPiA+IGl0IGNvbXBsZXRlbHkuDQo+ID4NCj4gPiByZWdhcmRzDQo+ID4gRXNrbw0KPiA+DQo+ ID4gRnJvbTogQWJoaWphbiBCaGF0dGFjaGFyeXlhIFttYWlsdG86YWJoaWphbi5iaGF0dGFjaGFy eXlhQHRjcy5jb21dDQo+ID4gU2VudDogRnJpZGF5LCBBcHJpbCAyMiwgMjAxNiAxNzoxNw0KPiA+ IFRvOiBEaWprLCBFc2tvIDxlc2tvLmRpamtAcGhpbGlwcy5jb208bWFpbHRvOmVza28uZGlqa0Bw aGlsaXBzLmNvbT4+DQo+ID4gQ2M6IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+ IFdHIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj47IE5ldmlsIEJyb3dubGVl IDxyZmMtaXNlQHJmYy1lZGl0b3Iub3JnDQo8bWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmcl MGI+PiA+DQo+ID4gU3ViamVjdDogUmU6IFVzaW5nIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNl LW9wdGlvbiB0byAqZW5hYmxlKiByZXNwb25zZXMNCj4gPg0KPiA+IEhpIEVza28sDQo+ID4gVGhh bmtzIGZvciB5b3VyIG1haWwuDQo+ID4gRmlyc3Qgb2YgYWxsIGxldCBtZSBqdXN0IGJyaW5nIHRo aXMgdG8geW91ciAoYXMgd2VsbCBhcyB0aGUgbWFpbGluZw0KPiA+IGxpc3Qncykgbm90aWNlIHRo YXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpczoNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2UtDQo+IG9w dGlvbi0xNi50eHQNCj4gPg0KPiA+IFRoaXMgdmVyc2lvbiAib2ZmaWNpYWxseSIgY2xvc2VzIHRo ZSB0ZWNobmljYWwgcmV2aWV3cyBhbmQgaXMgd2l0aA0KPiA+IHRoZSBSRkMgZWRpdG9yIHRocm91 Z2ggdGhlIElTIHRyYWNrLg0KPiA+DQo+ID4gTm93IGNvbWluZyB0byB5b3VyIHVzZSBjYXNlIChh bmQgaW5kZWVkIGl0IGlzIGFuIGludGVyZXN0aW5nIG9uZSkNCj4gPiBvbmUgdGhpbmcgdGhhdCB3 ZSBzaG91bGQgY29uc2lkZXIgaXMgdGhhdCB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9uIHdhcw0KPiA+ IGRlbGliZXJhdGVseSBkZXNpZ25lZCBub3QgdG8gbWFuZGF0ZSBhbnl0aGluZyBmb3IgdGhlIHNl cnZlciBzaWRlDQo+ID4gbWFpbmx5IHRvIGVuc3VyZSB0aGF0IGl0IGRvZXMgbm90IGRpc3J1cHQg dGhlIG1hbnkgdXNlZnVsbmVzcyBvZiB0aGUNCj4gPiB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIHN5 bWFudGljcy4gVGhlIGRyYWZ0IGFsbCBhbG9uZyBkZWFscyB3aXRoIHRoZQ0KPiA+IHJlcXVlc3Rp bmcgY2xpZW50J3MgYmVoYXZpb3VyIGFuZCBpdHMgZXhwcmVzc2lvbiBvZiBpbnRlcmVzdCB0byB0 aGUNCj4gPiBzZXJ2ZXIuIFNpbmNlIHRoaXMgb3B0aW9uIGlzIGVsZWN0aXZlIHdlIGxlYXZlIGl0 IHVwdG8gdGhlIHNlcnZlcg0KPiA+IGltcGxlbWVudGF0aW9uIHRvIGhvbm91ciB0aGUgY2xpZW50 J3MgaW50ZXJlc3QuDQo+ID4NCj4gPiBOb3csIGFzIHBlciB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNl IHN5bWFudGljcyB0aGUgcmVzcG9uc2VzIGFyZQ0KPiA+IGFsd2F5cyBlbmFibGVkLiBUaGUgYmVo YXZpb3VyIGluIGdyb3VwY29tbSBzZXJ2ZXIgaW4gdGVybXMgb2YNCj4gPiBzdXBwcmVzc2luZyB0 aGUgcmVzcG9uc2VzIG9uIGl0cyBvd24gaXMgc29tZXRoaW5nIHNwZWNpYWwgYW5kLA0KPiA+IGdl bmVyYWxseSBzcGVha2luZywgdGhlIGNsaWVudHMgYXJlIG5vdCBhd2FyZSBvZiBzdWNoIHNwZWNp YWwgYmVoYXZpb3VyLg0KPiA+DQo+ID4gU28sIGl0IHdvdWxkIGJlIGp1c3RpZmllZCB0byBoYW5k bGUgdGhlIHNpdHVhdGlvbiBhdCB0aGUgc2VydmVyJ3MNCj4gPiBlbmQuIEhlcmUgaXMgdGhlIGlk ZWE6DQo+ID4gV2hpbGUgTm8tUmVzcG9uc2UgaXMgdG8gZXhwcmVzc2VzIGNsaWVudCdzIGRpcy1p bnRlcmVzdCBpbiBzb21lIG9yDQo+ID4gYWxsIG9mIHRoZSByZXNwb25zZXMgZGVwZW5kaW5nIG9u IHRoZSBvcHRpb24gdmFsdWUsIGl0IGlzIGFsc28gdHJ1ZQ0KPiA+IHRoYXQgdGhlIG9wdGlvbiBh dXRvbWF0aWNhbGx5IGV4cHJlc3NlcyBpbnRlcmVzdCBpbiBhbGwgb3RoZXINCj4gPiByZXNwb25z ZXMgKG1hcmtlZCBieSAwJ3MgaW4gdGhlIHJlc3BlY3RpdmUgcG9zaXRpb25zKS4gVGhlIGNsaWVu dCBpcw0KPiA+IGdvaW5nIHRvIHdhaXQgZm9yIHRoZXNlIHJlc3BvbnNlcyB1cHRvIGEgZ2l2ZW4g dGltZW91dC4gTm93LCBpZiB0aGUNCj4gPiBzZXJ2ZXIgYmVoYXZpb3VyIGlzIG1vZGlmaWVkIGxp a2UgdGhpcyA6ICJJIGhhdmUgY2xvc2VkIG15IGRvb3IgZm9yDQo+ID4gYWxsIG91dCBnb2luZyBy ZXNwb25zZS4gKipCVVQqKiwgaWYgSSBzZWUgYSBmZWxsb3cgcmVxdWVzdGluZyB3aXRoDQo+ID4g Tm8tUmVzcG9uc2UgYW5kIGtlZXBpbmcgd2luZG93cyBvcGVuIHRvIHNvbWUgcmVzcG9uc2VzIHRo ZW4gSSBhc3N1bWUNCj4gPiB0aGF0IHRoaXMgZ3V5IHJlYWxseSBuZWVkcyB0aG9zZSBraW5kIG9m IHJlc3BvbnNlcy4gSW4gdGhhdCBjYXNlIGxldA0KPiA+IG1lIGJlIGxpbmllbnQgYW5kIGxldCBt ZSBvcGVuIHRoZSBkb29yIGZvciBzdWNoIHJlc3BvbnNlcy4gVGhpcw0KPiA+IGZlbGxvdyBtdXN0 IGJlIGF2YWlsYWJsZSB0byBsaXN0ZW4gdG8gdGhlbSBhcyBwZXIgdGhlIHByZXNjcmliZWQNCj4g PiBiZWhhdmlvdXIgaW4gdGhlIE5vLVJlc3BvbnNlIHNwZWNpZmljYXRpb24uIg0KPiA+DQo+ID4g TWFuZGF0aW5nIHN1Y2ggc2VydmVyIGJlaGF2aW91ciBmcm9tIHRoZSBjbGllbnQgc2lkZSB3aWxs IGJlIGEgYml0DQo+ID4gb3V0LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZp Y2F0aW9uLg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiA+ IEFzc29jaWF0ZSBDb25zdWx0YW50DQo+ID4gU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29s a2F0YSwgSW5kaWENCj4gPiBUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQo+ID4gTWFpbHRvOiBh YmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlh QHRjcy5jb20+DQo+ID4gV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tPGh0dHA6Ly93d3cudGNz LmNvbS8+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBFeHBlcmllbmNlIGNlcnRhaW50eS4gICAgICAgIElUIFNlcnZpY2VzDQo+ID4gICAgICAg ICAgICAgICAgICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCj4gPiAgICAgICAgICAgICAgICAg ICAgICAgIENvbnN1bHRpbmcNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gRnJvbTogICAgICAgICJEaWprLCBF c2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPG1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20+ Pg0KPiA+IFRvOiAgICAgICAgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxhYmhpamFuLmJoYXR0YWNo YXJ5eWFAdGNzLmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+Pg0KPiA+ IENjOiAgICAgICAgTmV2aWwgQnJvd25sZWUgPHJmYy1pc2VAcmZjLWVkaXRvci5vcmc8bWFpbHRv OnJmYy1pc2VAcmZjLWVkaXRvci5vcmc+PiwgImNvcmVAaWV0Zi5vcmcgV0c8bWFpbHRvOmNvcmVA aWV0Zi5vcmclMjBXRz4iIDwNCj4gPiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3Jn Pj4NCj4gPiBEYXRlOiAgICAgICAgMDQvMjIvMjAxNiAwNTo0MyBQTQ0KPiA+IFN1YmplY3Q6ICAg ICAgICBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gdG8NCj4gKmVuYWJs ZSogcmVzcG9uc2VzDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBIZWxsbyBBYmhpamFuLA0KPiA+ DQo+ID4gaW4gb3VyIHByb2plY3Qgd2Ugc2VlIGEgY2xlYXIgdXNlIGNhc2Ugb2YgdXNpbmcgdGhl IE5vLVJlc3BvbnNlDQo+ID4gT3B0aW9uIHRvICplbmFibGUqIGNlcnRhaW4gcmVzcG9uc2VzIHRo YXQgYXJlIGJ5IGRlZmF1bHQgc3VwcHJlc3NlZC4NCj4gPiBDb0FQIGFsbG93cyBzdXBwcmVzc2lv biBvZiBtdWx0aWNhc3QgcmVzcG9uc2VzIGJ5IGRlZmF1bHQsIHdoaWNoIGlzDQo+ID4gd2hhdCB3 ZSB1c2UgZm9yIGEgbGlnaHRpbmcgbXVsdGljYXN0IHVzZSBjYXNlLiBIb3dldmVyIGZvcg0KPiA+ IGRpYWdub3N0aWMgdXNhZ2Ugd2UnZCBsaWtlIHRvIGVuYWJsZSB0aGVzZSByZXNwb25zZXMgYWdh aW4gdXNpbmcgdGhlDQo+ID4gTm8tUmVzcG9uc2Ugb3B0aW9uIHdoaWNoIGlzIHBlcmZlY3RseSBz dWl0ZWQgZm9yIHRoYXQuIEhvd2V2ZXIsIHRoZQ0KPiA+IGRyYWZ0IHRleHQgY3VycmVudGx5IG9u bHkgdGFsa3MgYWJvdXQgc3VwcHJlc3NpbmcgcmVzcG9uc2VzIChub3QgZW5hYmxpbmcpLg0KPiA+ DQo+ID4gSGVuY2UgbXkgcmVxdWVzdDogY291bGQgd2UgbW9kaWZ5L2FkZCBzb21lIHRleHQgdG8g c2hvdyB0aGF0IGFsc28NCj4gPiB0aGUgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGVuYWJsZSByZXNw b25zZXMgaW4gY2FzZSB3aGVyZSB0aGV5IGFyZQ0KPiA+IG5vcm1hbGx5IChieSBkZWZhdWx0IC0t IHNlcnZlciBkZWNpc2lvbikgc3VwcHJlc3NlZD8NCj4gPiBKdXN0IHRvIGNsYXJpZnkgc3VjaCB1 c2FnZTsgd2hpY2ggaXMgcXVpdGUgdXNlZnVsIGluIG15IHZpZXcuDQo+ID4NCj4gPiByZWdhcmRz DQo+ID4gRXNrbw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlk ZW50aWFsIGFuZA0KPiA+IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBU aGUgbWVzc2FnZSBpcyBpbnRlbmRlZA0KPiA+IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwNCj4gPiB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yDQo+ ID4gcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUNCj4gPiB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlDQo+ID4gc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5k IGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCj4gPiA9PT09PS0t LS0tPT09PT0tLS0tLT09PT09DQo+ID4gTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgZS1tYWlsDQo+ID4gbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5 IGNvbnRhaW4NCj4gPiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYg eW91IGFyZQ0KPiA+IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzc2VtaW5hdGlv biwgdXNlLA0KPiA+IHJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9m IHRoZQ0KPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlDQo+ ID4gYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZg0K PiA+IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwNCj4gPiBw bGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kDQo+ID4gaW1t ZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgbWVzc2FnZQ0KPiA+IGFuZCBhbnkg YXR0YWNobWVudHMuIFRoYW5rIHlvdQ0KPg0KPiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZA0KPiBsZWdhbGx5IHByb3RlY3Rl ZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQNCj4gc29sZWx5 IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LA0KPiB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcs IGRpc3NlbWluYXRpb24sIG9yDQo+IHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlDQo+IHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUNCj4gc2VuZGVyIGJ5IHJl dHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2Fn ZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkg cHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGlu ZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUt bWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K --_000_fb9c8baf329b4cc6a4c890d84b0236dfHE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQp0dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGVsbG8gQWJoaWphbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QWdyZWVkOyBiZWxvdyBhIHByb3Bvc2VkIHVwZGF0ZWQgdGV4dCB0aGF0IHNlcGFyYXRlcyB0 aGUgZXhhbXBsZSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIHBhcnQuIFRoZSBudW1iZXIgb2YgTVVT VHMgaXMgYWxzbyByZWR1Y2VkIHRvIHR3by4gKE1pZ2h0IGJlIGV2ZW4gcmVkdWNlZCB0byBvbmUg 4oCTIG9ubHkNCiB0aGUgZmlyc3QsIGJ1dCBsZWF2aW5nIHRoYXQgdG8gdGhlIGVkaXRpbmcgcHJv Y2Vzc+KApiBJIHRoaW5rIGFuIGV4YW1wbGUgdHlwaWNhbGx5IGRvZXMgbm90IGhhdmUgYSBNVVNU KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBzZXJ2ZXIgTVVTVCBzZW5kIGJhY2sgcmVzcG9u c2VzIG9mIHRoZSBjbGFzc2VzIGZvciB3aGljaCB0aGUgY2xpZW50IGhhcyBub3QgZXhwcmVzc2Vk IGFueSBkaXNpbnRlcmVzdC4gVGhlcmUgYXJlIGluc3RhbmNlcyB3aGVyZSBhIHNlcnZlciwgb24g aXRzIG93biwgZGVjaWRlcyB0byBzdXBwcmVzcw0KIHJlc3BvbnNlcyBsaWtlIHRoZSBtdWx0aWNh c3Qgc2VydmVycyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjcgb2YmbmJzcDsgW1JGQzczOTBdLiBJ ZiBzdWNoIGEgc2VydmVyIHJlY2VpdmVzIGEgcmVxdWVzdCB3aXRoIGEgTm8tUmVzcG9uc2UgT3B0 aW9uIHNob3dpbmcgaW50ZXJlc3QgaW4gc3BlY2lmaWMgcmVzcG9uc2UgY2xhc3NlcywgdGhlbiBh bnkgZGVmYXVsdCBiZWhhdmlvdXIgb2Ygc3VwcHJlc3NpbmcgcmVzcG9uc2VzIOKAkyBpZiBwcmVz ZW50IOKAkyBNVVNUDQogYmUgb3ZlcnJpZGRlbiB0byBkZWxpdmVyIHRob3NlIHJlc3BvbnNlcyB3 aGljaCBhcmUgb2YgaW50ZXJlc3QgdG8gdGhlIGNsaWVudC4gPG86cD4NCjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U28s IGZvciBleGFtcGxlLCBpZiBhIG11bHRpY2FzdCBzZXJ2ZXIgc3VwcHJlc3NlcyBhbGwgcmVzcG9u c2VzIGJ5IGRlZmF1bHQgYW5kIHJlY2VpdmVzIGEgcmVxdWVzdCB3aXRoIGEgTm8tUmVzcG9uc2Ug T3B0aW9uIGV4cHJlc3NpbmcgZGlzaW50ZXJlc3QgaW4gMi54eCBzdWNjZXNzIHJlc3BvbnNlcywN CiBhbmQgaW50ZXJlc3QgaW4gZXJyb3IgcmVzcG9uc2VzIDQueHgvNS54eCwgdGhlbiB0aGUgc2Vy dmVyIG11c3Qgc2VuZCBiYWNrIGEgcmVzcG9uc2UgaWYgdGhlIGNvbmNlcm5lZCByZXF1ZXN0IGNh dXNlZCBhbiBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5yZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXNrbzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWJoaWph biBCaGF0dGFjaGFyeXlhIFttYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDAzLCAyMDE2IDIxOjUzPGJyPg0KPGI+VG86 PC9iPiBEaWprLCBFc2tvICZsdDtlc2tvLmRpamtAcGhpbGlwcy5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBjb3JlQGlldGYub3JnIFdHICZsdDtjb3JlQGlldGYub3JnJmd0OzsgTmV2aWwgQnJvd25s ZWUgJmx0O3JmYy1pc2VAcmZjLWVkaXRvci5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSogcmVz cG9uc2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IaSBF c2tvLDwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgcmVzcG9uZGluZy4g VGhlIGRpc2N1c3Npb24gaXMgbGVhZGluZyB0byBleGFjdGx5IHdoYXQgSSB3YXMgdGhpbmtpbmcg YWJvdXQuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U28sIGlmIHdlIGVuaGFuY2UgdGhl IHRleHQgYXMgYmVsb3cgd291bGQgaXQgYmUgZ29vZCBmb3IgdGhlIHB1cnBvc2U/IFBsZWFzZSBj b21tZW50Ljwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90O1RoZSBzZXJ2 ZXIgTVVTVCBzZW5kIGJhY2sgcmVzcG9uc2VzIG9mIHRoZSBjbGFzc2VzIGZvciB3aGljaCB0aGUg Y2xpZW50IGhhcyBub3QgZXhwcmVzc2VkIGFueSBkaXMtaW50ZXJlc3QuIFRoZXJlIGFyZSBpbnN0 YW5jZXMgd2hlcmUgYSBzZXJ2ZXIsIG9uIGl0cyBvd24sIG1heSBkZWNpZGUgdG8gc3VwcHJlc3Mg cmVzcG9uc2VzIGxpa2UNCiB0aGUgbXVsdGljYXN0IHNlcnZlcnMgYXMgZGVzY3JpYmVkIGluIHNl Y3Rpb24gMi43IG9mICZuYnNwO1tSRkM3MzkwXS4gSWYgdGhlIHNlcnZlciByZWNlaXZlcyBhIHJl cXVlc3Qgd2l0aCBOby1SZXNwb25zZSBzaG93aW5nICdpbnRlcmVzdCcgaW4gY2VydGFpbiByZXNw b25zZXMgdGhlbiBzdWNoIGJlaGF2aW91ciBvZiBzdXBwcmVzc2luZyByZXNwb25zZXMgYnkgc2Vy dmVycyBNVVNUIGJlIG92ZXItcmlkZGVuIGZvciB0aG9zZSByZXNwb25zZXMgd2hpY2gNCiBhcmUg b2YgaW50ZXJlc3QgdG8gdGhlIGNsaWVudC4gVGhlIHNlcnZlciBNVVNUIHNlbmQgdGhvc2UgcmVz cG9uc2VzIGZvciB3aGljaCB0aGUgY2xpZW50IGhhcyBub3QgZXhwcmVzc2VkIGFueSBkaXNpbnRl cmVzdCAoaS5lLiwgZXhwcmVzc2VkICdpbnRlcmVzdCcpLiBTbywgZm9yIGV4YW1wbGUsIGlmIGEg bXVsdGljYXN0IHNlcnZlciBkZWNpZGVzIHRvIHN1cHByZXNzIGFsbCByZXNwb25zZXMgYW5kIHJl Y2VpdmVzIGEgcmVxdWVzdCB3aXRoIE5vLVJlc3BvbnNlDQogb3B0aW9uIGV4cHJlc3NpbmcgZGlz aW50ZXJlc3Qgb25seSBpbiBzdWNjZXNzIHJlc3BvbnNlcyBidXQgbm90IGluIGVycm9ycyB0aGVu IHRoZSBzZXJ2ZXIgTVVTVCBzZW5kIGJhY2sgYSByZXNwb25zZSBpZiB0aGUgY29uY2VybmVkIHJl cXVlc3QgY2F1c2VzIGFuIGVycm9yLiAmcXVvdDs8L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDtIb3BlZnVsbHksIHRoaXMgd2lsbCBzb2x2ZSBhIHBvdGVudGlhbCBwcm9i bGVtIHdoZW4gdGhlIGNsaWVudCBhY3R1YWxseSB3YW50cyB0byBkZWJ1ZyB0aGUgbGlnaHRzIHRo cm91Z2ggZ3JhbnVsYXIgTm8tUmVzcG9uc2UgYnV0IHRoZSBzZXJ2ZXJzIGRlY2lkZSBub3QgdG8g c2VuZCBhIHJlc3BvbnNlIGFzIGRlZmF1bHQgYmVoYXZpb3VyDQogYW5kIHRoZSBjbGllbnQgaXMg bmV2ZXIgYXdhcmUgb2YgdGhhdC4gSG93ZXZlciwgaXQgd291bGQgYmUgZ29vZCBpZiB0aGUgYWJv dmUgY291bGQgYmUgcmVjaXByb2NhdGVkIGJ5IHNvbWUgc3BlY2lmaWNhdGlvbiB3aGljaCBkZWFs cyB3aXRoIHRoZSBzZXJ2ZXItc2lkZSBiZWhhdmlvdXIuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+V2FpdGluZyB0byBoZWFyIGZyb20geW91Ljwvc3Bhbj4NCjxicj4NCjxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHM8YnI+DQpBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQpB c3NvY2lhdGUgQ29uc3VsdGFudDxicj4NClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGth dGEsIEluZGlhPGJyPg0KVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczxicj4NCk1haWx0bzogPGEg aHJlZj0ibWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tIj5hYmhpamFuLmJoYXR0 YWNoYXJ5eWFAdGNzLmNvbTwvYT48YnI+DQpXZWJzaXRlOiA8L3NwYW4+PGEgaHJlZj0iaHR0cDov L3d3dy50Y3MuY29tLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aHR0cDovL3d3dy50Y3MuY29tPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCkV4cGVyaWVuY2UgY2VydGFpbnR5LiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtJVCBTZXJ2aWNlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QnVzaW5l c3MgU29sdXRpb25zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3Nw YW4+PGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mcXVvdDtE aWprLCBFc2tvJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29t Ij5lc2tvLmRpamtAcGhpbGlwcy5jb208L2E+Jmd0OyB3cm90ZSBvbiAwNS8wMy8yMDE2IDAxOjI1 OjAxIEFNOjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+Jmd0OyBGcm9tOiAm cXVvdDtEaWprLCBFc2tvJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZXNrby5kaWprQHBoaWxp cHMuY29tIj5lc2tvLmRpamtAcGhpbGlwcy5jb208L2E+Jmd0OzwvdHQ+PC9zcGFuPg0KPGJyPg0K PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IFRvOiBBYmhpamFuIEJoYXR0 YWNoYXJ5eWEgJmx0OzxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bSI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L2E+Jmd0Ozwvc3Bhbj48L3R0Pg0KPGJy Pg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IENjOiAmcXVvdDs8YSBo cmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyUyMFdHIj5jb3JlQGlldGYub3JnIFdHPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0 OywgTmV2aWwgQnJvd25sZWUgJmx0O3JmYy1pc2VAcmZjLTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8dHQ+Jmd0OyBlZGl0b3Iub3JnJmd0OzwvdHQ+PC9zcGFuPiA8YnI+DQo8dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgRGF0ZTogMDUvMDMvMjAxNiAwMToyNSBBTTwv c3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg U3ViamVjdDogUkU6IFVzaW5nIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAq ZW5hYmxlKiByZXNwb25zZXM8L3NwYW4+PC90dD4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsg SGksPC90dD48L3NwYW4+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7ICZndDsgJnF1b3Q7VGhlIHNlcnZlciBNVVNUIHNlbmQgYmFjayByZXNwb25z ZXMgb2YgdGhlIGNsYXNzZXMgZm9yIHdoaWNoIHRoZQ0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxi cj4NCjx0dD4mZ3Q7IGNsaWVudCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiZx dW90OyAtIDwvdHQ+PC9zcGFuPjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jmd0OyBUaGlzIGNvdmVycyBwYXJ0IG9mIG15IHVzZSBjYXNlOyBob3dldmVyIGl0IGlzIG5v dCBjbGVhciBob3cgdGhpcw0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7ICZx dW90O01VU1QmcXVvdDsgaW50ZXJhY3RzIHdpdGggdGhlICZxdW90O01BWSBzdXBwcmVzcyZxdW90 OyBvZiBSRkMgNzI1MiBmb3IgdGhlIDwvdHQ+PGJyPg0KPHR0PiZndDsgbXVsdGljYXN0IGNhc2Uu IENhbiB0aGUgc2VydmVyIHN0aWxsIGRlY2lkZSB0byBzdXBwcmVzcyB0aGUgPC90dD48YnI+DQo8 dHQ+Jmd0OyBtdWx0aWNhc3QgcmVzcG9uc2UgZXZlbiBpZiB0aGUgTm8tUmVzcG9uc2UgT3B0aW9u IHNlbnQgYnkgdGhlIGNsaWVudDwvdHQ+PGJyPg0KPHR0PiZndDsgc2F5cyBub3QgdG8/IFRoaW5r aW5nIGFib3V0IGl0LCBpdCB3b3VsZCBiZSBwZXJoYXBzIGdvb2QgaWYgZHJhZnQtPC90dD48YnI+ DQo8dHQ+Jmd0OyB0Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gd291bGQgbWFrZSB0aGF0IGNs ZWFyLiBUaGUgJnF1b3Q7TVVTVCZxdW90OyBhbmQgPC90dD48YnI+DQo8dHQ+Jmd0OyB0aGUgdXNl IGNhc2UgNC4yLjEgc3VnZ2VzdCB0aGF0IHRoZSBkZWZhdWx0IHN1cHByZXNzaW9uIGNob2ljZXMg b2YgPC90dD48YnI+DQo8dHQ+Jmd0OyB0aGUgc2VydmVyIGFyZSBvdmVycmlkZGVuIGJ5IHRoZSBO by1SZXNwb25zZSBvcHRpb24gYnV0IHRoYXQgaXMgbm90IDwvdHQ+PGJyPg0KPHR0PiZndDsgd3Jp dHRlbiBleHBsaWNpdGx5IHlldC4gJm5ic3A7SWYgdGhhdCBpcyB0aGUgY2FzZSwgbXkgdXNlIGNh c2UgaXMgZnVsbHkgPC90dD48YnI+DQo8dHQ+Jmd0OyBjb3ZlcmVkIGJ5IHlvdXIgZHJhZnQgSSB0 aGluay48L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsgQW4gdXBkYXRlIG9yIHN1Y2Nlc3NvciB0byB0aGUgR3JvdXBjb21tIFJG QyBjb3VsZCBpbmRlZWQgZGVzY3JpYmUNCjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+ Jmd0OyBob3cgdGhlIE5vLVJlc3BvbnNlIE9wdGlvbiBjYW4gYmUgdXNlZCBmb3IgbXVsdGljYXN0 IHVzZSBjYXNlcy4gSXQgPC90dD48YnI+DQo8dHQ+Jmd0OyB3b3VsZCBiZSBncmVhdCBpZiB0aGF0 IGNvdWxkIGJlIGRvbmUgd2l0aG91dCBuZWVkaW5nIGZ1cnRoZXIgPC90dD48YnI+DQo8dHQ+Jmd0 OyBtb2RpZmljYXRpb25zIHRvIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiE8L3R0 Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZu YnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZndDsgcmVnYXJkczwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsgRXNrbzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBGcm9tOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEg Wzwvc3Bhbj48L3R0PjxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5tYWlsdG86YWJoaWphbi5iaGF0 dGFjaGFyeXlhQHRjcy5jb208L3NwYW4+PC90dD48L2E+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5dDQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgU2VudDog TW9uZGF5LCBNYXkgMDIsIDIwMTYgNToxOTwvdHQ+PGJyPg0KPHR0PiZndDsgVG86IERpamssIEVz a28gJmx0OzxhIGhyZWY9Im1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20iPmVza28uZGlqa0Bw aGlsaXBzLmNvbTwvYT4mZ3Q7PC90dD48YnI+DQo8dHQ+Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRv OmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+IFdHICZsdDs8YSBocmVmPSJtYWlsdG86 Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7OyBOZXZpbCBCcm93bmxlZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmciPnJmYy1pc2VAcmZjLWVkaXRv ci5vcmc8L2E+Jmd0OzwvdHQ+PGJyPg0KPHR0PiZndDsgU3ViamVjdDogUkU6IFVzaW5nIGRyYWZ0 LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiByZXNwb25zZXM8L3R0Pjxi cj4NCjx0dD4mZ3Q7IEltcG9ydGFuY2U6IEhpZ2g8L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgSGkgRXNrbywgPC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IFRoZSBleGlzdGluZyB2ZXJzaW9uIC0xNiBoYXMg dGhlIGZvbGxvd2luZyB0ZXh0IGluIHNlY3Rpb24gMi4xIChwYWdlIDUpIDogPC90dD4NCjxicj4N Cjx0dD4mZ3Q7ICZxdW90O1RoZSBzZXJ2ZXIgTVVTVCBzZW5kIGJhY2sgcmVzcG9uc2VzIG9mIHRo ZSBjbGFzc2VzIGZvciB3aGljaCB0aGUgPC90dD48YnI+DQo8dHQ+Jmd0OyBjbGllbnQgaGFzIG5v dCBleHByZXNzZWQgYW55IGRpcy1pbnRlcmVzdC4mcXVvdDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBT bywgdGhhdCB3YXkgdGhlIGNsaWVudCBoYXMgYWN0dWFsbHkgZXhwcmVzc2VkIGl0cyBpbnRlcmVz dCAob3IgPC90dD48YnI+DQo8dHQ+Jmd0OyByZXF1ZXN0IGZvciBlbmFibGVtZW50KSBpbiBhbGwg dGhlIHJlc3BvbnNlcyBmb3Igd2hpY2ggaXQgaGFzIG5vdCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IGV4 cHJlc3NlZCBleHBsaWNpdCBkaXNpbnRlcmVzdC4gRG9lcyB0aGF0IGhlbHAgdG8gY29udHJvbCB0 aGUgPC90dD48YnI+DQo8dHQ+Jmd0OyBzcGVjaWFsIHNlcnZlci1zaWRlIGJlaGF2aW91ciBhcyB0 aGUgc2VydmVyIGtub3dzIHdoaWNoIGFsbCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHJlc3BvbnNlcyB0 aGUgY2xpZW50IGlzIGludGVyZXN0ZWQgaW4gYW5kIGl0IE1VU1Qgc2VuZCBhIHJlc3BvbnNlIDwv dHQ+PGJyPg0KPHR0PiZndDsgYmFjayA/IEkgc2hhbGwgc3VibWl0IGFub3RoZXIgdmVyc2lvbiB3 aXRoIHNvbWUgZWRpdG9yaWFsIGNoYW5nZXMgPC90dD48YnI+DQo8dHQ+Jmd0OyBiZWZvcmUgdGhl IGRyYWZ0IGdvZXMgdG8gSUVTRy4gU28gd2UgaGF2ZSBzb21lIG1vcmUgcm9vbSBmb3IgPC90dD48 YnI+DQo8dHQ+Jmd0OyBtb2RpZmljYXRpb24uIElmIHlvdSBoYXZlIHNvbWUgY29tbWVudHMgb24g dGhpcyBpbiB0aGUgbGluZSBvZiB0aGUgPC90dD48YnI+DQo8dHQ+Jmd0OyBkaXNjdXNzaW9uIHdl IGFyZSBoYXZpbmcsIHBsZWFzZSBsZXQgdXMga25vdy4gSSBzaGFsbCB3YWl0IGZvciB5b3VyIDwv dHQ+PGJyPg0KPHR0PiZndDsgdmlld3MgYmVmb3JlIHN1Ym1pdHRpbmcgdGhlIHVwZGF0ZWQgdmVy c2lvbi4gPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IEFueXdheSwgYSBz ZXBhcmF0ZSBkcmFmdCAob3IsIHBvc3NpYmx5LCBhbiB1cGRhdGVkIGdyb3VwY29tbSBSRkM/KSA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IGlzIGEgZ29vZCBpZGVhLiBOby1SZXNwb25zZSBhc3N1bWVzIHRo ZSB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIDwvdHQ+PGJyPg0KPHR0PiZndDsgc3ltYW50aWNzIGFu ZCBpdCBtYWlubHkgYWRkcmVzc2VzIHRoZSBjbGllbnQgc2lkZSBiZWhhdmlvdXIgYW5kIDwvdHQ+ PGJyPg0KPHR0PiZndDsgaXNzdWVzLiBDb25zaWRlcmluZyBzdWNoIHNwZWNpYWwgYmVoYXZpb3Vy IG9mIGdyb3VwY29tbSBzZXJ2ZXJzLCBpdCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHdvdWxkIGJlIGdv b2QgdG8gaGFuZGxlIHNlcGFyYXRlbHkuIDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8 dHQ+Jmd0OyBXYWl0aW5nIHRvIGhlYXIgZnJvbSB5b3UuIDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90 dD48YnI+DQo8dHQ+Jmd0OyBSZWdhcmRzPC90dD48YnI+DQo8dHQ+Jmd0OyBBYmhpamFuIEJoYXR0 YWNoYXJ5eWE8L3R0Pjxicj4NCjx0dD4mZ3Q7IEFzc29jaWF0ZSBDb25zdWx0YW50PC90dD48YnI+ DQo8dHQ+Jmd0OyBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTwvdHQ+ PGJyPg0KPHR0PiZndDsgVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczwvdHQ+PGJyPg0KPHR0PiZn dDsgTWFpbHRvOiA8YSBocmVmPSJtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20i PmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPC9hPjwvdHQ+PGJyPg0KPHR0PiZndDsgV2Vi c2l0ZTogPC90dD48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy50Y3MuY29tLyI+PHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwOi8vd3d3LnRjcy5jb208L3NwYW4+PC90dD48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC90dD48YnI+DQo8dHQ+Jmd0OyBFeHBlcmllbmNlIGNlcnRhaW50eS4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8L3R0Pjxicj4NCjx0dD4mZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QnVzaW5lc3MgU29sdXRpb25zPC90dD48YnI+DQo8 dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8L3R0Pjxicj4NCjx0 dD4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC90dD48 YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJnF1 b3Q7RGlqaywgRXNrbyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVza28uZGlqa0BwaGlsaXBz LmNvbSI+ZXNrby5kaWprQHBoaWxpcHMuY29tPC9hPiZndDsgd3JvdGUgb24gMDUvMDIvMjAxNiAw MzoxMDoyNCBBTTo8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBG cm9tOiAmcXVvdDtEaWprLCBFc2tvJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZXNrby5kaWpr QHBoaWxpcHMuY29tIj5lc2tvLmRpamtAcGhpbGlwcy5jb208L2E+Jmd0Ow0KPC90dD48YnI+DQo8 dHQ+Jmd0OyAmZ3Q7IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgJmx0OzxhIGhyZWY9Im1haWx0 bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRj cy5jb208L2E+Jmd0Ow0KPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IENjOiAmcXVvdDs8YSBocmVm PSJtYWlsdG86Y29yZUBpZXRmLm9yZyUyMFdHIj5jb3JlQGlldGYub3JnIFdHPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0Oywg TmV2aWwgQnJvd25sZWUgJmx0O3JmYy1pc2VAcmZjLTwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBl ZGl0b3Iub3JnJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgRGF0ZTogMDUvMDIvMjAxNiAw MzoxMCBBTSA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgU3ViamVjdDogUkU6IFVzaW5nIGRyYWZ0 LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiByZXNwb25zZXMNCjwvdHQ+ PGJyPg0KPHR0PiZndDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgSGVsbG8gQWJoaWph biwgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7ICZuYnNwOyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZn dDsgJmd0OyBNYW5kYXRpbmcgc3VjaCBzZXJ2ZXIgYmVoYXZpb3VyIGZyb20gdGhlIGNsaWVudCBz aWRlIHdpbGwgYmUgYSBiaXQ8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgb3V0LW9mLXN5bmMgd2l0 aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLiA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZn dDsgVGhpcyBpcyBub3QgZnVsbHkgY2xlYXIgdG8gbWUgeWV0IOKApiB0aGUgY2xpZW50IGRvZXMg bm90IG1hbmRhdGUgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IGFueXRoaW5nIGZyb20gdGhlIHNl cnZlcjsgaXQganVzdCBleHByZXNzZXMgaXRzIGludGVyZXN0ICgwLWJpdHMpIDwvdHQ+PGJyPg0K PHR0PiZndDsgJmd0OyBhbmQgZGlzaW50ZXJlc3QgKDEtYml0cykuIFRoZSBzZXJ2ZXIgY2FuIGFs d2F5cyBub3QgcGFyc2UgdGhlIG9wdGlvbjwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyAoZWxlY3Rp dmUpIG9yIGNob29zZSBub3QgdG8gYm90aGVyIGFib3V0IGl0LiA8L3R0Pjxicj4NCjx0dD4mZ3Q7 ICZndDsgVGhpcyBkb2VzIGtlZXAgdGhlIGNsaWVudCB3YWl0aW5nIGZvciBhIHBvc3NpYmxlIHJl c3BvbnNlIHRoYXQgbmV2ZXI8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgY29tZXM7IGJ1dCB0aGF0 IGlzIHRoZSBzYW1lIGluIHRoZSBnZW5lcmFsIG11bHRpY2FzdCBjYXNlIDogdGhlIDwvdHQ+PGJy Pg0KPHR0PiZndDsgJmd0OyBjbGllbnQgY2FuIG5ldmVyIGtub3cgaWYgb3Igd2hlbiBhIHJlc3Bv bnNlIHdpbGwgY29tZSwgdGhlIHNlcnZlciA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgTUFZIGFs d2F5cyBjaG9vc2UgdG8gbm90IHJlc3BvbmQuIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyAmbmJz cDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IFNvIHdoYXQgSSBwcm9wb3NlIGlzIHRvIHVzZSB0 aGUgJnF1b3Q7aW5kaWNhdGlvbiBvZiBpbnRlcmVzdCZxdW90OyB0byBzcGVjaWZpYzwvdHQ+PGJy Pg0KPHR0PiZndDsgJmd0OyByZXNwb25zZSBjbGFzc2VzIGluIGEgbmV3IHdheTsgbmFtZWx5IHRv IGVuYWJsZSBjZXJ0YWluIHJlc3BvbnNlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBjbGFzc2Vz IHRoYXQgYXJlIHN1cHByZXNzZWQgYnkgZGVmYXVsdC4gJm5ic3A7SXQganVzdCBoYXBwZW5zIHRo YXQgdGhlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBzYW1lIE9wdGlvbiBzeW50YXggaXMgdmVy eSB3ZWxsIHN1aXRlZCBmb3IgdGhhdCBwdXJwb3NlLiBBIHNlcGFyYXRlIDwvdHQ+DQo8YnI+DQo8 dHQ+Jmd0OyAmZ3Q7IGRyYWZ0IGNvdWxkIGJlIHdyaXR0ZW4gZm9yIHRoYXQgcGVyaGFwcyBpZiB5 b3UgdGhpbmsgaXQgZG9lcyBub3QgZml0PC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IGluIGRyYWZ0 LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiBvciBpZiBpdCBpcyB0b28gbGF0ZSBmb3IgdGhh dC4gPC90dD4NCjxicj4NCjx0dD4mZ3Q7ICZndDsgVGhlIHdlIGNhbiBwb2ludCB0byB0aGUgc3lu dGF4IG9mIHRoZSBOby1SZXNwb25zZSBPcHRpb24gYW5kIHJlLXVzZSA8L3R0Pg0KPGJyPg0KPHR0 PiZndDsgJmd0OyBpdCBjb21wbGV0ZWx5LiA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgJm5ic3A7 IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyByZWdhcmRzIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0 OyBFc2tvIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyAmbmJzcDsgPC90dD48YnI+DQo8dHQ+Jmd0 OyAmZ3Q7IEZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbPC90dD48L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tIj48dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPm1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvc3Bh bj48L3R0PjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl0NCjwvc3Bhbj48 L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IFNlbnQ6IEZyaWRheSwgQXByaWwgMjIs IDIwMTYgMTc6MTc8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgVG86IERpamssIEVza28gJmx0Ozxh IGhyZWY9Im1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20iPmVza28uZGlqa0BwaGlsaXBzLmNv bTwvYT4mZ3Q7PC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86Y29y ZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4gV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3Jl QGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZndDs7IE5ldmlsIEJyb3dubGVlICZsdDs8YSBo cmVmPSJtYWlsdG86cmZjLWlzZUByZmMtZWRpdG9yLm9yZyUwYiI+cmZjLWlzZUByZmMtZWRpdG9y Lm9yZzxicj4NCjwvYT4mZ3Q7ICZndDs8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgU3ViamVjdDog UmU6IFVzaW5nIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiBy ZXNwb25zZXMNCjwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyAmbmJzcDsgPC90dD48YnI+DQo8dHQ+ Jmd0OyAmZ3Q7IEhpIEVza28sIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBUaGFua3MgZm9yIHlv dXIgbWFpbC4gPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IEZpcnN0IG9mIGFsbCBsZXQgbWUganVz dCBicmluZyB0aGlzIHRvIHlvdXIgKGFzIHdlbGwgYXMgdGhlIG1haWxpbmcgPC90dD4NCjxicj4N Cjx0dD4mZ3Q7ICZndDsgbGlzdCdzKSBub3RpY2UgdGhhdCB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg dGhlIGRyYWZ0IGlzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwv dHQ+PGJyPg0KPHR0PiZndDsgJmd0OyA8L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2UtIj48dHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS08L3NwYW4+PC90dD48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxicj4NCjx0dD4mZ3Q7IG9wdGlvbi0xNi50eHQ8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZn dDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IFRoaXMgdmVyc2lvbiAmcXVvdDtvZmZpY2lhbGx5 JnF1b3Q7IGNsb3NlcyB0aGUgdGVjaG5pY2FsIHJldmlld3MgYW5kIGlzIHdpdGggPC90dD48YnI+ DQo8dHQ+Jmd0OyAmZ3Q7IHRoZSBSRkMgZWRpdG9yIHRocm91Z2ggdGhlIElTIHRyYWNrLiA8L3R0 Pjxicj4NCjx0dD4mZ3Q7ICZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IE5vdyBjb21pbmcg dG8geW91ciB1c2UgY2FzZSAoYW5kIGluZGVlZCBpdCBpcyBhbiBpbnRlcmVzdGluZyBvbmUpIDwv dHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBvbmUgdGhpbmcgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIg aXMgdGhhdCB0aGUgTm8tUmVzcG9uc2Ugb3B0aW9uIHdhczwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0 OyBkZWxpYmVyYXRlbHkgZGVzaWduZWQgbm90IHRvIG1hbmRhdGUgYW55dGhpbmcgZm9yIHRoZSBz ZXJ2ZXIgc2lkZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgbWFpbmx5IHRvIGVuc3VyZSB0aGF0 IGl0IGRvZXMgbm90IGRpc3J1cHQgdGhlIG1hbnkgdXNlZnVsbmVzcyBvZiB0aGU8L3R0Pjxicj4N Cjx0dD4mZ3Q7ICZndDsgdXN1YWwgcmVxdWVzdC9yZXNwb25zZSBzeW1hbnRpY3MuIFRoZSBkcmFm dCBhbGwgYWxvbmcgZGVhbHMgd2l0aCB0aGU8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgcmVxdWVz dGluZyBjbGllbnQncyBiZWhhdmlvdXIgYW5kIGl0cyBleHByZXNzaW9uIG9mIGludGVyZXN0IHRv IHRoZSA8L3R0Pg0KPGJyPg0KPHR0PiZndDsgJmd0OyBzZXJ2ZXIuIFNpbmNlIHRoaXMgb3B0aW9u IGlzIGVsZWN0aXZlIHdlIGxlYXZlIGl0IHVwdG8gdGhlIHNlcnZlciA8L3R0Pjxicj4NCjx0dD4m Z3Q7ICZndDsgaW1wbGVtZW50YXRpb24gdG8gaG9ub3VyIHRoZSBjbGllbnQncyBpbnRlcmVzdC4g PC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBOb3csIGFz IHBlciB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIHN5bWFudGljcyB0aGUgcmVzcG9uc2VzIGFyZSA8 L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgYWx3YXlzIGVuYWJsZWQuIFRoZSBiZWhhdmlvdXIgaW4g Z3JvdXBjb21tIHNlcnZlciBpbiB0ZXJtcyBvZiA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgc3Vw cHJlc3NpbmcgdGhlIHJlc3BvbnNlcyBvbiBpdHMgb3duIGlzIHNvbWV0aGluZyBzcGVjaWFsIGFu ZCwgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IGdlbmVyYWxseSBzcGVha2luZywgdGhlIGNsaWVu dHMgYXJlIG5vdCBhd2FyZSBvZiBzdWNoIHNwZWNpYWwgYmVoYXZpb3VyLiAmbmJzcDsNCjwvdHQ+ PGJyPg0KPHR0PiZndDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgU28sIGl0IHdvdWxk IGJlIGp1c3RpZmllZCB0byBoYW5kbGUgdGhlIHNpdHVhdGlvbiBhdCB0aGUgc2VydmVyJ3MgPC90 dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IGVuZC4gSGVyZSBpcyB0aGUgaWRlYTogPC90dD48YnI+DQo8 dHQ+Jmd0OyAmZ3Q7IFdoaWxlIE5vLVJlc3BvbnNlIGlzIHRvIGV4cHJlc3NlcyBjbGllbnQncyBk aXMtaW50ZXJlc3QgaW4gc29tZSBvciA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgYWxsIG9mIHRo ZSByZXNwb25zZXMgZGVwZW5kaW5nIG9uIHRoZSBvcHRpb24gdmFsdWUsIGl0IGlzIGFsc28gdHJ1 ZSA8L3R0Pg0KPGJyPg0KPHR0PiZndDsgJmd0OyB0aGF0IHRoZSBvcHRpb24gYXV0b21hdGljYWxs eSBleHByZXNzZXMgaW50ZXJlc3QgaW4gYWxsIG90aGVyIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0 OyByZXNwb25zZXMgKG1hcmtlZCBieSAwJ3MgaW4gdGhlIHJlc3BlY3RpdmUgcG9zaXRpb25zKS4g VGhlIGNsaWVudCBpczwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBnb2luZyB0byB3YWl0IGZvciB0 aGVzZSByZXNwb25zZXMgdXB0byBhIGdpdmVuIHRpbWVvdXQuIE5vdywgaWYgdGhlIDwvdHQ+DQo8 YnI+DQo8dHQ+Jmd0OyAmZ3Q7IHNlcnZlciBiZWhhdmlvdXIgaXMgbW9kaWZpZWQgbGlrZSB0aGlz IDogJnF1b3Q7SSBoYXZlIGNsb3NlZCBteSBkb29yIGZvciA8L3R0Pg0KPGJyPg0KPHR0PiZndDsg Jmd0OyBhbGwgb3V0IGdvaW5nIHJlc3BvbnNlLiAqKkJVVCoqLCBpZiBJIHNlZSBhIGZlbGxvdyBy ZXF1ZXN0aW5nIHdpdGggPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IE5vLVJlc3BvbnNlIGFuZCBr ZWVwaW5nIHdpbmRvd3Mgb3BlbiB0byBzb21lIHJlc3BvbnNlcyB0aGVuIEkgYXNzdW1lPC90dD48 YnI+DQo8dHQ+Jmd0OyAmZ3Q7IHRoYXQgdGhpcyBndXkgcmVhbGx5IG5lZWRzIHRob3NlIGtpbmQg b2YgcmVzcG9uc2VzLiBJbiB0aGF0IGNhc2UgbGV0PC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IG1l IGJlIGxpbmllbnQgYW5kIGxldCBtZSBvcGVuIHRoZSBkb29yIGZvciBzdWNoIHJlc3BvbnNlcy4g VGhpcyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgZmVsbG93IG11c3QgYmUgYXZhaWxhYmxlIHRv IGxpc3RlbiB0byB0aGVtIGFzIHBlciB0aGUgcHJlc2NyaWJlZCA8L3R0Pjxicj4NCjx0dD4mZ3Q7 ICZndDsgYmVoYXZpb3VyIGluIHRoZSBOby1SZXNwb25zZSBzcGVjaWZpY2F0aW9uLiZxdW90OyAm bmJzcDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBN YW5kYXRpbmcgc3VjaCBzZXJ2ZXIgYmVoYXZpb3VyIGZyb20gdGhlIGNsaWVudCBzaWRlIHdpbGwg YmUgYSBiaXQgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IG91dC1vZi1zeW5jIHdpdGggdGhlIHNw aXJpdCBvZiB0aGUgc3BlY2lmaWNhdGlvbi4gPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IDwvdHQ+ PGJyPg0KPHR0PiZndDsgJmd0OyBSZWdhcmRzPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IEFiaGlq YW4gQmhhdHRhY2hhcnl5YTwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBBc3NvY2lhdGUgQ29uc3Vs dGFudDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBL b2xrYXRhLCBJbmRpYTwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBUYXRhIENvbnN1bHRhbmN5IFNl cnZpY2VzPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IE1haWx0bzogPGEgaHJlZj0ibWFpbHRvOmFi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tIj5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bTwvYT48L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgV2Vic2l0ZTogPC90dD48L3NwYW4+PGEgaHJl Zj0iaHR0cDovL3d3dy50Y3MuY29tLyI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5odHRwOi8vd3d3LnRjcy5jb208L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4m Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0 Pjxicj4NCjx0dD4mZ3Q7ICZndDsgRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7QnVzaW5lc3MgU29sdXRpb25zPC90dD48YnI+DQo8dHQ+Jmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q29uc3VsdGluZzwvdHQ+PGJyPg0KPHR0PiZn dDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvdHQ+ PGJyPg0KPHR0PiZndDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgPC90dD48YnI+DQo8 dHQ+Jmd0OyAmZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7 ICZndDsgRnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7RGlqaywgRXNrbyZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbSI+ZXNrby5kaWpr QHBoaWxpcHMuY29tPC9hPiZndDsNCjwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBUbzogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWJoaWphbiBCaGF0dGFjaGFyeXlhICZsdDs8YSBocmVmPSJt YWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20iPmFiaGlqYW4uYmhhdHRhY2hhcnl5 YUB0Y3MuY29tPC9hPiZndDsNCjwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBDYzogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7TmV2aWwgQnJvd25sZWUgJmx0OzxhIGhyZWY9Im1haWx0bzpyZmMt aXNlQHJmYy1lZGl0b3Iub3JnIj5yZmMtaXNlQHJmYy1lZGl0b3Iub3JnPC9hPiZndDssICZxdW90 OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnJTIwV0ciPmNvcmVAaWV0Zi5vcmcgV0c8L2E+ JnF1b3Q7ICZsdDs8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOmNvcmVA aWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsg RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDQvMjIvMjAxNiAwNTo0MyBQTSA8L3R0 Pjxicj4NCjx0dD4mZ3Q7ICZndDsgU3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 VXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvIDwvdHQ+PGJyPg0KPHR0 PiZndDsgKmVuYWJsZSogcmVzcG9uc2VzIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyA8L3R0Pjxi cj4NCjx0dD4mZ3Q7ICZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IDwvdHQ+PGJyPg0KPHR0 PiZndDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgSGVsbG8gQWJoaWphbiw8L3R0Pjxi cj4NCjx0dD4mZ3Q7ICZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IGluIG91ciBwcm9qZWN0 IHdlIHNlZSBhIGNsZWFyIHVzZSBjYXNlIG9mIHVzaW5nIHRoZSBOby1SZXNwb25zZSA8L3R0Pjxi cj4NCjx0dD4mZ3Q7ICZndDsgT3B0aW9uIHRvICplbmFibGUqIGNlcnRhaW4gcmVzcG9uc2VzIHRo YXQgYXJlIGJ5IGRlZmF1bHQgc3VwcHJlc3NlZC48L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgQ29B UCBhbGxvd3Mgc3VwcHJlc3Npb24gb2YgbXVsdGljYXN0IHJlc3BvbnNlcyBieSBkZWZhdWx0LCB3 aGljaCBpcyA8L3R0Pg0KPGJyPg0KPHR0PiZndDsgJmd0OyB3aGF0IHdlIHVzZSBmb3IgYSBsaWdo dGluZyBtdWx0aWNhc3QgdXNlIGNhc2UuIEhvd2V2ZXIgZm9yIDwvdHQ+PGJyPg0KPHR0PiZndDsg Jmd0OyBkaWFnbm9zdGljIHVzYWdlIHdlJ2QgbGlrZSB0byBlbmFibGUgdGhlc2UgcmVzcG9uc2Vz IGFnYWluIHVzaW5nIHRoZTwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBOby1SZXNwb25zZSBvcHRp b24gd2hpY2ggaXMgcGVyZmVjdGx5IHN1aXRlZCBmb3IgdGhhdC4gSG93ZXZlciwgdGhlIDwvdHQ+ DQo8YnI+DQo8dHQ+Jmd0OyAmZ3Q7IGRyYWZ0IHRleHQgY3VycmVudGx5IG9ubHkgdGFsa3MgYWJv dXQgc3VwcHJlc3NpbmcgcmVzcG9uc2VzIChub3QgZW5hYmxpbmcpLjwvdHQ+PGJyPg0KPHR0PiZn dDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgSGVuY2UgbXkgcmVxdWVzdDogY291bGQg d2UgbW9kaWZ5L2FkZCBzb21lIHRleHQgdG8gc2hvdyB0aGF0IGFsc28gPC90dD48YnI+DQo8dHQ+ Jmd0OyAmZ3Q7IHRoZSBvcHRpb24gY2FuIGJlIHVzZWQgdG8gZW5hYmxlIHJlc3BvbnNlcyBpbiBj YXNlIHdoZXJlIHRoZXkgYXJlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBub3JtYWxseSAoYnkg ZGVmYXVsdCAtLSBzZXJ2ZXIgZGVjaXNpb24pIHN1cHByZXNzZWQ/PC90dD48YnI+DQo8dHQ+Jmd0 OyAmZ3Q7IEp1c3QgdG8gY2xhcmlmeSBzdWNoIHVzYWdlOyB3aGljaCBpcyBxdWl0ZSB1c2VmdWwg aW4gbXkgdmlldy48L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAm Z3Q7IHJlZ2FyZHM8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgRXNrbzwvdHQ+PGJyPg0KPHR0PiZn dDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgPC90dD48YnI+DQo8dHQ+ Jmd0OyAmZ3Q7IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVz c2FnZSBpcyBpbnRlbmRlZCA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgc29sZWx5IGZvciB0aGUg YWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCA8L3R0 Pg0KPGJyPg0KPHR0PiZndDsgJmd0OyB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1 c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIDwvdHQ+DQo8YnI+DQo8dHQ+Jmd0OyAm Z3Q7IHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh bmQgbWF5IGJlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyB1bmxhd2Z1bC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIDwvdHQ+DQo8YnI+ DQo8dHQ+Jmd0OyAmZ3Q7IHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuIDwvdHQ+DQo8YnI+DQo8dHQ+Jmd0OyAmZ3Q7 ID09PT09LS0tLS09PT09PS0tLS0tPT09PT08L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsPC90dD48YnI+DQo8dHQ+ Jmd0OyAmZ3Q7IG1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIDwv dHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbi4gSWYgeW91IGFyZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIDwvdHQ+PGJyPg0KPHR0PiZndDsg Jmd0OyByZXZpZXcsIGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPC90 dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFp bCBtZXNzYWdlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBhbmQvb3IgYXR0YWNobWVudHMgdG8g aXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDwvdHQ+PGJyPg0K PHR0PiZndDsgJmd0OyBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhv bmUgYW5kIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoZSBtZXNzYWdlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBhbmQgYW55IGF0 dGFjaG1lbnRzLiBUaGFuayB5b3UgPC90dD48L3NwYW4+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0 OyBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlk ZW50aWFsIGFuZCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFw cGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCA8L3R0Pjxicj4NCjx0dD4mZ3Q7 IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgPC90dD48YnI+DQo8dHQ+Jmd0OyB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0 aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIDwvdHQ+PGJyPg0KPHR0 PiZndDsgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgPC90dD48YnI+DQo8dHQ+Jmd0OyB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIDwvdHQ+PGJyPg0KPHR0 PiZndDsgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0 aGUgb3JpZ2luYWwgbWVzc2FnZS48L3R0Pjwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRp YWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkDQogdGhhdCBh bnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhp cyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdp bmFsIG1lc3NhZ2UuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_fb9c8baf329b4cc6a4c890d84b0236dfHE1PR9001MB0170MGDPHGem_-- From nobody Tue May 3 20:19:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BADD12D7A6 for ; Tue, 3 May 2016 20:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6drE9J9LcEz for ; Tue, 3 May 2016 20:18:59 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C38A12D678 for ; Tue, 3 May 2016 20:18:59 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 2353319F409 for ; Wed, 4 May 2016 11:18:57 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id F405919F426; Wed, 4 May 2016 11:18:55 +0800 (HKT) Message-ID: From: "weigengyu" To: , , References: <065.865b9837ab99aed6c309ae6125f98820@trac.tools.ietf.org> In-Reply-To: <065.865b9837ab99aed6c309ae6125f98820@trac.tools.ietf.org> Date: Wed, 4 May 2016 11:18:54 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP Connections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 03:19:02 -0000 Hi, The problem seems to be whether CoAP over Multiple Simultaneous TCP Connections needs considering in CoAP related drafts. My suggestion is no. There are many P2P communications adopts P2P/HTTP over Multiple Simultaneous TCP Connections. It is the P2P software to manage the multiple TCP connections, not HTTP. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: core issue tracker Sent: Tuesday, May 03, 2016 4:39 PM To: draft-ietf-core-block@tools.ietf.org ; Hannes.Tschofenig@gmx.net Cc: core@ietf.org Subject: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP Connections #409: CoAP over TCP: Multiple Simultaneous TCP Connections CoAP has been designed to support small data transmissions. For device management it is, however, necessary to also deal with the transmission of larger payloads as well. Such larger payloads may be, for example, firmware/software updates. The maximum payload size of CoAP is determined by the length field of the length field provided in the UDP header. It is ~64KB. For practical purposes the usable payload size is, however, much smaller due to performance issues introduced by fragmentation provided at the IP layer and/or adaption layers. For this reason the block-wise transfer mechanism has been defined. Block-wise transfer is a mechanism that can be used to transfer larger payloads by chunking them into smaller parts (each part with a maximum size of 1024 bytes each). The block-wise transfer depends on CoAP and therefore uses the stop-and-wait defined in RFC 7252 (as a simple congestion control mechanism). The transfer of large payloads does, however, not block the transmission of other pending messages since they can easily be interleaved due to the nature of the block-wise transfer design. When large payloads are transferred by CoAP over TCP then a large transfer blocks any other requests unless multiple TCP connections are opened. The question is therefore what should the CoAP over TCP state regarding the use of multiple TCP connections? Using multiple TCP connection increases RAM requirements; a single TCP connection introduces head-of-line blocking. When CoAP over TCP is used with Block-wise transport in combination with BERT, see https://tools.ietf.org/html/draft-bormann-core-block-bert-00, then the previously described problem of large transfers that block other ongoing activities is (partially) mitigated. BERT changes the interpretation of the length information and changes it as a multiple of 1024 bytes (and thus increasing the size of the chunks). The question is therefore whether CoAP over TCP should recommend the use of Block-wise Transfer for large file transfers and incorporate BERT into the CoAP over TCP draft. (I would like to thank Achim Kraus for raising this issue during the OMA face-to-face meeting.) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core- Hannes.Tschofenig@gmx.net | block@tools.ietf.org Type: protocol defect | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue May 3 21:43:44 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DD612B023 for ; Tue, 3 May 2016 21:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, URIBL_BLACK=1.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTrGOlQtoHol for ; Tue, 3 May 2016 21:43:39 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE5912D1B1 for ; Tue, 3 May 2016 21:43:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQAieilX/wQXEqxegmyBH326JAENgXEEFwEKhW4CHIFWFAEBAQEBAQGBDIRBAQEBAwEaCUsLBQsLBwYEAwEBASEBBgMCAgJECQgGCwgbiAcWqlgBAQFlkQYBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhHdnhQ+EIgEBBSILCAEHBQqCEjgTGIIuBY5LhFmEcoFVhCeFY4QhFzeDf4hehiSJDh4BAYQ1ZIZ+BwKBNQEBAQ X-IPAS-Result: A2DQAQAieilX/wQXEqxegmyBH326JAENgXEEFwEKhW4CHIFWFAEBAQEBAQGBDIRBAQEBAwEaCUsLBQsLBwYEAwEBASEBBgMCAgJECQgGCwgbiAcWqlgBAQFlkQYBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhHdnhQ+EIgEBBSILCAEHBQqCEjgTGIIuBY5LhFmEcoFVhCeFY4QhFzeDf4hehiSJDh4BAYQ1ZIZ+BwKBNQEBAQ X-IronPort-AV: E=Sophos;i="5.24,574,1454956200"; d="scan'208";a="80412276" X-DISCLAIMER: FALSE In-Reply-To: References: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com> To: "Dijk, Esko" MIME-Version: 1.0 X-KeepSent: 7EC4E3E5:FD5964C7-65257FA9:0019D8D4; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 4 May 2016 10:13:27 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF956 | April 21, 2016) at 05/04/2016 10:13:28, Serialize complete at 05/04/2016 10:13:28 Content-Type: multipart/alternative; boundary="=_alternative 0019F30665257FA9_=" Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 04:43:43 -0000 This is a multipart message in MIME format. --=_alternative 0019F30665257FA9_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRXNrbywNClRoYW5rcy4gSSBzaGFsbCB1cGRhdGUgdGhlIG5leHQgdmVyc2lvbiBhY2NvcmRp bmdseS4gSSBhbSBoYXBweSB0aGF0IHdlIA0KY291bGQgc2F0aXNmeSB5b3VyIHVzZSBjYXNlIGZp bmFsbHkuIA0KDQpSZWdhcmRzDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWENCkFzc29jaWF0ZSBDb25z dWx0YW50DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0KVGF0YSBD b25zdWx0YW5jeSBTZXJ2aWNlcw0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bQ0KV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgSVQgU2VydmljZXMN CiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAgICAgICAg ICAgICAgICAgICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQoNCg0KRnJvbTogICAiRGlqaywgRXNrbyIgPGVza28uZGlqa0BwaGls aXBzLmNvbT4NClRvOiAgICAgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxhYmhpamFuLmJoYXR0YWNo YXJ5eWFAdGNzLmNvbT4NCkNjOiAgICAgImNvcmVAaWV0Zi5vcmcgV0ciIDxjb3JlQGlldGYub3Jn PiwgTmV2aWwgQnJvd25sZWUgDQo8cmZjLWlzZUByZmMtZWRpdG9yLm9yZz4NCkRhdGU6ICAgMDUv MDQvMjAxNiAwMjo0NCBBTQ0KU3ViamVjdDogICAgICAgIFJFOiBVc2luZyBkcmFmdC10Y3MtY29h cC1uby1yZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSogDQpyZXNwb25zZXMNCg0KDQoNCkhlbGxv IEFiaGlqYW4sDQogDQpBZ3JlZWQ7IGJlbG93IGEgcHJvcG9zZWQgdXBkYXRlZCB0ZXh0IHRoYXQg c2VwYXJhdGVzIHRoZSBleGFtcGxlIGZyb20gdGhlIA0Kc3BlY2lmaWNhdGlvbiBwYXJ0LiBUaGUg bnVtYmVyIG9mIE1VU1RzIGlzIGFsc28gcmVkdWNlZCB0byB0d28uIChNaWdodCBiZSANCmV2ZW4g cmVkdWNlZCB0byBvbmUg4oCTIG9ubHkgdGhlIGZpcnN0LCBidXQgbGVhdmluZyB0aGF0IHRvIHRo ZSBlZGl0aW5nIA0KcHJvY2Vzc+KApiBJIHRoaW5rIGFuIGV4YW1wbGUgdHlwaWNhbGx5IGRvZXMg bm90IGhhdmUgYSBNVVNUKQ0KIA0KLS0tDQpUaGUgc2VydmVyIE1VU1Qgc2VuZCBiYWNrIHJlc3Bv bnNlcyBvZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2ggdGhlIGNsaWVudCANCmhhcyBub3QgZXhwcmVz c2VkIGFueSBkaXNpbnRlcmVzdC4gVGhlcmUgYXJlIGluc3RhbmNlcyB3aGVyZSBhIHNlcnZlciwg b24gDQppdHMgb3duLCBkZWNpZGVzIHRvIHN1cHByZXNzIHJlc3BvbnNlcyBsaWtlIHRoZSBtdWx0 aWNhc3Qgc2VydmVycyANCmRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuNyBvZiAgW1JGQzczOTBdLiBJ ZiBzdWNoIGEgc2VydmVyIHJlY2VpdmVzIGEgDQpyZXF1ZXN0IHdpdGggYSBOby1SZXNwb25zZSBP cHRpb24gc2hvd2luZyBpbnRlcmVzdCBpbiBzcGVjaWZpYyByZXNwb25zZSANCmNsYXNzZXMsIHRo ZW4gYW55IGRlZmF1bHQgYmVoYXZpb3VyIG9mIHN1cHByZXNzaW5nIHJlc3BvbnNlcyDigJMgaWYg cHJlc2VudCANCuKAkyBNVVNUIGJlIG92ZXJyaWRkZW4gdG8gZGVsaXZlciB0aG9zZSByZXNwb25z ZXMgd2hpY2ggYXJlIG9mIGludGVyZXN0IHRvIA0KdGhlIGNsaWVudC4gDQogDQpTbywgZm9yIGV4 YW1wbGUsIGlmIGEgbXVsdGljYXN0IHNlcnZlciBzdXBwcmVzc2VzIGFsbCByZXNwb25zZXMgYnkg ZGVmYXVsdCANCmFuZCByZWNlaXZlcyBhIHJlcXVlc3Qgd2l0aCBhIE5vLVJlc3BvbnNlIE9wdGlv biBleHByZXNzaW5nIGRpc2ludGVyZXN0IGluIA0KMi54eCBzdWNjZXNzIHJlc3BvbnNlcywgYW5k IGludGVyZXN0IGluIGVycm9yIHJlc3BvbnNlcyA0Lnh4LzUueHgsIHRoZW4gDQp0aGUgc2VydmVy IG11c3Qgc2VuZCBiYWNrIGEgcmVzcG9uc2UgaWYgdGhlIGNvbmNlcm5lZCByZXF1ZXN0IGNhdXNl ZCBhbiANCmVycm9yLg0KLS0tDQogDQpyZWdhcmRzLA0KRXNrbw0KIA0KRnJvbTogQWJoaWphbiBC aGF0dGFjaGFyeXlhIFttYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb21dIA0KU2Vu dDogVHVlc2RheSwgTWF5IDAzLCAyMDE2IDIxOjUzDQpUbzogRGlqaywgRXNrbyA8ZXNrby5kaWpr QHBoaWxpcHMuY29tPg0KQ2M6IGNvcmVAaWV0Zi5vcmcgV0cgPGNvcmVAaWV0Zi5vcmc+OyBOZXZp bCBCcm93bmxlZSANCjxyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPg0KU3ViamVjdDogUkU6IFVzaW5n IGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiByZXNwb25zZXMN CiANCkhpIEVza28sIA0KVGhhbmtzIGZvciByZXNwb25kaW5nLiBUaGUgZGlzY3Vzc2lvbiBpcyBs ZWFkaW5nIHRvIGV4YWN0bHkgd2hhdCBJIHdhcyANCnRoaW5raW5nIGFib3V0LiANClNvLCBpZiB3 ZSBlbmhhbmNlIHRoZSB0ZXh0IGFzIGJlbG93IHdvdWxkIGl0IGJlIGdvb2QgZm9yIHRoZSBwdXJw b3NlPyANClBsZWFzZSBjb21tZW50LiANCg0KIlRoZSBzZXJ2ZXIgTVVTVCBzZW5kIGJhY2sgcmVz cG9uc2VzIG9mIHRoZSBjbGFzc2VzIGZvciB3aGljaCB0aGUgY2xpZW50IA0KaGFzIG5vdCBleHBy ZXNzZWQgYW55IGRpcy1pbnRlcmVzdC4gVGhlcmUgYXJlIGluc3RhbmNlcyB3aGVyZSBhIHNlcnZl ciwgb24gDQppdHMgb3duLCBtYXkgZGVjaWRlIHRvIHN1cHByZXNzIHJlc3BvbnNlcyBsaWtlIHRo ZSBtdWx0aWNhc3Qgc2VydmVycyBhcyANCmRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuNyBvZiAgW1JG QzczOTBdLiBJZiB0aGUgc2VydmVyIHJlY2VpdmVzIGEgcmVxdWVzdCANCndpdGggTm8tUmVzcG9u c2Ugc2hvd2luZyAnaW50ZXJlc3QnIGluIGNlcnRhaW4gcmVzcG9uc2VzIHRoZW4gc3VjaCANCmJl aGF2aW91ciBvZiBzdXBwcmVzc2luZyByZXNwb25zZXMgYnkgc2VydmVycyBNVVNUIGJlIG92ZXIt cmlkZGVuIGZvciANCnRob3NlIHJlc3BvbnNlcyB3aGljaCBhcmUgb2YgaW50ZXJlc3QgdG8gdGhl IGNsaWVudC4gVGhlIHNlcnZlciBNVVNUIHNlbmQgDQp0aG9zZSByZXNwb25zZXMgZm9yIHdoaWNo IHRoZSBjbGllbnQgaGFzIG5vdCBleHByZXNzZWQgYW55IGRpc2ludGVyZXN0IA0KKGkuZS4sIGV4 cHJlc3NlZCAnaW50ZXJlc3QnKS4gU28sIGZvciBleGFtcGxlLCBpZiBhIG11bHRpY2FzdCBzZXJ2 ZXIgDQpkZWNpZGVzIHRvIHN1cHByZXNzIGFsbCByZXNwb25zZXMgYW5kIHJlY2VpdmVzIGEgcmVx dWVzdCB3aXRoIE5vLVJlc3BvbnNlIA0Kb3B0aW9uIGV4cHJlc3NpbmcgZGlzaW50ZXJlc3Qgb25s eSBpbiBzdWNjZXNzIHJlc3BvbnNlcyBidXQgbm90IGluIGVycm9ycyANCnRoZW4gdGhlIHNlcnZl ciBNVVNUIHNlbmQgYmFjayBhIHJlc3BvbnNlIGlmIHRoZSBjb25jZXJuZWQgcmVxdWVzdCBjYXVz ZXMgDQphbiBlcnJvci4gIiANCg0KIEhvcGVmdWxseSwgdGhpcyB3aWxsIHNvbHZlIGEgcG90ZW50 aWFsIHByb2JsZW0gd2hlbiB0aGUgY2xpZW50IGFjdHVhbGx5IA0Kd2FudHMgdG8gZGVidWcgdGhl IGxpZ2h0cyB0aHJvdWdoIGdyYW51bGFyIE5vLVJlc3BvbnNlIGJ1dCB0aGUgc2VydmVycyANCmRl Y2lkZSBub3QgdG8gc2VuZCBhIHJlc3BvbnNlIGFzIGRlZmF1bHQgYmVoYXZpb3VyIGFuZCB0aGUg Y2xpZW50IGlzIG5ldmVyIA0KYXdhcmUgb2YgdGhhdC4gSG93ZXZlciwgaXQgd291bGQgYmUgZ29v ZCBpZiB0aGUgYWJvdmUgY291bGQgYmUgDQpyZWNpcHJvY2F0ZWQgYnkgc29tZSBzcGVjaWZpY2F0 aW9uIHdoaWNoIGRlYWxzIHdpdGggdGhlIHNlcnZlci1zaWRlIA0KYmVoYXZpb3VyLiANCg0KV2Fp dGluZyB0byBoZWFyIGZyb20geW91LiANCg0KUmVnYXJkcw0KQWJoaWphbiBCaGF0dGFjaGFyeXlh DQpBc3NvY2lhdGUgQ29uc3VsdGFudA0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0 YSwgSW5kaWENClRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMNCk1haWx0bzogYWJoaWphbi5iaGF0 dGFjaGFyeXlhQHRjcy5jb20NCldlYnNpdGU6IGh0dHA6Ly93d3cudGNzLmNvbQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkV4cGVyaWVuY2UgY2VydGFpbnR5 LiAgICAgICAgSVQgU2VydmljZXMNCiAgICAgICAgICAgICAgICAgICAgICAgQnVzaW5lc3MgU29s dXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRpbmcNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KIkRpamssIEVza28iIDxlc2tvLmRp amtAcGhpbGlwcy5jb20+IHdyb3RlIG9uIDA1LzAzLzIwMTYgMDE6MjU6MDEgQU06DQoNCj4gRnJv bTogIkRpamssIEVza28iIDxlc2tvLmRpamtAcGhpbGlwcy5jb20+IA0KPiBUbzogQWJoaWphbiBC aGF0dGFjaGFyeXlhIDxhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT4gDQo+IENjOiAiY29y ZUBpZXRmLm9yZyBXRyIgPGNvcmVAaWV0Zi5vcmc+LCBOZXZpbCBCcm93bmxlZSA8cmZjLWlzZUBy ZmMtDQo+IGVkaXRvci5vcmc+IA0KPiBEYXRlOiAwNS8wMy8yMDE2IDAxOjI1IEFNIA0KPiBTdWJq ZWN0OiBSRTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFi bGUqIA0KcmVzcG9uc2VzIA0KPiANCj4gSGksIA0KPiAgIA0KPiA+ICJUaGUgc2VydmVyIE1VU1Qg c2VuZCBiYWNrIHJlc3BvbnNlcyBvZiB0aGUgY2xhc3NlcyBmb3Igd2hpY2ggdGhlIA0KPiBjbGll bnQgaGFzIG5vdCBleHByZXNzZWQgYW55IGRpcy1pbnRlcmVzdC4iIC0gDQo+IFRoaXMgY292ZXJz IHBhcnQgb2YgbXkgdXNlIGNhc2U7IGhvd2V2ZXIgaXQgaXMgbm90IGNsZWFyIGhvdyB0aGlzIA0K PiAiTVVTVCIgaW50ZXJhY3RzIHdpdGggdGhlICJNQVkgc3VwcHJlc3MiIG9mIFJGQyA3MjUyIGZv ciB0aGUgDQo+IG11bHRpY2FzdCBjYXNlLiBDYW4gdGhlIHNlcnZlciBzdGlsbCBkZWNpZGUgdG8g c3VwcHJlc3MgdGhlIA0KPiBtdWx0aWNhc3QgcmVzcG9uc2UgZXZlbiBpZiB0aGUgTm8tUmVzcG9u c2UgT3B0aW9uIHNlbnQgYnkgdGhlIGNsaWVudA0KPiBzYXlzIG5vdCB0bz8gVGhpbmtpbmcgYWJv dXQgaXQsIGl0IHdvdWxkIGJlIHBlcmhhcHMgZ29vZCBpZiBkcmFmdC0NCj4gdGNzLWNvYXAtbm8t cmVzcG9uc2Utb3B0aW9uIHdvdWxkIG1ha2UgdGhhdCBjbGVhci4gVGhlICJNVVNUIiBhbmQgDQo+ IHRoZSB1c2UgY2FzZSA0LjIuMSBzdWdnZXN0IHRoYXQgdGhlIGRlZmF1bHQgc3VwcHJlc3Npb24g Y2hvaWNlcyBvZiANCj4gdGhlIHNlcnZlciBhcmUgb3ZlcnJpZGRlbiBieSB0aGUgTm8tUmVzcG9u c2Ugb3B0aW9uIGJ1dCB0aGF0IGlzIG5vdCANCj4gd3JpdHRlbiBleHBsaWNpdGx5IHlldC4gIElm IHRoYXQgaXMgdGhlIGNhc2UsIG15IHVzZSBjYXNlIGlzIGZ1bGx5IA0KPiBjb3ZlcmVkIGJ5IHlv dXIgZHJhZnQgSSB0aGluay4gDQo+ICAgDQo+IEFuIHVwZGF0ZSBvciBzdWNjZXNzb3IgdG8gdGhl IEdyb3VwY29tbSBSRkMgY291bGQgaW5kZWVkIGRlc2NyaWJlIA0KPiBob3cgdGhlIE5vLVJlc3Bv bnNlIE9wdGlvbiBjYW4gYmUgdXNlZCBmb3IgbXVsdGljYXN0IHVzZSBjYXNlcy4gSXQgDQo+IHdv dWxkIGJlIGdyZWF0IGlmIHRoYXQgY291bGQgYmUgZG9uZSB3aXRob3V0IG5lZWRpbmcgZnVydGhl ciANCj4gbW9kaWZpY2F0aW9ucyB0byBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24h IA0KPiAgIA0KPiByZWdhcmRzIA0KPiBFc2tvIA0KPiAgIA0KPiBGcm9tOiBBYmhpamFuIEJoYXR0 YWNoYXJ5eWEgW21haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbV0gDQo+IFNlbnQ6 IE1vbmRheSwgTWF5IDAyLCAyMDE2IDU6MTkNCj4gVG86IERpamssIEVza28gPGVza28uZGlqa0Bw aGlsaXBzLmNvbT4NCj4gQ2M6IGNvcmVAaWV0Zi5vcmcgV0cgPGNvcmVAaWV0Zi5vcmc+OyBOZXZp bCBCcm93bmxlZSA8DQpyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPg0KPiBTdWJqZWN0OiBSRTogVXNp bmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICplbmFibGUqIA0KcmVzcG9u c2VzDQo+IEltcG9ydGFuY2U6IEhpZ2ggDQo+ICAgDQo+IEhpIEVza28sIA0KPiBUaGUgZXhpc3Rp bmcgdmVyc2lvbiAtMTYgaGFzIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBzZWN0aW9uIDIuMSAocGFn ZSA1KSANCjogDQo+ICJUaGUgc2VydmVyIE1VU1Qgc2VuZCBiYWNrIHJlc3BvbnNlcyBvZiB0aGUg Y2xhc3NlcyBmb3Igd2hpY2ggdGhlIA0KPiBjbGllbnQgaGFzIG5vdCBleHByZXNzZWQgYW55IGRp cy1pbnRlcmVzdC4iIA0KPiBTbywgdGhhdCB3YXkgdGhlIGNsaWVudCBoYXMgYWN0dWFsbHkgZXhw cmVzc2VkIGl0cyBpbnRlcmVzdCAob3IgDQo+IHJlcXVlc3QgZm9yIGVuYWJsZW1lbnQpIGluIGFs bCB0aGUgcmVzcG9uc2VzIGZvciB3aGljaCBpdCBoYXMgbm90IA0KPiBleHByZXNzZWQgZXhwbGlj aXQgZGlzaW50ZXJlc3QuIERvZXMgdGhhdCBoZWxwIHRvIGNvbnRyb2wgdGhlIA0KPiBzcGVjaWFs IHNlcnZlci1zaWRlIGJlaGF2aW91ciBhcyB0aGUgc2VydmVyIGtub3dzIHdoaWNoIGFsbCANCj4g cmVzcG9uc2VzIHRoZSBjbGllbnQgaXMgaW50ZXJlc3RlZCBpbiBhbmQgaXQgTVVTVCBzZW5kIGEg cmVzcG9uc2UgDQo+IGJhY2sgPyBJIHNoYWxsIHN1Ym1pdCBhbm90aGVyIHZlcnNpb24gd2l0aCBz b21lIGVkaXRvcmlhbCBjaGFuZ2VzIA0KPiBiZWZvcmUgdGhlIGRyYWZ0IGdvZXMgdG8gSUVTRy4g U28gd2UgaGF2ZSBzb21lIG1vcmUgcm9vbSBmb3IgDQo+IG1vZGlmaWNhdGlvbi4gSWYgeW91IGhh dmUgc29tZSBjb21tZW50cyBvbiB0aGlzIGluIHRoZSBsaW5lIG9mIHRoZSANCj4gZGlzY3Vzc2lv biB3ZSBhcmUgaGF2aW5nLCBwbGVhc2UgbGV0IHVzIGtub3cuIEkgc2hhbGwgd2FpdCBmb3IgeW91 ciANCj4gdmlld3MgYmVmb3JlIHN1Ym1pdHRpbmcgdGhlIHVwZGF0ZWQgdmVyc2lvbi4gDQo+IA0K PiBBbnl3YXksIGEgc2VwYXJhdGUgZHJhZnQgKG9yLCBwb3NzaWJseSwgYW4gdXBkYXRlZCBncm91 cGNvbW0gUkZDPykgDQo+IGlzIGEgZ29vZCBpZGVhLiBOby1SZXNwb25zZSBhc3N1bWVzIHRoZSB1 c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIA0KPiBzeW1hbnRpY3MgYW5kIGl0IG1haW5seSBhZGRyZXNz ZXMgdGhlIGNsaWVudCBzaWRlIGJlaGF2aW91ciBhbmQgDQo+IGlzc3Vlcy4gQ29uc2lkZXJpbmcg c3VjaCBzcGVjaWFsIGJlaGF2aW91ciBvZiBncm91cGNvbW0gc2VydmVycywgaXQgDQo+IHdvdWxk IGJlIGdvb2QgdG8gaGFuZGxlIHNlcGFyYXRlbHkuIA0KPiANCj4gV2FpdGluZyB0byBoZWFyIGZy b20geW91LiANCj4gDQo+IFJlZ2FyZHMNCj4gQWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+IEFzc29j aWF0ZSBDb25zdWx0YW50DQo+IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIElu ZGlhDQo+IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMNCj4gTWFpbHRvOiBhYmhpamFuLmJoYXR0 YWNoYXJ5eWFAdGNzLmNvbQ0KPiBXZWJzaXRlOiBodHRwOi8vd3d3LnRjcy5jb20NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRXhwZXJpZW5jZSBjZXJ0 YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0KPiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2lu ZXNzIFNvbHV0aW9ucw0KPiAgICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRpbmcNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IA0KPiAiRGlq aywgRXNrbyIgPGVza28uZGlqa0BwaGlsaXBzLmNvbT4gd3JvdGUgb24gMDUvMDIvMjAxNiAwMzox MDoyNCBBTToNCj4gDQo+ID4gRnJvbTogIkRpamssIEVza28iIDxlc2tvLmRpamtAcGhpbGlwcy5j b20+IA0KPiA+IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgPGFiaGlqYW4uYmhhdHRhY2hhcnl5 YUB0Y3MuY29tPiANCj4gPiBDYzogImNvcmVAaWV0Zi5vcmcgV0ciIDxjb3JlQGlldGYub3JnPiwg TmV2aWwgQnJvd25sZWUgPHJmYy1pc2VAcmZjLQ0KPiA+IGVkaXRvci5vcmc+IA0KPiA+IERhdGU6 IDA1LzAyLzIwMTYgMDM6MTAgQU0gDQo+ID4gU3ViamVjdDogUkU6IFVzaW5nIGRyYWZ0LXRjcy1j b2FwLW5vLXJlc3BvbnNlLW9wdGlvbiB0byAqZW5hYmxlKiANCnJlc3BvbnNlcyANCj4gPiANCj4g PiBIZWxsbyBBYmhpamFuLCANCj4gPiANCj4gPiA+IE1hbmRhdGluZyBzdWNoIHNlcnZlciBiZWhh dmlvdXIgZnJvbSB0aGUgY2xpZW50IHNpZGUgd2lsbCBiZSBhIGJpdA0KPiA+IG91dC1vZi1zeW5j IHdpdGggdGhlIHNwaXJpdCBvZiB0aGUgc3BlY2lmaWNhdGlvbi4gDQo+ID4gVGhpcyBpcyBub3Qg ZnVsbHkgY2xlYXIgdG8gbWUgeWV0IOKApiB0aGUgY2xpZW50IGRvZXMgbm90IG1hbmRhdGUgDQo+ ID4gYW55dGhpbmcgZnJvbSB0aGUgc2VydmVyOyBpdCBqdXN0IGV4cHJlc3NlcyBpdHMgaW50ZXJl c3QgKDAtYml0cykgDQo+ID4gYW5kIGRpc2ludGVyZXN0ICgxLWJpdHMpLiBUaGUgc2VydmVyIGNh biBhbHdheXMgbm90IHBhcnNlIHRoZSBvcHRpb24NCj4gPiAoZWxlY3RpdmUpIG9yIGNob29zZSBu b3QgdG8gYm90aGVyIGFib3V0IGl0LiANCj4gPiBUaGlzIGRvZXMga2VlcCB0aGUgY2xpZW50IHdh aXRpbmcgZm9yIGEgcG9zc2libGUgcmVzcG9uc2UgdGhhdCBuZXZlcg0KPiA+IGNvbWVzOyBidXQg dGhhdCBpcyB0aGUgc2FtZSBpbiB0aGUgZ2VuZXJhbCBtdWx0aWNhc3QgY2FzZSA6IHRoZSANCj4g PiBjbGllbnQgY2FuIG5ldmVyIGtub3cgaWYgb3Igd2hlbiBhIHJlc3BvbnNlIHdpbGwgY29tZSwg dGhlIHNlcnZlciANCj4gPiBNQVkgYWx3YXlzIGNob29zZSB0byBub3QgcmVzcG9uZC4gDQo+ID4g DQo+ID4gU28gd2hhdCBJIHByb3Bvc2UgaXMgdG8gdXNlIHRoZSAiaW5kaWNhdGlvbiBvZiBpbnRl cmVzdCIgdG8gc3BlY2lmaWMNCj4gPiByZXNwb25zZSBjbGFzc2VzIGluIGEgbmV3IHdheTsgbmFt ZWx5IHRvIGVuYWJsZSBjZXJ0YWluIHJlc3BvbnNlIA0KPiA+IGNsYXNzZXMgdGhhdCBhcmUgc3Vw cHJlc3NlZCBieSBkZWZhdWx0LiAgSXQganVzdCBoYXBwZW5zIHRoYXQgdGhlIA0KPiA+IHNhbWUg T3B0aW9uIHN5bnRheCBpcyB2ZXJ5IHdlbGwgc3VpdGVkIGZvciB0aGF0IHB1cnBvc2UuIEEgc2Vw YXJhdGUgDQo+ID4gZHJhZnQgY291bGQgYmUgd3JpdHRlbiBmb3IgdGhhdCBwZXJoYXBzIGlmIHlv dSB0aGluayBpdCBkb2VzIG5vdCBmaXQNCj4gPiBpbiBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25z ZS1vcHRpb24gb3IgaWYgaXQgaXMgdG9vIGxhdGUgZm9yIHRoYXQuIA0KPiA+IFRoZSB3ZSBjYW4g cG9pbnQgdG8gdGhlIHN5bnRheCBvZiB0aGUgTm8tUmVzcG9uc2UgT3B0aW9uIGFuZCByZS11c2Ug DQo+ID4gaXQgY29tcGxldGVseS4gDQo+ID4gDQo+ID4gcmVnYXJkcyANCj4gPiBFc2tvIA0KPiA+ IA0KPiA+IEZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRh Y2hhcnl5YUB0Y3MuY29tXSANCj4gPiBTZW50OiBGcmlkYXksIEFwcmlsIDIyLCAyMDE2IDE3OjE3 DQo+ID4gVG86IERpamssIEVza28gPGVza28uZGlqa0BwaGlsaXBzLmNvbT4NCj4gPiBDYzogY29y ZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9yZz47IE5ldmlsIEJyb3dubGVlIDwNCnJmYy1pc2VA cmZjLWVkaXRvci5vcmcNCj4gPg0KPiA+IFN1YmplY3Q6IFJlOiBVc2luZyBkcmFmdC10Y3MtY29h cC1uby1yZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSogDQpyZXNwb25zZXMgDQo+ID4gDQo+ID4g SGkgRXNrbywgDQo+ID4gVGhhbmtzIGZvciB5b3VyIG1haWwuIA0KPiA+IEZpcnN0IG9mIGFsbCBs ZXQgbWUganVzdCBicmluZyB0aGlzIHRvIHlvdXIgKGFzIHdlbGwgYXMgdGhlIG1haWxpbmcgDQo+ ID4gbGlzdCdzKSBub3RpY2UgdGhhdCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlz OiANCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGNzLWNv YXAtbm8tcmVzcG9uc2UtDQo+IG9wdGlvbi0xNi50eHQNCj4gPiANCj4gPiBUaGlzIHZlcnNpb24g Im9mZmljaWFsbHkiIGNsb3NlcyB0aGUgdGVjaG5pY2FsIHJldmlld3MgYW5kIGlzIHdpdGggDQo+ ID4gdGhlIFJGQyBlZGl0b3IgdGhyb3VnaCB0aGUgSVMgdHJhY2suIA0KPiA+IA0KPiA+IE5vdyBj b21pbmcgdG8geW91ciB1c2UgY2FzZSAoYW5kIGluZGVlZCBpdCBpcyBhbiBpbnRlcmVzdGluZyBv bmUpIA0KPiA+IG9uZSB0aGluZyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBpcyB0aGF0IHRoZSBO by1SZXNwb25zZSBvcHRpb24gd2FzDQo+ID4gZGVsaWJlcmF0ZWx5IGRlc2lnbmVkIG5vdCB0byBt YW5kYXRlIGFueXRoaW5nIGZvciB0aGUgc2VydmVyIHNpZGUgDQo+ID4gbWFpbmx5IHRvIGVuc3Vy ZSB0aGF0IGl0IGRvZXMgbm90IGRpc3J1cHQgdGhlIG1hbnkgdXNlZnVsbmVzcyBvZiB0aGUNCj4g PiB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIHN5bWFudGljcy4gVGhlIGRyYWZ0IGFsbCBhbG9uZyBk ZWFscyB3aXRoIHRoZQ0KPiA+IHJlcXVlc3RpbmcgY2xpZW50J3MgYmVoYXZpb3VyIGFuZCBpdHMg ZXhwcmVzc2lvbiBvZiBpbnRlcmVzdCB0byB0aGUgDQo+ID4gc2VydmVyLiBTaW5jZSB0aGlzIG9w dGlvbiBpcyBlbGVjdGl2ZSB3ZSBsZWF2ZSBpdCB1cHRvIHRoZSBzZXJ2ZXIgDQo+ID4gaW1wbGVt ZW50YXRpb24gdG8gaG9ub3VyIHRoZSBjbGllbnQncyBpbnRlcmVzdC4gDQo+ID4gDQo+ID4gTm93 LCBhcyBwZXIgdXN1YWwgcmVxdWVzdC9yZXNwb25zZSBzeW1hbnRpY3MgdGhlIHJlc3BvbnNlcyBh cmUgDQo+ID4gYWx3YXlzIGVuYWJsZWQuIFRoZSBiZWhhdmlvdXIgaW4gZ3JvdXBjb21tIHNlcnZl ciBpbiB0ZXJtcyBvZiANCj4gPiBzdXBwcmVzc2luZyB0aGUgcmVzcG9uc2VzIG9uIGl0cyBvd24g aXMgc29tZXRoaW5nIHNwZWNpYWwgYW5kLCANCj4gPiBnZW5lcmFsbHkgc3BlYWtpbmcsIHRoZSBj bGllbnRzIGFyZSBub3QgYXdhcmUgb2Ygc3VjaCBzcGVjaWFsIA0KYmVoYXZpb3VyLiANCj4gPiAN Cj4gPiBTbywgaXQgd291bGQgYmUganVzdGlmaWVkIHRvIGhhbmRsZSB0aGUgc2l0dWF0aW9uIGF0 IHRoZSBzZXJ2ZXIncyANCj4gPiBlbmQuIEhlcmUgaXMgdGhlIGlkZWE6IA0KPiA+IFdoaWxlIE5v LVJlc3BvbnNlIGlzIHRvIGV4cHJlc3NlcyBjbGllbnQncyBkaXMtaW50ZXJlc3QgaW4gc29tZSBv ciANCj4gPiBhbGwgb2YgdGhlIHJlc3BvbnNlcyBkZXBlbmRpbmcgb24gdGhlIG9wdGlvbiB2YWx1 ZSwgaXQgaXMgYWxzbyB0cnVlIA0KPiA+IHRoYXQgdGhlIG9wdGlvbiBhdXRvbWF0aWNhbGx5IGV4 cHJlc3NlcyBpbnRlcmVzdCBpbiBhbGwgb3RoZXIgDQo+ID4gcmVzcG9uc2VzIChtYXJrZWQgYnkg MCdzIGluIHRoZSByZXNwZWN0aXZlIHBvc2l0aW9ucykuIFRoZSBjbGllbnQgaXMNCj4gPiBnb2lu ZyB0byB3YWl0IGZvciB0aGVzZSByZXNwb25zZXMgdXB0byBhIGdpdmVuIHRpbWVvdXQuIE5vdywg aWYgdGhlIA0KPiA+IHNlcnZlciBiZWhhdmlvdXIgaXMgbW9kaWZpZWQgbGlrZSB0aGlzIDogIkkg aGF2ZSBjbG9zZWQgbXkgZG9vciBmb3IgDQo+ID4gYWxsIG91dCBnb2luZyByZXNwb25zZS4gKipC VVQqKiwgaWYgSSBzZWUgYSBmZWxsb3cgcmVxdWVzdGluZyB3aXRoIA0KPiA+IE5vLVJlc3BvbnNl IGFuZCBrZWVwaW5nIHdpbmRvd3Mgb3BlbiB0byBzb21lIHJlc3BvbnNlcyB0aGVuIEkgYXNzdW1l DQo+ID4gdGhhdCB0aGlzIGd1eSByZWFsbHkgbmVlZHMgdGhvc2Uga2luZCBvZiByZXNwb25zZXMu IEluIHRoYXQgY2FzZSBsZXQNCj4gPiBtZSBiZSBsaW5pZW50IGFuZCBsZXQgbWUgb3BlbiB0aGUg ZG9vciBmb3Igc3VjaCByZXNwb25zZXMuIFRoaXMgDQo+ID4gZmVsbG93IG11c3QgYmUgYXZhaWxh YmxlIHRvIGxpc3RlbiB0byB0aGVtIGFzIHBlciB0aGUgcHJlc2NyaWJlZCANCj4gPiBiZWhhdmlv dXIgaW4gdGhlIE5vLVJlc3BvbnNlIHNwZWNpZmljYXRpb24uIiANCj4gPiANCj4gPiBNYW5kYXRp bmcgc3VjaCBzZXJ2ZXIgYmVoYXZpb3VyIGZyb20gdGhlIGNsaWVudCBzaWRlIHdpbGwgYmUgYSBi aXQgDQo+ID4gb3V0LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZpY2F0aW9u LiANCj4gPiANCj4gPiBSZWdhcmRzDQo+ID4gQWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+ID4gQXNz b2NpYXRlIENvbnN1bHRhbnQNCj4gPiBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRh LCBJbmRpYQ0KPiA+IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMNCj4gPiBNYWlsdG86IGFiaGlq YW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQo+ID4gV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29t DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBF eHBlcmllbmNlIGNlcnRhaW50eS4gICAgICAgIElUIFNlcnZpY2VzDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCj4gPiAgICAgICAgICAgICAgICAgICAgICAg IENvbnN1bHRpbmcNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEZyb206ICAgICAgICAiRGlqaywgRXNr byIgPGVza28uZGlqa0BwaGlsaXBzLmNvbT4gDQo+ID4gVG86ICAgICAgICBBYmhpamFuIEJoYXR0 YWNoYXJ5eWEgPGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPiANCj4gPiBDYzogICAgICAg IE5ldmlsIEJyb3dubGVlIDxyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPiwgImNvcmVAaWV0Zi5vcmcg V0ciIA0KPA0KPiA+IGNvcmVAaWV0Zi5vcmc+IA0KPiA+IERhdGU6ICAgICAgICAwNC8yMi8yMDE2 IDA1OjQzIFBNIA0KPiA+IFN1YmplY3Q6ICAgICAgICBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1y ZXNwb25zZS1vcHRpb24gdG8gDQo+ICplbmFibGUqIHJlc3BvbnNlcyANCj4gPiANCj4gPiANCj4g PiANCj4gPiANCj4gPiBIZWxsbyBBYmhpamFuLA0KPiA+IA0KPiA+IGluIG91ciBwcm9qZWN0IHdl IHNlZSBhIGNsZWFyIHVzZSBjYXNlIG9mIHVzaW5nIHRoZSBOby1SZXNwb25zZSANCj4gPiBPcHRp b24gdG8gKmVuYWJsZSogY2VydGFpbiByZXNwb25zZXMgdGhhdCBhcmUgYnkgZGVmYXVsdCBzdXBw cmVzc2VkLg0KPiA+IENvQVAgYWxsb3dzIHN1cHByZXNzaW9uIG9mIG11bHRpY2FzdCByZXNwb25z ZXMgYnkgZGVmYXVsdCwgd2hpY2ggaXMgDQo+ID4gd2hhdCB3ZSB1c2UgZm9yIGEgbGlnaHRpbmcg bXVsdGljYXN0IHVzZSBjYXNlLiBIb3dldmVyIGZvciANCj4gPiBkaWFnbm9zdGljIHVzYWdlIHdl J2QgbGlrZSB0byBlbmFibGUgdGhlc2UgcmVzcG9uc2VzIGFnYWluIHVzaW5nIHRoZQ0KPiA+IE5v LVJlc3BvbnNlIG9wdGlvbiB3aGljaCBpcyBwZXJmZWN0bHkgc3VpdGVkIGZvciB0aGF0LiBIb3dl dmVyLCB0aGUgDQo+ID4gZHJhZnQgdGV4dCBjdXJyZW50bHkgb25seSB0YWxrcyBhYm91dCBzdXBw cmVzc2luZyByZXNwb25zZXMgKG5vdCANCmVuYWJsaW5nKS4NCj4gPiANCj4gPiBIZW5jZSBteSBy ZXF1ZXN0OiBjb3VsZCB3ZSBtb2RpZnkvYWRkIHNvbWUgdGV4dCB0byBzaG93IHRoYXQgYWxzbyAN Cj4gPiB0aGUgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGVuYWJsZSByZXNwb25zZXMgaW4gY2FzZSB3 aGVyZSB0aGV5IGFyZSANCj4gPiBub3JtYWxseSAoYnkgZGVmYXVsdCAtLSBzZXJ2ZXIgZGVjaXNp b24pIHN1cHByZXNzZWQ/DQo+ID4gSnVzdCB0byBjbGFyaWZ5IHN1Y2ggdXNhZ2U7IHdoaWNoIGlz IHF1aXRlIHVzZWZ1bCBpbiBteSB2aWV3Lg0KPiA+IA0KPiA+IHJlZ2FyZHMNCj4gPiBFc2tvDQo+ ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCAN Cj4gPiBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2Ug aXMgaW50ZW5kZWQgDQo+ID4gc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCANCj4gPiB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIA0KPiA+IHJlcHJv ZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IA0KPiA+IHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgY29udGFjdCB0aGUgDQo+ID4gc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ry b3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgDQptZXNzYWdlLiANCj4gPiA9PT09PS0tLS0t PT09PT0tLS0tLT09PT09DQo+ID4gTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZS1tYWlsDQo+ID4gbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNv bnRhaW4gDQo+ID4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlv dSBhcmUgDQo+ID4gbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9u LCB1c2UsIA0KPiA+IHJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9m IHRoZSANCj4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSAN Cj4gPiBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElm IA0KPiA+IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgDQo+ ID4gcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCANCj4g PiBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIA0KPiA+IGFu ZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdSANCj4gDQo+IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIA0KPiBsZWdhbGx5 IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQg DQo+IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgDQo+IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwg Zm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgDQo+IHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1l c3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIA0KPiB1bmxhd2Z1bC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIA0K PiBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBv cmlnaW5hbCBtZXNzYWdlLiANCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1l c3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSANCnByb3RlY3RlZCB1bmRlciBh cHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgDQph ZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBh cmUgaGVyZWJ5IA0Kbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0 aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyANCm1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgDQppbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQg ZGVzdHJveSANCmFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQoNCg== --=_alternative 0019F30665257FA9_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVza28sPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MuIEkgc2hhbGwgdXBkYXRlIHRoZSBuZXh0 IHZlcnNpb24NCmFjY29yZGluZ2x5LiBJIGFtIGhhcHB5IHRoYXQgd2UgY291bGQgc2F0aXNmeSB5 b3VyIHVzZSBjYXNlIGZpbmFsbHkuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+UmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCkFz c29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0 YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFpbHRvOiBhYmhp amFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0 dHA6Ly93d3cudGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93 d3cudGNzLmNvbTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJp ZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJv bTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7RGlqaywgRXNrbyZxdW90Ow0KJmx0O2Vza28uZGlqa0BwaGlsaXBz LmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fu cy1zZXJpZiI+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KJmx0O2FiaGlqYW4u YmhhdHRhY2hhcnl5YUB0Y3MuY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9 IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y29yZUBpZXRmLm9y Zw0KV0cmcXVvdDsgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7LCBOZXZpbCBCcm93bmxlZSAmbHQ7cmZj LWlzZUByZmMtZWRpdG9yLm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1 ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MDUvMDQvMjAxNiAwMjo0NCBB TTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlm Ij5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Ut b3B0aW9uDQp0byAqZW5hYmxlKiByZXNwb25zZXM8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFkZT4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SGVsbG8gQWJoaWph biw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QWdyZWVkOyBiZWxvdyBhIHByb3Bvc2Vk IHVwZGF0ZWQgdGV4dCB0aGF0DQpzZXBhcmF0ZXMgdGhlIGV4YW1wbGUgZnJvbSB0aGUgc3BlY2lm aWNhdGlvbiBwYXJ0LiBUaGUgbnVtYmVyIG9mIE1VU1RzDQppcyBhbHNvIHJlZHVjZWQgdG8gdHdv LiAoTWlnaHQgYmUgZXZlbiByZWR1Y2VkIHRvIG9uZSDigJMgb25seSB0aGUgZmlyc3QsDQpidXQg bGVhdmluZyB0aGF0IHRvIHRoZSBlZGl0aW5nIHByb2Nlc3PigKYgSSB0aGluayBhbiBleGFtcGxl IHR5cGljYWxseQ0KZG9lcyBub3QgaGF2ZSBhIE1VU1QpPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh bGlicmkiPi0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhlIHNl cnZlciBNVVNUIHNlbmQgYmFjayByZXNwb25zZXMgb2YNCnRoZSBjbGFzc2VzIGZvciB3aGljaCB0 aGUgY2xpZW50IGhhcyBub3QgZXhwcmVzc2VkIGFueSBkaXNpbnRlcmVzdC4gVGhlcmUNCmFyZSBp bnN0YW5jZXMgd2hlcmUgYSBzZXJ2ZXIsIG9uIGl0cyBvd24sIGRlY2lkZXMgdG8gc3VwcHJlc3Mg cmVzcG9uc2VzDQpsaWtlIHRoZSBtdWx0aWNhc3Qgc2VydmVycyBkZXNjcmliZWQgaW4gU2VjdGlv biAyLjcgb2YgJm5ic3A7W1JGQzczOTBdLg0KSWYgc3VjaCBhIHNlcnZlciByZWNlaXZlcyBhIHJl cXVlc3Qgd2l0aCBhIE5vLVJlc3BvbnNlIE9wdGlvbiBzaG93aW5nIGludGVyZXN0DQppbiBzcGVj aWZpYyByZXNwb25zZSBjbGFzc2VzLCB0aGVuIGFueSBkZWZhdWx0IGJlaGF2aW91ciBvZiBzdXBw cmVzc2luZw0KcmVzcG9uc2VzIOKAkyBpZiBwcmVzZW50IOKAkyBNVVNUIGJlIG92ZXJyaWRkZW4g dG8gZGVsaXZlciB0aG9zZSByZXNwb25zZXMNCndoaWNoIGFyZSBvZiBpbnRlcmVzdCB0byB0aGUg Y2xpZW50LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+U28sIGZvciBleGFtcGxlLCBp ZiBhIG11bHRpY2FzdCBzZXJ2ZXINCnN1cHByZXNzZXMgYWxsIHJlc3BvbnNlcyBieSBkZWZhdWx0 IGFuZCByZWNlaXZlcyBhIHJlcXVlc3Qgd2l0aCBhIE5vLVJlc3BvbnNlDQpPcHRpb24gZXhwcmVz c2luZyBkaXNpbnRlcmVzdCBpbiAyLnh4IHN1Y2Nlc3MgcmVzcG9uc2VzLCBhbmQgaW50ZXJlc3Qg aW4NCmVycm9yIHJlc3BvbnNlcyA0Lnh4LzUueHgsIHRoZW4gdGhlIHNlcnZlciBtdXN0IHNlbmQg YmFjayBhIHJlc3BvbnNlIGlmDQp0aGUgY29uY2VybmVkIHJlcXVlc3QgY2F1c2VkIGFuIGVycm9y LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+LS0tPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPnJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5Fc2tvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxiPkZyb206PC9i PiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgWzwvZm9udD48YSBocmVmPW1haWx0bzphYmhpamFuLmJo YXR0YWNoYXJ5eWFAdGNzLmNvbT48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+bWFpbHRvOmFi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IFR1ZXNkYXksIE1heSAwMywgMjAxNiAyMTo1 MzxiPjxicj4NClRvOjwvYj4gRGlqaywgRXNrbyAmbHQ7ZXNrby5kaWprQHBoaWxpcHMuY29tJmd0 OzxiPjxicj4NCkNjOjwvYj4gY29yZUBpZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs7 IE5ldmlsIEJyb3dubGVlICZsdDtyZmMtaXNlQHJmYy1lZGl0b3Iub3JnJmd0OzxiPjxicj4NClN1 YmplY3Q6PC9iPiBSRTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRv ICplbmFibGUqIHJlc3BvbnNlczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5I aSBFc2tvLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5rcyBmb3IgcmVzcG9uZGluZy4g VGhlIGRpc2N1c3Npb24gaXMgbGVhZGluZyB0byBleGFjdGx5IHdoYXQgSSB3YXMNCnRoaW5raW5n IGFib3V0LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU28sIGlmIHdlIGVuaGFuY2UgdGhlIHRl eHQgYXMgYmVsb3cgd291bGQgaXQgYmUgZ29vZCBmb3IgdGhlIHB1cnBvc2U/IFBsZWFzZQ0KY29t bWVudC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiZxdW90O1RoZSBzZXJ2ZXIgTVVT VCBzZW5kIGJhY2sgcmVzcG9uc2VzIG9mIHRoZSBjbGFzc2VzIGZvciB3aGljaCB0aGUNCmNsaWVu dCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlzLWludGVyZXN0LiBUaGVyZSBhcmUgaW5zdGFuY2Vz IHdoZXJlIGENCnNlcnZlciwgb24gaXRzIG93biwgbWF5IGRlY2lkZSB0byBzdXBwcmVzcyByZXNw b25zZXMgbGlrZSB0aGUgbXVsdGljYXN0DQpzZXJ2ZXJzIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDIuNyBvZiAmbmJzcDtbUkZDNzM5MF0uIElmIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMNCmEgcmVxdWVz dCB3aXRoIE5vLVJlc3BvbnNlIHNob3dpbmcgJ2ludGVyZXN0JyBpbiBjZXJ0YWluIHJlc3BvbnNl cyB0aGVuDQpzdWNoIGJlaGF2aW91ciBvZiBzdXBwcmVzc2luZyByZXNwb25zZXMgYnkgc2VydmVy cyBNVVNUIGJlIG92ZXItcmlkZGVuDQpmb3IgdGhvc2UgcmVzcG9uc2VzIHdoaWNoIGFyZSBvZiBp bnRlcmVzdCB0byB0aGUgY2xpZW50LiBUaGUgc2VydmVyIE1VU1QNCnNlbmQgdGhvc2UgcmVzcG9u c2VzIGZvciB3aGljaCB0aGUgY2xpZW50IGhhcyBub3QgZXhwcmVzc2VkIGFueSBkaXNpbnRlcmVz dA0KKGkuZS4sIGV4cHJlc3NlZCAnaW50ZXJlc3QnKS4gU28sIGZvciBleGFtcGxlLCBpZiBhIG11 bHRpY2FzdCBzZXJ2ZXIgZGVjaWRlcw0KdG8gc3VwcHJlc3MgYWxsIHJlc3BvbnNlcyBhbmQgcmVj ZWl2ZXMgYSByZXF1ZXN0IHdpdGggTm8tUmVzcG9uc2Ugb3B0aW9uDQpleHByZXNzaW5nIGRpc2lu dGVyZXN0IG9ubHkgaW4gc3VjY2VzcyByZXNwb25zZXMgYnV0IG5vdCBpbiBlcnJvcnMgdGhlbg0K dGhlIHNlcnZlciBNVVNUIHNlbmQgYmFjayBhIHJlc3BvbnNlIGlmIHRoZSBjb25jZXJuZWQgcmVx dWVzdCBjYXVzZXMgYW4NCmVycm9yLiAmcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCiBIb3BlZnVsbHksIHRoaXMgd2lsbCBzb2x2ZSBhIHBvdGVudGlhbCBwcm9ibGVtIHdoZW4g dGhlIGNsaWVudCBhY3R1YWxseQ0Kd2FudHMgdG8gZGVidWcgdGhlIGxpZ2h0cyB0aHJvdWdoIGdy YW51bGFyIE5vLVJlc3BvbnNlIGJ1dCB0aGUgc2VydmVycw0KZGVjaWRlIG5vdCB0byBzZW5kIGEg cmVzcG9uc2UgYXMgZGVmYXVsdCBiZWhhdmlvdXIgYW5kIHRoZSBjbGllbnQgaXMgbmV2ZXINCmF3 YXJlIG9mIHRoYXQuIEhvd2V2ZXIsIGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGFib3ZlIGNvdWxk IGJlIHJlY2lwcm9jYXRlZA0KYnkgc29tZSBzcGVjaWZpY2F0aW9uIHdoaWNoIGRlYWxzIHdpdGgg dGhlIHNlcnZlci1zaWRlIGJlaGF2aW91ci48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpXYWl0aW5nIHRvIGhlYXIgZnJvbSB5b3UuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpSZWdhcmRzPGJyPg0KQWJoaWphbiBCaGF0dGFjaGFyeXlhPGJyPg0KQXNzb2NpYXRlIENvbnN1 bHRhbnQ8YnI+DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4N ClRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXM8YnI+DQpNYWlsdG86IDwvZm9udD48YSBocmVmPW1h aWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJBcmlhbCI+PHU+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCldlYnNpdGU6IDwvZm9udD48YSBo cmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJp YWwiPjx1Pmh0dHA6Ly93d3cudGNzLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpFeHBlcmllbmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 SVQgU2VydmljZXM8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgQnVzaW5lc3MgU29sdXRpb25z PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IENvbnN1bHRpbmc8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48YnI+DQomcXVvdDtEaWprLCBFc2tvJnF1b3Q7ICZsdDs8L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IkNvdXJpZXIgTmV3Ij48dT5lc2tvLmRpamtAcGhpbGlwcy5jb208L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsNCndyb3RlIG9uIDA1LzAzLzIwMTYg MDE6MjU6MDEgQU06PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDtEaWprLCBFc2tvJnF1b3Q7 ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5lc2tvLmRpamtAcGhpbGlwcy5j b208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5 eWEgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+YWJoaWphbi5i aGF0dGFjaGFyeXlhQHRjcy5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IENjOiAm cXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y29yZUBpZXRmLm9yZyUyMFdHPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5jb3JlQGlldGYub3JnDQpXRzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+JnF1b3Q7ICZsdDs8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86Y29yZUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJDb3VyaWVyIE5ldyI+PHU+Y29yZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OywNCk5ldmlsIEJyb3dubGVlICZsdDtyZmMtaXNl QHJmYy08YnI+DQomZ3Q7IGVkaXRvci5vcmcmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQomZ3Q7IERhdGU6IDA1LzAzLzIwMTYgMDE6MjUgQU08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48YnI+DQomZ3Q7IFN1YmplY3Q6IFJFOiBVc2luZyBkcmFmdC10Y3MtY29hcC1uby1yZXNw b25zZS1vcHRpb24gdG8gKmVuYWJsZSogcmVzcG9uc2VzPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJmd0OyAm cXVvdDtUaGUgc2VydmVyIE1VU1Qgc2VuZCBiYWNrIHJlc3BvbnNlcyBvZiB0aGUgY2xhc3NlcyBm b3INCndoaWNoIHRoZSA8YnI+DQomZ3Q7IGNsaWVudCBoYXMgbm90IGV4cHJlc3NlZCBhbnkgZGlz LWludGVyZXN0LiZxdW90OyAtIDxicj4NCiZndDsgVGhpcyBjb3ZlcnMgcGFydCBvZiBteSB1c2Ug Y2FzZTsgaG93ZXZlciBpdCBpcyBub3QgY2xlYXIgaG93IHRoaXMNCjxicj4NCiZndDsgJnF1b3Q7 TVVTVCZxdW90OyBpbnRlcmFjdHMgd2l0aCB0aGUgJnF1b3Q7TUFZIHN1cHByZXNzJnF1b3Q7IG9m IFJGQw0KNzI1MiBmb3IgdGhlIDxicj4NCiZndDsgbXVsdGljYXN0IGNhc2UuIENhbiB0aGUgc2Vy dmVyIHN0aWxsIGRlY2lkZSB0byBzdXBwcmVzcyB0aGUgPGJyPg0KJmd0OyBtdWx0aWNhc3QgcmVz cG9uc2UgZXZlbiBpZiB0aGUgTm8tUmVzcG9uc2UgT3B0aW9uIHNlbnQgYnkgdGhlIGNsaWVudDxi cj4NCiZndDsgc2F5cyBub3QgdG8/IFRoaW5raW5nIGFib3V0IGl0LCBpdCB3b3VsZCBiZSBwZXJo YXBzIGdvb2QgaWYgZHJhZnQtPGJyPg0KJmd0OyB0Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24g d291bGQgbWFrZSB0aGF0IGNsZWFyLiBUaGUgJnF1b3Q7TVVTVCZxdW90Ow0KYW5kIDxicj4NCiZn dDsgdGhlIHVzZSBjYXNlIDQuMi4xIHN1Z2dlc3QgdGhhdCB0aGUgZGVmYXVsdCBzdXBwcmVzc2lv biBjaG9pY2VzIG9mDQo8YnI+DQomZ3Q7IHRoZSBzZXJ2ZXIgYXJlIG92ZXJyaWRkZW4gYnkgdGhl IE5vLVJlc3BvbnNlIG9wdGlvbiBidXQgdGhhdCBpcyBub3QNCjxicj4NCiZndDsgd3JpdHRlbiBl eHBsaWNpdGx5IHlldC4gJm5ic3A7SWYgdGhhdCBpcyB0aGUgY2FzZSwgbXkgdXNlIGNhc2UgaXMN CmZ1bGx5IDxicj4NCiZndDsgY292ZXJlZCBieSB5b3VyIGRyYWZ0IEkgdGhpbmsuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxicj4NCiZndDsgQW4gdXBkYXRlIG9yIHN1Y2Nlc3NvciB0byB0aGUgR3JvdXBjb21tIFJG QyBjb3VsZCBpbmRlZWQgZGVzY3JpYmUNCjxicj4NCiZndDsgaG93IHRoZSBOby1SZXNwb25zZSBP cHRpb24gY2FuIGJlIHVzZWQgZm9yIG11bHRpY2FzdCB1c2UgY2FzZXMuIEl0DQo8YnI+DQomZ3Q7 IHdvdWxkIGJlIGdyZWF0IGlmIHRoYXQgY291bGQgYmUgZG9uZSB3aXRob3V0IG5lZWRpbmcgZnVy dGhlciA8YnI+DQomZ3Q7IG1vZGlmaWNhdGlvbnMgdG8gZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9u c2Utb3B0aW9uITwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJm5ic3A7PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IHJlZ2FyZHM8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCiZndDsgRXNrbzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K Jmd0OyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgRnJvbTogQWJo aWphbiBCaGF0dGFjaGFyeXlhIFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFj aGFyeXlhQHRjcy5jb20+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXci Pjx1Pm1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+XQ0KPGJyPg0KJmd0OyBTZW50OiBNb25kYXks IE1heSAwMiwgMjAxNiA1OjE5PGJyPg0KJmd0OyBUbzogRGlqaywgRXNrbyAmbHQ7PC9mb250Pjxh IGhyZWY9bWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ZXNrby5kaWprQHBoaWxpcHMuY29tPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PGJyPg0KJmd0OyBDYzogPC9m b250PjxhIGhyZWY9bWFpbHRvOmNvcmVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iQ291cmllciBOZXciPjx1PmNvcmVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPg0KV0cgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpj b3JlQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48 dT5jb3JlQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7Ow0KTmV2aWwgQnJvd25sZWUgJmx0OzwvZm9udD48YSBocmVmPSJtYWlsdG86cmZj LWlzZUByZmMtZWRpdG9yLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll ciBOZXciPjx1PnJmYy1pc2VAcmZjLWVkaXRvci5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJFOiBVc2luZyBk cmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24gdG8gKmVuYWJsZSogcmVzcG9uc2VzPGJy Pg0KJmd0OyBJbXBvcnRhbmNlOiBIaWdoPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQom Z3Q7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyBIaSBFc2tvLCA8 YnI+DQomZ3Q7IFRoZSBleGlzdGluZyB2ZXJzaW9uIC0xNiBoYXMgdGhlIGZvbGxvd2luZyB0ZXh0 IGluIHNlY3Rpb24gMi4xIChwYWdlDQo1KSA6IDxicj4NCiZndDsgJnF1b3Q7VGhlIHNlcnZlciBN VVNUIHNlbmQgYmFjayByZXNwb25zZXMgb2YgdGhlIGNsYXNzZXMgZm9yIHdoaWNoDQp0aGUgPGJy Pg0KJmd0OyBjbGllbnQgaGFzIG5vdCBleHByZXNzZWQgYW55IGRpcy1pbnRlcmVzdC4mcXVvdDsg PGJyPg0KJmd0OyBTbywgdGhhdCB3YXkgdGhlIGNsaWVudCBoYXMgYWN0dWFsbHkgZXhwcmVzc2Vk IGl0cyBpbnRlcmVzdCAob3IgPGJyPg0KJmd0OyByZXF1ZXN0IGZvciBlbmFibGVtZW50KSBpbiBh bGwgdGhlIHJlc3BvbnNlcyBmb3Igd2hpY2ggaXQgaGFzIG5vdA0KPGJyPg0KJmd0OyBleHByZXNz ZWQgZXhwbGljaXQgZGlzaW50ZXJlc3QuIERvZXMgdGhhdCBoZWxwIHRvIGNvbnRyb2wgdGhlIDxi cj4NCiZndDsgc3BlY2lhbCBzZXJ2ZXItc2lkZSBiZWhhdmlvdXIgYXMgdGhlIHNlcnZlciBrbm93 cyB3aGljaCBhbGwgPGJyPg0KJmd0OyByZXNwb25zZXMgdGhlIGNsaWVudCBpcyBpbnRlcmVzdGVk IGluIGFuZCBpdCBNVVNUIHNlbmQgYSByZXNwb25zZQ0KPGJyPg0KJmd0OyBiYWNrID8gSSBzaGFs bCBzdWJtaXQgYW5vdGhlciB2ZXJzaW9uIHdpdGggc29tZSBlZGl0b3JpYWwgY2hhbmdlcw0KPGJy Pg0KJmd0OyBiZWZvcmUgdGhlIGRyYWZ0IGdvZXMgdG8gSUVTRy4gU28gd2UgaGF2ZSBzb21lIG1v cmUgcm9vbSBmb3IgPGJyPg0KJmd0OyBtb2RpZmljYXRpb24uIElmIHlvdSBoYXZlIHNvbWUgY29t bWVudHMgb24gdGhpcyBpbiB0aGUgbGluZSBvZiB0aGUNCjxicj4NCiZndDsgZGlzY3Vzc2lvbiB3 ZSBhcmUgaGF2aW5nLCBwbGVhc2UgbGV0IHVzIGtub3cuIEkgc2hhbGwgd2FpdCBmb3IgeW91cg0K PGJyPg0KJmd0OyB2aWV3cyBiZWZvcmUgc3VibWl0dGluZyB0aGUgdXBkYXRlZCB2ZXJzaW9uLiA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQW55d2F5LCBhIHNlcGFyYXRlIGRyYWZ0IChvciwgcG9zc2li bHksIGFuIHVwZGF0ZWQgZ3JvdXBjb21tIFJGQz8pDQo8YnI+DQomZ3Q7IGlzIGEgZ29vZCBpZGVh LiBOby1SZXNwb25zZSBhc3N1bWVzIHRoZSB1c3VhbCByZXF1ZXN0L3Jlc3BvbnNlIDxicj4NCiZn dDsgc3ltYW50aWNzIGFuZCBpdCBtYWlubHkgYWRkcmVzc2VzIHRoZSBjbGllbnQgc2lkZSBiZWhh dmlvdXIgYW5kIDxicj4NCiZndDsgaXNzdWVzLiBDb25zaWRlcmluZyBzdWNoIHNwZWNpYWwgYmVo YXZpb3VyIG9mIGdyb3VwY29tbSBzZXJ2ZXJzLCBpdA0KPGJyPg0KJmd0OyB3b3VsZCBiZSBnb29k IHRvIGhhbmRsZSBzZXBhcmF0ZWx5LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2FpdGluZyB0byBo ZWFyIGZyb20geW91LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkczxicj4NCiZndDsgQWJo aWphbiBCaGF0dGFjaGFyeXlhPGJyPg0KJmd0OyBBc3NvY2lhdGUgQ29uc3VsdGFudDxicj4NCiZn dDsgU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQomZ3Q7IFRh dGEgQ29uc3VsdGFuY3kgU2VydmljZXM8YnI+DQomZ3Q7IE1haWx0bzogPC9mb250PjxhIGhyZWY9 bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyBX ZWJzaXRlOiA8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LnRjcy5jb20vPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5odHRwOi8vd3d3LnRjcy5jb208L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEV4cGVyaWVu Y2UgY2VydGFpbnR5LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJVCBTZXJ2aWNlczxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7QnVzaW5lc3MgU29sdXRpb25zPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZxdW90O0RpamssIEVza28mcXVvdDsgJmx0OzwvZm9udD48YSBocmVm PW1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQ291cmllciBOZXciPjx1PmVza28uZGlqa0BwaGlsaXBzLmNvbTwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ow0Kd3JvdGUgb24gMDUvMDIvMjAxNiAw MzoxMDoyNCBBTTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBGcm9tOiAmcXVvdDtEaWprLCBF c2tvJnF1b3Q7ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29t Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5lc2tvLmRpamtA cGhpbGlwcy5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZndDsNCjxicj4NCiZndDsgJmd0OyBUbzogQWJoaWphbiBCaGF0dGFjaGFyeXlhICZsdDs8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmFiaGlqYW4uYmhhdHRhY2hhcnl5 YUB0Y3MuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7DQo8YnI+DQomZ3Q7ICZndDsgQ2M6ICZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzpjb3Jl QGlldGYub3JnJTIwV0c+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXci Pjx1PmNvcmVAaWV0Zi5vcmcNCldHPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4mcXVvdDsgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpjb3JlQGlldGYub3Jn Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5jb3JlQGlldGYu b3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7LA0K TmV2aWwgQnJvd25sZWUgJmx0O3JmYy1pc2VAcmZjLTxicj4NCiZndDsgJmd0OyBlZGl0b3Iub3Jn Jmd0OyA8YnI+DQomZ3Q7ICZndDsgRGF0ZTogMDUvMDIvMjAxNiAwMzoxMCBBTSA8YnI+DQomZ3Q7 ICZndDsgU3ViamVjdDogUkU6IFVzaW5nIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlv biB0byAqZW5hYmxlKg0KcmVzcG9uc2VzIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg SGVsbG8gQWJoaWphbiwgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBNYW5kYXRpbmcgc3VjaCBzZXJ2ZXIgYmVoYXZpb3VyIGZyb20gdGhlIGNsaWVudCBzaWRlIHdp bGwNCmJlIGEgYml0PGJyPg0KJmd0OyAmZ3Q7IG91dC1vZi1zeW5jIHdpdGggdGhlIHNwaXJpdCBv ZiB0aGUgc3BlY2lmaWNhdGlvbi4gPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgaXMgbm90IGZ1bGx5IGNs ZWFyIHRvIG1lIHlldCDigKYgdGhlIGNsaWVudCBkb2VzIG5vdCBtYW5kYXRlDQo8YnI+DQomZ3Q7 ICZndDsgYW55dGhpbmcgZnJvbSB0aGUgc2VydmVyOyBpdCBqdXN0IGV4cHJlc3NlcyBpdHMgaW50 ZXJlc3QgKDAtYml0cykNCjxicj4NCiZndDsgJmd0OyBhbmQgZGlzaW50ZXJlc3QgKDEtYml0cyku IFRoZSBzZXJ2ZXIgY2FuIGFsd2F5cyBub3QgcGFyc2UgdGhlDQpvcHRpb248YnI+DQomZ3Q7ICZn dDsgKGVsZWN0aXZlKSBvciBjaG9vc2Ugbm90IHRvIGJvdGhlciBhYm91dCBpdC4gPGJyPg0KJmd0 OyAmZ3Q7IFRoaXMgZG9lcyBrZWVwIHRoZSBjbGllbnQgd2FpdGluZyBmb3IgYSBwb3NzaWJsZSBy ZXNwb25zZSB0aGF0DQpuZXZlcjxicj4NCiZndDsgJmd0OyBjb21lczsgYnV0IHRoYXQgaXMgdGhl IHNhbWUgaW4gdGhlIGdlbmVyYWwgbXVsdGljYXN0IGNhc2UgOiB0aGUNCjxicj4NCiZndDsgJmd0 OyBjbGllbnQgY2FuIG5ldmVyIGtub3cgaWYgb3Igd2hlbiBhIHJlc3BvbnNlIHdpbGwgY29tZSwg dGhlIHNlcnZlcg0KPGJyPg0KJmd0OyAmZ3Q7IE1BWSBhbHdheXMgY2hvb3NlIHRvIG5vdCByZXNw b25kLiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBTbyB3aGF0IEkgcHJv cG9zZSBpcyB0byB1c2UgdGhlICZxdW90O2luZGljYXRpb24gb2YgaW50ZXJlc3QmcXVvdDsNCnRv IHNwZWNpZmljPGJyPg0KJmd0OyAmZ3Q7IHJlc3BvbnNlIGNsYXNzZXMgaW4gYSBuZXcgd2F5OyBu YW1lbHkgdG8gZW5hYmxlIGNlcnRhaW4gcmVzcG9uc2UNCjxicj4NCiZndDsgJmd0OyBjbGFzc2Vz IHRoYXQgYXJlIHN1cHByZXNzZWQgYnkgZGVmYXVsdC4gJm5ic3A7SXQganVzdCBoYXBwZW5zDQp0 aGF0IHRoZSA8YnI+DQomZ3Q7ICZndDsgc2FtZSBPcHRpb24gc3ludGF4IGlzIHZlcnkgd2VsbCBz dWl0ZWQgZm9yIHRoYXQgcHVycG9zZS4gQSBzZXBhcmF0ZQ0KPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0 IGNvdWxkIGJlIHdyaXR0ZW4gZm9yIHRoYXQgcGVyaGFwcyBpZiB5b3UgdGhpbmsgaXQgZG9lcw0K bm90IGZpdDxicj4NCiZndDsgJmd0OyBpbiBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRp b24gb3IgaWYgaXQgaXMgdG9vIGxhdGUgZm9yDQp0aGF0LiA8YnI+DQomZ3Q7ICZndDsgVGhlIHdl IGNhbiBwb2ludCB0byB0aGUgc3ludGF4IG9mIHRoZSBOby1SZXNwb25zZSBPcHRpb24gYW5kDQpy ZS11c2UgPGJyPg0KJmd0OyAmZ3Q7IGl0IGNvbXBsZXRlbHkuIDxicj4NCiZndDsgJmd0OyAmbmJz cDsgPGJyPg0KJmd0OyAmZ3Q7IHJlZ2FyZHMgPGJyPg0KJmd0OyAmZ3Q7IEVza28gPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogQWJoaWphbiBCaGF0dGFjaGFyeXlh IFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1haWx0bzphYmhpamFu LmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+XQ0KPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IEZyaWRheSwgQXByaWwgMjIsIDIw MTYgMTc6MTc8YnI+DQomZ3Q7ICZndDsgVG86IERpamssIEVza28gJmx0OzwvZm9udD48YSBocmVm PW1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQ291cmllciBOZXciPjx1PmVza28uZGlqa0BwaGlsaXBzLmNvbTwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ozxicj4NCiZndDsgJmd0OyBDYzogPC9m b250PjxhIGhyZWY9bWFpbHRvOmNvcmVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iQ291cmllciBOZXciPjx1PmNvcmVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPg0KV0cgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpj b3JlQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48 dT5jb3JlQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7Ow0KTmV2aWwgQnJvd25sZWUgJmx0OzwvZm9udD48YSBocmVmPSJtYWlsdG86cmZj LWlzZUByZmMtZWRpdG9yLm9yZyUwYiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291 cmllciBOZXciPjx1PnJmYy1pc2VAcmZjLWVkaXRvci5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBT dWJqZWN0OiBSZTogVXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uIHRvICpl bmFibGUqDQpyZXNwb25zZXMgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg SGkgRXNrbywgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyBmb3IgeW91ciBtYWlsLiA8YnI+DQomZ3Q7 ICZndDsgRmlyc3Qgb2YgYWxsIGxldCBtZSBqdXN0IGJyaW5nIHRoaXMgdG8geW91ciAoYXMgd2Vs bCBhcyB0aGUgbWFpbGluZw0KPGJyPg0KJmd0OyAmZ3Q7IGxpc3Qncykgbm90aWNlIHRoYXQgdGhl IGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpczogJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Ut Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLTwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyBv cHRpb24tMTYudHh0PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGlzIHZlcnNpb24g JnF1b3Q7b2ZmaWNpYWxseSZxdW90OyBjbG9zZXMgdGhlIHRlY2huaWNhbCByZXZpZXdzDQphbmQg aXMgd2l0aCA8YnI+DQomZ3Q7ICZndDsgdGhlIFJGQyBlZGl0b3IgdGhyb3VnaCB0aGUgSVMgdHJh Y2suIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTm93IGNvbWluZyB0byB5b3VyIHVz ZSBjYXNlIChhbmQgaW5kZWVkIGl0IGlzIGFuIGludGVyZXN0aW5nDQpvbmUpIDxicj4NCiZndDsg Jmd0OyBvbmUgdGhpbmcgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgaXMgdGhhdCB0aGUgTm8tUmVz cG9uc2Ugb3B0aW9uDQp3YXM8YnI+DQomZ3Q7ICZndDsgZGVsaWJlcmF0ZWx5IGRlc2lnbmVkIG5v dCB0byBtYW5kYXRlIGFueXRoaW5nIGZvciB0aGUgc2VydmVyDQpzaWRlIDxicj4NCiZndDsgJmd0 OyBtYWlubHkgdG8gZW5zdXJlIHRoYXQgaXQgZG9lcyBub3QgZGlzcnVwdCB0aGUgbWFueSB1c2Vm dWxuZXNzDQpvZiB0aGU8YnI+DQomZ3Q7ICZndDsgdXN1YWwgcmVxdWVzdC9yZXNwb25zZSBzeW1h bnRpY3MuIFRoZSBkcmFmdCBhbGwgYWxvbmcgZGVhbHMgd2l0aA0KdGhlPGJyPg0KJmd0OyAmZ3Q7 IHJlcXVlc3RpbmcgY2xpZW50J3MgYmVoYXZpb3VyIGFuZCBpdHMgZXhwcmVzc2lvbiBvZiBpbnRl cmVzdA0KdG8gdGhlIDxicj4NCiZndDsgJmd0OyBzZXJ2ZXIuIFNpbmNlIHRoaXMgb3B0aW9uIGlz IGVsZWN0aXZlIHdlIGxlYXZlIGl0IHVwdG8gdGhlIHNlcnZlcg0KPGJyPg0KJmd0OyAmZ3Q7IGlt cGxlbWVudGF0aW9uIHRvIGhvbm91ciB0aGUgY2xpZW50J3MgaW50ZXJlc3QuIDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgTm93LCBhcyBwZXIgdXN1YWwgcmVxdWVzdC9yZXNwb25zZSBz eW1hbnRpY3MgdGhlIHJlc3BvbnNlcyBhcmUNCjxicj4NCiZndDsgJmd0OyBhbHdheXMgZW5hYmxl ZC4gVGhlIGJlaGF2aW91ciBpbiBncm91cGNvbW0gc2VydmVyIGluIHRlcm1zIG9mDQo8YnI+DQom Z3Q7ICZndDsgc3VwcHJlc3NpbmcgdGhlIHJlc3BvbnNlcyBvbiBpdHMgb3duIGlzIHNvbWV0aGlu ZyBzcGVjaWFsIGFuZCwNCjxicj4NCiZndDsgJmd0OyBnZW5lcmFsbHkgc3BlYWtpbmcsIHRoZSBj bGllbnRzIGFyZSBub3QgYXdhcmUgb2Ygc3VjaCBzcGVjaWFsDQpiZWhhdmlvdXIuICZuYnNwOyA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNvLCBpdCB3b3VsZCBiZSBqdXN0aWZpZWQg dG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gYXQgdGhlIHNlcnZlcidzDQo8YnI+DQomZ3Q7ICZndDsg ZW5kLiBIZXJlIGlzIHRoZSBpZGVhOiA8YnI+DQomZ3Q7ICZndDsgV2hpbGUgTm8tUmVzcG9uc2Ug aXMgdG8gZXhwcmVzc2VzIGNsaWVudCdzIGRpcy1pbnRlcmVzdCBpbiBzb21lDQpvciA8YnI+DQom Z3Q7ICZndDsgYWxsIG9mIHRoZSByZXNwb25zZXMgZGVwZW5kaW5nIG9uIHRoZSBvcHRpb24gdmFs dWUsIGl0IGlzIGFsc28NCnRydWUgPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgdGhlIG9wdGlvbiBhdXRv bWF0aWNhbGx5IGV4cHJlc3NlcyBpbnRlcmVzdCBpbiBhbGwgb3RoZXINCjxicj4NCiZndDsgJmd0 OyByZXNwb25zZXMgKG1hcmtlZCBieSAwJ3MgaW4gdGhlIHJlc3BlY3RpdmUgcG9zaXRpb25zKS4g VGhlIGNsaWVudA0KaXM8YnI+DQomZ3Q7ICZndDsgZ29pbmcgdG8gd2FpdCBmb3IgdGhlc2UgcmVz cG9uc2VzIHVwdG8gYSBnaXZlbiB0aW1lb3V0LiBOb3csDQppZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7 IHNlcnZlciBiZWhhdmlvdXIgaXMgbW9kaWZpZWQgbGlrZSB0aGlzIDogJnF1b3Q7SSBoYXZlIGNs b3NlZA0KbXkgZG9vciBmb3IgPGJyPg0KJmd0OyAmZ3Q7IGFsbCBvdXQgZ29pbmcgcmVzcG9uc2Uu ICoqQlVUKiosIGlmIEkgc2VlIGEgZmVsbG93IHJlcXVlc3RpbmcNCndpdGggPGJyPg0KJmd0OyAm Z3Q7IE5vLVJlc3BvbnNlIGFuZCBrZWVwaW5nIHdpbmRvd3Mgb3BlbiB0byBzb21lIHJlc3BvbnNl cyB0aGVuIEkNCmFzc3VtZTxicj4NCiZndDsgJmd0OyB0aGF0IHRoaXMgZ3V5IHJlYWxseSBuZWVk cyB0aG9zZSBraW5kIG9mIHJlc3BvbnNlcy4gSW4gdGhhdCBjYXNlDQpsZXQ8YnI+DQomZ3Q7ICZn dDsgbWUgYmUgbGluaWVudCBhbmQgbGV0IG1lIG9wZW4gdGhlIGRvb3IgZm9yIHN1Y2ggcmVzcG9u c2VzLiBUaGlzDQo8YnI+DQomZ3Q7ICZndDsgZmVsbG93IG11c3QgYmUgYXZhaWxhYmxlIHRvIGxp c3RlbiB0byB0aGVtIGFzIHBlciB0aGUgcHJlc2NyaWJlZA0KPGJyPg0KJmd0OyAmZ3Q7IGJlaGF2 aW91ciBpbiB0aGUgTm8tUmVzcG9uc2Ugc3BlY2lmaWNhdGlvbi4mcXVvdDsgJm5ic3A7IDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTWFuZGF0aW5nIHN1Y2ggc2VydmVyIGJlaGF2aW91 ciBmcm9tIHRoZSBjbGllbnQgc2lkZSB3aWxsIGJlDQphIGJpdCA8YnI+DQomZ3Q7ICZndDsgb3V0 LW9mLXN5bmMgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLiA8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFJlZ2FyZHM8YnI+DQomZ3Q7ICZndDsgQWJoaWphbiBCaGF0 dGFjaGFyeXlhPGJyPg0KJmd0OyAmZ3Q7IEFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KJmd0OyAm Z3Q7IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhPGJyPg0KJmd0OyAm Z3Q7IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXM8YnI+DQomZ3Q7ICZndDsgTWFpbHRvOiA8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmFiaGlqYW4uYmhhdHRhY2hhcnl5 YUB0Y3MuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQomZ3Q7ICZndDsgV2Vic2l0ZTogPC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy50Y3MuY29t Lz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cDovL3d3 dy50Y3MuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsgRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBGcm9tOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtEaWprLCBFc2tvJnF1b3Q7ICZsdDs8L2ZvbnQ+ PGEgaHJlZj1tYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5lc2tvLmRpamtAcGhpbGlwcy5jb208L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsNCjxicj4NCiZndDsgJmd0 OyBUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWJoaWphbiBCaGF0dGFjaGFyeXlhICZs dDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmFiaGlqYW4uYmhhdHRh Y2hhcnl5YUB0Y3MuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgQ2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O05ldmlsIEJyb3dubGVlICZsdDs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnJmYy1pc2VAcmZjLWVk aXRvci5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5y ZmMtaXNlQHJmYy1lZGl0b3Iub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7LA0KJnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOmNvcmVAaWV0Zi5v cmclMjBXRz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+Y29y ZUBpZXRmLm9yZw0KV0c8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPiZxdW90OyAmbHQ7PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48YSBocmVmPW1haWx0bzpjb3Jl QGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5j b3JlQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgRGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 MDQvMjIvMjAxNiAwNTo0MyBQTSA8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7VXNpbmcgZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uDQp0 byA8YnI+DQomZ3Q7ICplbmFibGUqIHJlc3BvbnNlcyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhl bGxvIEFiaGlqYW4sPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBpbiBvdXIgcHJvamVj dCB3ZSBzZWUgYSBjbGVhciB1c2UgY2FzZSBvZiB1c2luZyB0aGUgTm8tUmVzcG9uc2UNCjxicj4N CiZndDsgJmd0OyBPcHRpb24gdG8gKmVuYWJsZSogY2VydGFpbiByZXNwb25zZXMgdGhhdCBhcmUg YnkgZGVmYXVsdCBzdXBwcmVzc2VkLjxicj4NCiZndDsgJmd0OyBDb0FQIGFsbG93cyBzdXBwcmVz c2lvbiBvZiBtdWx0aWNhc3QgcmVzcG9uc2VzIGJ5IGRlZmF1bHQsIHdoaWNoDQppcyA8YnI+DQom Z3Q7ICZndDsgd2hhdCB3ZSB1c2UgZm9yIGEgbGlnaHRpbmcgbXVsdGljYXN0IHVzZSBjYXNlLiBI b3dldmVyIGZvciA8YnI+DQomZ3Q7ICZndDsgZGlhZ25vc3RpYyB1c2FnZSB3ZSdkIGxpa2UgdG8g ZW5hYmxlIHRoZXNlIHJlc3BvbnNlcyBhZ2FpbiB1c2luZw0KdGhlPGJyPg0KJmd0OyAmZ3Q7IE5v LVJlc3BvbnNlIG9wdGlvbiB3aGljaCBpcyBwZXJmZWN0bHkgc3VpdGVkIGZvciB0aGF0LiBIb3dl dmVyLA0KdGhlIDxicj4NCiZndDsgJmd0OyBkcmFmdCB0ZXh0IGN1cnJlbnRseSBvbmx5IHRhbGtz IGFib3V0IHN1cHByZXNzaW5nIHJlc3BvbnNlcyAobm90DQplbmFibGluZykuPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBIZW5jZSBteSByZXF1ZXN0OiBjb3VsZCB3ZSBtb2RpZnkvYWRk IHNvbWUgdGV4dCB0byBzaG93IHRoYXQNCmFsc28gPGJyPg0KJmd0OyAmZ3Q7IHRoZSBvcHRpb24g Y2FuIGJlIHVzZWQgdG8gZW5hYmxlIHJlc3BvbnNlcyBpbiBjYXNlIHdoZXJlIHRoZXkNCmFyZSA8 YnI+DQomZ3Q7ICZndDsgbm9ybWFsbHkgKGJ5IGRlZmF1bHQgLS0gc2VydmVyIGRlY2lzaW9uKSBz dXBwcmVzc2VkPzxicj4NCiZndDsgJmd0OyBKdXN0IHRvIGNsYXJpZnkgc3VjaCB1c2FnZTsgd2hp Y2ggaXMgcXVpdGUgdXNlZnVsIGluIG15IHZpZXcuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyByZWdhcmRzPGJyPg0KJmd0OyAmZ3Q7IEVza288YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRp YWwNCmFuZCA8YnI+DQomZ3Q7ICZndDsgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJs ZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkDQo8YnI+DQomZ3Q7ICZndDsgc29sZWx5IGZv ciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LA0KPGJyPg0KJmd0OyAmZ3Q7IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwg Zm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwNCm9yIDxicj4NCiZndDsgJmd0OyByZXByb2R1Y3Rp b24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQ0KPGJy Pg0KJmd0OyAmZ3Q7IHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2UgY29udGFjdA0KdGhlIDxicj4NCiZndDsgJmd0OyBzZW5kZXIgYnkgcmV0dXJu IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbA0KbWVzc2FnZS4g PGJyPg0KJmd0OyAmZ3Q7ID09PT09LS0tLS09PT09PS0tLS0tPT09PT08YnI+DQomZ3Q7ICZndDsg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsPGJyPg0KJmd0 OyAmZ3Q7IG1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIDxicj4N CiZndDsgJmd0OyBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91 IGFyZSA8YnI+DQomZ3Q7ICZndDsgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNz ZW1pbmF0aW9uLCB1c2UsIDxicj4NCiZndDsgJmd0OyByZXZpZXcsIGRpc3RyaWJ1dGlvbiwgcHJp bnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIDxicj4NCiZndDsgJmd0OyBhbmQvb3IgYXR0YWNo bWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIDxicj4NCiZndDsgJmd0OyB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDxicj4NCiZndDsg Jmd0OyBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIDxi cj4NCiZndDsgJmd0OyBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNz YWdlIDxicj4NCiZndDsgJmd0OyBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdl IG1heSBiZSBjb25maWRlbnRpYWwgYW5kDQo8YnI+DQomZ3Q7IGxlZ2FsbHkgcHJvdGVjdGVkIHVu ZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCA8YnI+DQomZ3Q7IHNv bGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwNCjxicj4NCiZndDsgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNl LCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvcg0KPGJyPg0KJmd0OyByZXByb2R1Y3Rpb24g b2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSA8YnI+DQom Z3Q7IHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgY29udGFjdCB0aGUNCjxicj4NCiZndDsgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRl c3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS48L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+PGJy Pg0KPC9mb250Pg0KPGhyPjxmb250IHNpemU9MSBjb2xvcj0jODA4MDgwIGZhY2U9IkFyaWFsIj5U aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVu dGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZQ0KbGF3LiBUaGUgbWVz c2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUg bm90DQp0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSB1c2UsIGZvcndhcmRpbmcsDQpkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2Yg dGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kDQptYXkgYmUgdW5sYXdmdWwu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0DQp0 aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUg b3JpZ2luYWwgbWVzc2FnZS48L2ZvbnQ+DQo8cD4NCg== --=_alternative 0019F30665257FA9_=-- From nobody Thu May 5 01:52:04 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE7612B043 for ; Thu, 5 May 2016 01:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm7KTUY0k98S for ; Thu, 5 May 2016 01:52:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C8012B038 for ; Thu, 5 May 2016 01:52:01 -0700 (PDT) Received: from [192.168.10.140] ([213.210.38.194]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lz3rc-1bktZz15zU-014F4Z; Thu, 05 May 2016 10:51:47 +0200 To: weigengyu , trac+core@zinfandel.tools.ietf.org, draft-ietf-core-block@tools.ietf.org References: <065.865b9837ab99aed6c309ae6125f98820@trac.tools.ietf.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <572B099D.2080606@gmx.net> Date: Thu, 5 May 2016 10:51:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LBtXP9exEtRhWvEaio4qGFvBGSoLxRvdX" X-Provags-ID: V03:K0:bUahsiYLO5wAkbetY6WLEVuwIF5qvR5e0vt9Ixn18/xDfyKMH62 YAcrqmoSmK5OQLFGcqnZGsDsgAQ8rX7XTpwJ/rsfPYl7HYIkktkItApP8Y1nktXR1zSOqV2 HBchUSghHbN2+hx/JB4BDP+kBZ2+Fo3yA9i7v5+/R/kdQ00NLarFwuxDdEz7PlnU96acEyA B7XeGP0sRXRB615j42qfg== X-UI-Out-Filterresults: notjunk:1;V01:K0:MLFjyj9xFBQ=:XGygBIPpLTDcZJt8gIrX7U MaRTXYHdBA3ywP/EUnlG0wmckscNZNdSMKCJ/Lq2vkhZHyfWjXQJURZXmJM+VZNvWE4ADPB4c lz5vTJZ8cGqPbH50DS/b/d0OVvM6DCgdnbtg9cos/FB/5ScRNzmDfrTW7yFXLcWVOEAaxAdu/ /9Qj0md3h9gm8P8h+8qyrvR/LN87ArwFb1DXk7om5bvWdIEsoVc9nCTfbsUW+GkU5hs7FYWDK 6CEmcqt6iZHzrzDA634GqTWF6i1XzGuCtJIMRmBmXVc9vJLOGebIBxVDNf9IEZmzAc3TIBsUP oqLNAWgrs2T7KqxunXGctBGzhx4VOD8Kc49Tlwt5DHhFx6pL97gcKYcfCk8O7NgJxbGSRxDzu fvWb5Fp+58sdicU0S7ynvwlo6EP1Hgec5r3aCizYWM2LxnHL+l4JK6YCeG4iDCjfwwdmue+PD u8qfdGyYXVqz2UkxC8TZgZyWGmd3fJSqfrntCDtb1RhJRu76aVfAEg2z8hB+cbCkeL74TfFjY rgoyoLYJ+PNmq2AbERyD02dBhk0SDnTl2oQcFzYnPpDUgalUVeR/ZDLEehj0oMV9wsQv//iZZ 1jYG5vJ130icGkn3OGqBpGTwaxPMGKwz+fCPkCwOR8TWtfmsrukCgQyafB2W0rqwaVm7yj5Rn 9mHk5ywFFM1SlQRJw3+pjZ3GyjL70K7qXwfSXILglYtwHh77Q3MmoWl9YPt/AN6czj9BEpigl b06jXYf2x7Wl6zJXZa+Ch9bSU+6UWrFI8UwHUgxMocmMJ54JlI3fkhD/hwE= Archived-At: Cc: core@ietf.org Subject: Re: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP Connections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 05 May 2016 08:52:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LBtXP9exEtRhWvEaio4qGFvBGSoLxRvdX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Gengyu, thanks for your input. In the issue I added to the tracker I raised two issues, namely 1) "What should the CoAP over TCP state regarding the use of multiple TCP connections?" It seems you are arguing that nothing should be said about that topic. 2) "Should we recommend the use of Block-wise Transfer for large file transfers and incorporate BERT into the CoAP over TCP draft?" You didn't directly answer that question and I am curious what your thoughts are. Ciao Hannes On 05/04/2016 05:18 AM, weigengyu wrote: > Hi, >=20 > The problem seems to be whether CoAP over Multiple Simultaneous TCP > Connections needs considering in CoAP related drafts. >=20 > My suggestion is no. >=20 > There are many P2P communications adopts P2P/HTTP over Multiple > Simultaneous TCP Connections. > It is the P2P software to manage the multiple TCP connections, not HTTP= =2E >=20 > Regards, >=20 > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: core issue tracker= > Sent: Tuesday, May 03, 2016 4:39 PM > To: draft-ietf-core-block@tools.ietf.org ; Hannes.Tschofenig@gmx.net > Cc: core@ietf.org > Subject: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP > Connections >=20 > #409: CoAP over TCP: Multiple Simultaneous TCP Connections >=20 > CoAP has been designed to support small data transmissions. For device > management it is, however, necessary to also deal with the transmission= of > larger payloads as well. Such larger payloads may be, for example, > firmware/software updates. >=20 > The maximum payload size of CoAP is determined by the length field of t= he > length field provided in the UDP header. It is ~64KB. For practical > purposes the usable payload size is, however, much smaller due to > performance issues introduced by fragmentation provided at the IP layer= > and/or adaption layers. For this reason the block-wise transfer mechani= sm > has been defined. >=20 > Block-wise transfer is a mechanism that can be used to transfer larger > payloads by chunking them into smaller parts (each part with a maximum > size of 1024 bytes each). The block-wise transfer depends on CoAP and > therefore uses the stop-and-wait defined in RFC 7252 (as a simple > congestion control mechanism). The transfer of large payloads does, > however, not block the transmission of other pending messages since the= y > can easily be interleaved due to the nature of the block-wise transfer > design. >=20 > When large payloads are transferred by CoAP over TCP then a large trans= fer > blocks any other requests unless multiple TCP connections are opened. T= he > question is therefore what should the CoAP over TCP state regarding the= > use of multiple TCP connections? Using multiple TCP connection increase= s > RAM requirements; a single TCP connection introduces head-of-line > blocking. >=20 > When CoAP over TCP is used with Block-wise transport in combination wit= h > BERT, see https://tools.ietf.org/html/draft-bormann-core-block-bert-00,= > then the previously described problem of large transfers that block oth= er > ongoing activities is (partially) mitigated. BERT changes the > interpretation of the length information and changes it as a multiple o= f > 1024 bytes (and thus increasing the size of the chunks). >=20 > The question is therefore whether CoAP over TCP should recommend the us= e > of Block-wise Transfer for large file transfers and incorporate BERT in= to > the CoAP over TCP draft. >=20 > (I would like to thank Achim Kraus for raising this issue during the OM= A > face-to-face meeting.) >=20 --LBtXP9exEtRhWvEaio4qGFvBGSoLxRvdX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXKwmdAAoJEGhJURNOOiAtKSoH/iInUlh4+D+EvVfZxubrhYxB yWzHiA+cXtgrf4WoPog8UUcZ1Fsl60ucEiqNJQ0hiJbIlnKpmfcfH/YkfbUrcJtm 7h2XMykdWWefA7ni/OMikHF35OGkjagfFZ3ZP1g5F+Q6XiQR/MEQ/6b5hUZB8bdw bLChlhpCv+3srQkiKPbxcHpe+w23weDEkZGNVFQMV3PrkrauYju/Q1HYzk05C736 rSkYLHkTim3GAvXorrbVDSIGhua5AFW7okeNLz6h20GvPYyRBcYmjHAqRgIXJkC0 cbfHzFWUJHRXS2wIAD6aQqfpLy9veWeL/qcVcJAaqFCvkAxFW+/dq3C6jRC9hW8= =c4+7 -----END PGP SIGNATURE----- --LBtXP9exEtRhWvEaio4qGFvBGSoLxRvdX-- From nobody Fri May 6 06:01:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52DB12D987 for ; Fri, 6 May 2016 06:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dilq2r5zWJ5X for ; Fri, 6 May 2016 06:01:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2836C12D978 for ; Fri, 6 May 2016 06:01:32 -0700 (PDT) Received: from localhost ([::1]:33237 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ayfNq-0004aR-UX; Fri, 06 May 2016 06:01: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.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, achim.kraus@bosch-si.com X-Trac-Project: core Date: Fri, 06 May 2016 13:01:30 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/410 Message-ID: <064.4cbf8d09348a03ec25afdd8a19df82d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 410 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, achim.kraus@bosch-si.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 Resent-To: draft-ietf-core-block@ietf.org Resent-Message-Id: <20160506130132.2836C12D978@ietfa.amsl.com> Resent-Date: Fri, 6 May 2016 06:01:32 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #410 (block): Initial MID on restart after blockwise transfer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.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, 06 May 2016 13:01:41 -0000 #410: Initial MID on restart after blockwise transfer Doing tests on firmware updates using - a blockwise transfer (draft-ietf-core-block-20), - a random initial value of the MID (as recommended in RFC7252, 4.4. last part of implementation note), - I found on restarts short after such a transfer, a rather high probability of MID collision. (This is obvious caused by having rather more MIDs in use, than in normal communication situations). Therefore I would propose to add an implementation note in "draft-ietf- core-block" or/and "draft-ietf-lwig-coap" for proper handling of that situation. On my experience there are two possibilities: a: on graceful shutdown (after blockwise) store the last MID and load it on restart. b: if on restart (after blockwise) communication errors occur, wait for at least EXCHANGE_LIFETIME to escape the “probable” MID collision. This may also be the strategy, when a fails to load the MID for any reason. -- -------------------------------------+------------------------------------- Reporter: achim.kraus@bosch- | Owner: draft-ietf-core- si.com | block@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: Component: block | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: core From nobody Fri May 6 06:03:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8978E12D980 for ; Fri, 6 May 2016 06:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVF-Chg2Uw7c for ; Fri, 6 May 2016 06:03:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A882A12D97B for ; Fri, 6 May 2016 06:03:29 -0700 (PDT) Received: from localhost ([::1]:33317 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ayfPl-0005h0-FI; Fri, 06 May 2016 06:03:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, achim.kraus@bosch-si.com X-Trac-Project: core Date: Fri, 06 May 2016 13:03:29 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/410#comment:1 Message-ID: <079.91253355a6c5469f216ec0c7fd810306@trac.tools.ietf.org> References: <064.4cbf8d09348a03ec25afdd8a19df82d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 410 In-Reply-To: <064.4cbf8d09348a03ec25afdd8a19df82d0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, achim.kraus@bosch-si.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 Resent-To: draft-ietf-core-block@ietf.org Resent-Message-Id: <20160506130329.A882A12D97B@ietfa.amsl.com> Resent-Date: Fri, 6 May 2016 06:03:29 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #410 (block): Initial MID on restart after blockwise transfer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.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, 06 May 2016 13:03:32 -0000 #410: Initial MID on restart after blockwise transfer Comment (by achim.kraus@bosch-si.com): I hope "new editorial" is the right one :-). Otherwise feel free to change that. -- -------------------------------------+------------------------------------- Reporter: achim.kraus@bosch- | Owner: draft-ietf-core- si.com | block@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: Component: block | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: core From nobody Fri May 6 06:48:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A1012D5C5 for ; Fri, 6 May 2016 06:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTI5nvahBfrC for ; Fri, 6 May 2016 06:47:58 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4033312D55C for ; Fri, 6 May 2016 06:47:57 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-64-572ca08b699c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.31.12516.B80AC275; Fri, 6 May 2016 15:47:56 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.203]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Fri, 6 May 2016 15:47:55 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXZhbmRlcnN0b2st?= =?utf-8?Q?core-etch-00?= Thread-Index: AQHRp53kAQvIfiNdakWUKcqq8bChQg== Date: Fri, 6 May 2016 13:47:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <01A599CD0CBAFE40AAC9E5721CB52316@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbE9SrdngU64QWMru8W+t+uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXDqO6aCE1wVG+6vYWpgXMLVxcjJISFgItHS+YAFwhaTuHBv PVsXIxeHkMARRom311YzQziLGSW+/GhjA6liE3CW+PSskR3EFhFQlth85jUjiC0sUCDx5+UE qHihxJEl56BsPYnVix6B1bAIqEic6D3HCmLzCthL9O7YBBYXArI7ml8C1XNwcAo4SPzokgcJ MwId9P3UGiYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSSx6PZnJpAxzAKaEut36UO0 Wkus/DeDGcJWlJjS/ZAd4gJBiZMzn7BMYBSbhWTDLITuWUi6ZyHpnoWkewEj6ypG0eLU4uLc dCNjvdSizOTi4vw8vbzUkk2MwPg5uOW37g7G1a8dDzEKcDAq8fAu+KUdLsSaWFZcmXuIUYKD WUmE9/xcnXAh3pTEyqrUovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFIN jFqVr5TM4lcLLfx+1+2DU7WU/p6nTmt1e091z3S68E3OvkOQryRok/taV9f+aWHNmbU+h7WT Z6uvD/hUHnPw9tULJQ7clzLEw45fCFh6I3+yfeOnzKg0m8JZbseCrkXt7zpycZLcp4/HTKbs fb+psoy3XHQD3y2lzTtNs2dYB9TPLf5w4MvmMCWW4oxEQy3mouJEAOPlRLebAgAA Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-vanderstok-cor?= =?utf-8?q?e-etch-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 13:48:00 -0000 SGkgYWxsLA0KDQpUaGVyZSBzZWVtcyB0byBiZSBubyBvYmplY3Rpb25zIHRvIHRoZSBpbi1yb29t IGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIGRvY3VtZW50Lg0KDQpBdXRob3JzOiBQbGVhc2UgcmVz dWJtaXQgdGhlIGRyYWZ0IGFzIGRyYWZ0LWlldGYtY29yZS1ldGNoLTAwLg0KDQpDaWFvIQ0KLSAt IEphaW1lIEppbWVuZXoNCg0KPiBPbiAyOCBBcHIgMjAxNiwgYXQgMTc6MDUsIEphaW1lIEppbcOp bmV6IDxqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBhbGwsDQo+ IA0KPiBnb2luZyB0aHJvdWdoIHRoZSBpdGVtIGxpc3QsIGluIEJ1ZW5vcyBBaXJlcyB3ZSBkaXNj dXNzZWQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LXZhbmRlcnN0b2stY29yZS1ldGNoLTAwIGFzIFdH IGl0ZW0uIEJhY2sgdGhlbiB0aGVyZSB3YXMgcm9vbSBjb25zZW5zdXMgd2l0aCAxMiBwZW9wbGUg aW4gZmF2b3IgKCsgNCBtb3JlIG9uIHRoZSBqYWJiZXIpIGFuZCBub29uZSBhZ2FpbnN0LiANCj4g DQo+IFRoaXMgd29yayBpcyBuZWVkZWQgaW4gb3JkZXIgdG8ga2VlcCB1c2luZyBQQVRDSCBsaW5r IHVwZGF0ZXMgb24gdGhlIFJEIGFuZCBhbHNvIGZvciB0aGUgQ09NSSB3b3JrIHRoYXQgaGFzIGFs cmVhZHkgYmVlbiBhZG9wdGVkIGFzIG9mIHRoaXMgd2Vlay4gDQo+IA0KPiBUaGlzIGlzIGEgb25l LXdlZWsgY2FsbCBmb3IgY29uZmlybWF0aW9uIG9uIHRoYXQgZGVjaXNpb24sIHNvIGlmIHRoZXJl IGFyZSBvYmplY3Rpb25zIHBsZWFzZSB2b2ljZSB0aGVtIG9uIHRoZSBtYWlsaW5nIGxpc3QgYnkg MjAxNi0wNS0wNi4NCj4gDQo+IENpYW8sDQo+IC0gLSBKYWltZSBKaW1lbmV6DQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxp bmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZQ0KDQo= From nobody Fri May 6 08:52:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9512D0F9 for ; Fri, 6 May 2016 08:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbpaSVIvwXiY for ; Fri, 6 May 2016 08:52:50 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7166012B019 for ; Fri, 6 May 2016 08:52:50 -0700 (PDT) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 0D3BEA80C8; Fri, 6 May 2016 17:52:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id KtNwBWvWUvSt; Fri, 6 May 2016 17:52:46 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A526CA80CD; Fri, 6 May 2016 17:52:44 +0200 (CEST) Message-ID: <572CBDCB.9090000@tzi.org> Date: Fri, 06 May 2016 17:52:43 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: trac+core@zinfandel.tools.ietf.org References: <064.4cbf8d09348a03ec25afdd8a19df82d0@trac.tools.ietf.org> <079.91253355a6c5469f216ec0c7fd810306@trac.tools.ietf.org> In-Reply-To: <079.91253355a6c5469f216ec0c7fd810306@trac.tools.ietf.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@tools.ietf.org, core@ietf.org Subject: Re: [core] #410 (block): Initial MID on restart after blockwise transfer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 15:52:53 -0000 Hi Achim, thank you for this observation! Can you be a bit more specific about the scenario? If I imagine a hub/server doing a firmware upgrade on a node via PUT (as in LWM2M), the selection of the MIDs is on the hub side, which is not the one that gets restarted by the firmware upgrade. So maybe your scenario is one where the node fetches the new firmware from a hub per block-wise GET, then restarts, and then tries to talk to the same hub (using the same port number) right after restart? I think this scenario would make great content for section 2.3 or 3.5 of lwig-coap. I don't think it is really entirely specific to block-wise transfers (the firmware fetch process might just be using another way to do the bulk transfer). (While we are talking about firmware upgrades, here's a pertinent pointer: https://down.dsg.cs.tcd.ie/iotsu/ Just two weeks left before the submission deadline...) Grüße, Carsten From nobody Sat May 7 21:11:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A71412D1E1 for ; Sat, 7 May 2016 21:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh24xtdgu88g for ; Sat, 7 May 2016 21:11:04 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B46212B029 for ; Sat, 7 May 2016 21:11:02 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 0E0A219F3EA for ; Sun, 8 May 2016 12:11:01 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.254.85.28]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id D9B2A19F390; Sun, 8 May 2016 12:11:00 +0800 (HKT) Message-ID: From: "weigengyu" To: , , "Hannes Tschofenig" References: <065.865b9837ab99aed6c309ae6125f98820@trac.tools.ietf.org> <572B099D.2080606@gmx.net> In-Reply-To: <572B099D.2080606@gmx.net> Date: Sun, 8 May 2016 12:11:00 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP Connections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 04:11:06 -0000 Hi Hannes, Ciao Hannes wrote: > Hi Gengyu, > thanks for your input. > In the issue I added to the tracker I raised two issues, namely > 1) "What should the CoAP over TCP state regarding the use of multiple TCP > connections?" > It seems you are arguing that nothing should be said about that topic. My suggestion is that CoAP does not need to touch the issure using mutliple TCP connections. The reason is to refer P2P software in which it is the application software to do this. > 2) "Should we recommend the use of Block-wise Transfer for large file > transfers and incorporate BERT into the CoAP over TCP draft?" Yes. The draft should give statements for this. CoAP over TCP should support CoAP Block-wise Transfer related to RFC7252. > You didn't directly answer that question and I am curious what your > thoughts are. When doing CoAP over TCP, RFC7252 should be considered firstly. If an application tranfers a large data by CoAP/UDP, it should concern the limit of UDP datagram, i.e less than 64KB. Then the data may be delivered by CoAP Block-wise Tranfer. If the size of data is greadter than 64KB, the application should do multiple invocations of CoAP/UDP. If CoAP/TCP is considered, one TCP connection can transfer 64KB data in one window, probably with sevreal segments. The 64KB limitation should be kept for the purpose with consistency to RFC7252, and this limitaion may need clarifying in the draft. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Hannes Tschofenig Sent: Thursday, May 05, 2016 4:51 PM To: weigengyu ; trac+core@zinfandel.tools.ietf.org ; draft-ietf-core-block@tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP Connections From nobody Sun May 8 23:37:50 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFCA12D1D2; Sun, 8 May 2016 23:37:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509063748.17500.36760.idtracker@ietfa.amsl.com> Date: Sun, 08 May 2016 23:37:48 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-etch-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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 2016 06:37:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Patch and Fetch Methods for Constrained Application Protocol (CoAP) Authors : Peter van der Stok Carsten Bormann Anuj Sehgal Filename : draft-ietf-core-etch-00.txt Pages : 16 Date : 2016-05-08 Abstract: The existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource. This does not permit applications to access parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource. This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired. This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of an existing CoAP resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-etch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-etch-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 9 05:46:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B5312B069 for ; Mon, 9 May 2016 05:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuZuO53CSMcG for ; Mon, 9 May 2016 05:46:01 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DD012B038 for ; Mon, 9 May 2016 05:46:00 -0700 (PDT) Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta24.fe.bosch.de (Postfix) with ESMTP id 27416D80204; Mon, 9 May 2016 14:45:57 +0200 (CEST) Received: from imbvw2exc01.bosch-si.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id B74402E40227; Mon, 9 May 2016 14:45:56 +0200 (CEST) Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by imbvw2exc01.bosch-si.com ([::1]) with mapi id 14.03.0279.002; Mon, 9 May 2016 14:45:55 +0200 From: "Kraus Achim (INST/ESY1)" To: Carsten Bormann , "trac+core@zinfandel.tools.ietf.org" Thread-Topic: [core] #410 (block): Initial MID on restart after blockwise transfer Thread-Index: AQHRp5dvDrse8dD2TUSqr2zTL8r+H5+rvqiAgAAvSICABJi9sA== Date: Mon, 9 May 2016 12:45:55 +0000 Message-ID: References: <064.4cbf8d09348a03ec25afdd8a19df82d0@trac.tools.ietf.org> <079.91253355a6c5469f216ec0c7fd810306@trac.tools.ietf.org> <572CBDCB.9090000@tzi.org> In-Reply-To: <572CBDCB.9090000@tzi.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.144.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22310.006 X-TMASE-MatchedRID: B+VEu1exVFdJJDuM6qazTpmug812qIbzwx0jRRxcQfPlY3fh4J0VvjzA K7q1A+IiuGX5AZSrLM1+tcxIlnGhdaiCOW6RkH3YQCg+244Pxtq4IRKvHvCWckdmDSBYfnJRBXb mYqeVw+z2F344+hM7xA6tvAvztRdhoVVi0fhQg53Wmh5xCo4mMCnGh6cFQ6shY8r/ndGdDsXLsL vOp8aQisrfCsxYhUl5cmHAUC91bv1iZyE2UOy4HJGtJGqXJFNbGa8+8BBl2GYS5KhLWFf6k0bNX f9sRezIfG5NkoCquAs6hkzmvV1DhFiz6pt5Pa2rEwyZyuMQ410rtU4v33TxwVHaR5xICCF6TGww xUMNAZS5Nq9Z7+iI4z4lyTZE5tsq5js1tiEJISzf8GJjBXCUiFQQ0EgzIoPRmyiLZetSf8n5kvm j69FXvEl4W8WVUOR/joczmuoPCq3d7bP/BLYr+CrUXimWZk5WvhytpgpcsoMUFaZ79tGu5KTSoF PJBGhd Archived-At: Cc: "draft-ietf-core-block@tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #410 (block): Initial MID on restart after blockwise transfer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 12:46:05 -0000 SGkgQ2Fyc3RlbiwNCg0KPiBDYW4geW91IGJlIGEgYml0IG1vcmUgc3BlY2lmaWMgYWJvdXQgdGhl IHNjZW5hcmlvPw0KDQo+IFNvIG1heWJlIHlvdXIgc2NlbmFyaW8gaXMgb25lIHdoZXJlIHRoZSBu b2RlIGZldGNoZXMgdGhlIG5ldyBmaXJtd2FyZSBmcm9tIGEgaHViIHBlciBibG9jay13aXNlIEdF VCwgdGhlbiByZXN0YXJ0cywgYW5kIHRoZW4gdHJpZXMgdG8gdGFsayB0byB0aGUgc2FtZSBodWIg KHVzaW5nIHRoZSBzYW1lIHBvcnQgbnVtYmVyKSByaWdodCBhZnRlciByZXN0YXJ0Pw0KDQpZZXMs IHlvdXIgcmlnaHQsIHRoYXQncyB0aGUgY2FzZS4gSSB0cmllZCB0byB0ZXN0IGEgIkxXTTJNIEZp cm13YXJlIFVwZGF0ZSIgdXNpbmcgYSAicGFja2FnZSBVUkkiIHBvaW50aW5nIGJhY2sgdG8gdGhl IHNhbWUgTFdNMk0gc2VydmVyLCBzbyB0aGF0IHRoZSBub3RlIHVzZXMgYSBibG9jay13aXNlIChD T04gR0VUIHJlcXVlc3RzKSB0byB0cmFuc2ZlciB0aGUgZmlybXdhcmUuIFNob3J0IGxhdGVyIHRo ZSBub3RlIHRyaWVzIHRvIHJlZ2lzdGVyIGFmdGVyIGEgcmVzdGFydCAoQ09OIFBVVCByZXF1ZXN0 KS4gICANCg0KPiBJIGRvbid0IHRoaW5rIGl0IGlzIHJlYWxseSBlbnRpcmVseSBzcGVjaWZpYyB0 byBibG9jay13aXNlIHRyYW5zZmVycyAodGhlIGZpcm13YXJlIGZldGNoIHByb2Nlc3MgbWlnaHQg anVzdCBiZSB1c2luZyBhbm90aGVyIHdheSB0byBkbyB0aGUgYnVsayB0cmFuc2ZlcikuDQoNCk15 IGludGVudCB0byBtZW50aW9uIHRoZSBibG9jay13aXNlIHRyYW5zZmVyIHdhcywgdGhhdCBpdCAi Y29uc3VtZXMgbmF0dXJhbGx5IG1vcmUgTUlEcyIgdGhlbiDigJx1c3VhbGx5IHRyYWZmaWPigJ0s IGFuZCB0aGVyZWZvcmUgaXTigJlzIG9uZSB0aGUgaW5ncmVkaWVudHMgb2YgdGhlIHNpdHVhdGlv bi4NCg0KTWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbiAvIEJlc3QgcmVnYXJkcw0KDQpBY2hpbSBL cmF1cw0KDQpCb3NjaCBTb2Z0d2FyZSBJbm5vdmF0aW9ucyBHbWJIDQpDb21tdW5pY2F0aW9ucyAo SU5TVC9FU1kxKQ0KU3R1dHRnYXJ0ZXIgU3RyYcOfZSAxMzANCjcxMzMyIFdhaWJsaW5nZW4NCkdF Uk1BTlkNCnd3dy5ib3NjaC1zaS5kZQ0Kd3d3LmJsb2cuYm9zY2gtc2kuY29tIA0KDQphY2hpbS5r cmF1c0Bib3NjaC1zaS5jb20NCg0KUmVnaXN0ZXJlZCBvZmZpY2U6IEJlcmxpbiwgUmVnaXN0ZXIg Y291cnQ6IEFtdHNnZXJpY2h0IENoYXJsb3R0ZW5idXJnLCBIUkIgMTQ4NDExIEINCkV4ZWN1dGl2 ZXM6IERyLi1JbmcuIFJhaW5lciBLYWxsZW5iYWNoOyBNaWNoYWVsIEhhaG4NCg0KDQoNCi0tLS0t VXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogQ2Fyc3RlbiBCb3JtYW5uIFttYWls dG86Y2Fib0B0emkub3JnXSANCkdlc2VuZGV0OiBGcmVpdGFnLCA2LiBNYWkgMjAxNiAxNzo1Mw0K QW46IHRyYWMrY29yZUB6aW5mYW5kZWwudG9vbHMuaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLWNv cmUtYmxvY2tAdG9vbHMuaWV0Zi5vcmc7IEtyYXVzIEFjaGltIChJTlNUL0VTWTEpOyBjb3JlQGll dGYub3JnDQpCZXRyZWZmOiBSZTogW2NvcmVdICM0MTAgKGJsb2NrKTogSW5pdGlhbCBNSUQgb24g cmVzdGFydCBhZnRlciBibG9ja3dpc2UgdHJhbnNmZXINCg0KSGkgQWNoaW0sDQoNCnRoYW5rIHlv dSBmb3IgdGhpcyBvYnNlcnZhdGlvbiENCg0KQ2FuIHlvdSBiZSBhIGJpdCBtb3JlIHNwZWNpZmlj IGFib3V0IHRoZSBzY2VuYXJpbz8NCg0KSWYgSSBpbWFnaW5lIGEgaHViL3NlcnZlciBkb2luZyBh IGZpcm13YXJlIHVwZ3JhZGUgb24gYSBub2RlIHZpYSBQVVQgKGFzIGluIExXTTJNKSwgdGhlIHNl bGVjdGlvbiBvZiB0aGUgTUlEcyBpcyBvbiB0aGUgaHViIHNpZGUsIHdoaWNoIGlzIG5vdCB0aGUg b25lIHRoYXQgZ2V0cyByZXN0YXJ0ZWQgYnkgdGhlIGZpcm13YXJlIHVwZ3JhZGUuDQoNClNvIG1h eWJlIHlvdXIgc2NlbmFyaW8gaXMgb25lIHdoZXJlIHRoZSBub2RlIGZldGNoZXMgdGhlIG5ldyBm aXJtd2FyZSBmcm9tIGEgaHViIHBlciBibG9jay13aXNlIEdFVCwgdGhlbiByZXN0YXJ0cywgYW5k IHRoZW4gdHJpZXMgdG8gdGFsayB0byB0aGUgc2FtZSBodWIgKHVzaW5nIHRoZSBzYW1lIHBvcnQg bnVtYmVyKSByaWdodCBhZnRlciByZXN0YXJ0Pw0KDQpJIHRoaW5rIHRoaXMgc2NlbmFyaW8gd291 bGQgbWFrZSBncmVhdCBjb250ZW50IGZvciBzZWN0aW9uIDIuMyBvciAzLjUgb2YgbHdpZy1jb2Fw LiAgSSBkb24ndCB0aGluayBpdCBpcyByZWFsbHkgZW50aXJlbHkgc3BlY2lmaWMgdG8gYmxvY2st d2lzZSB0cmFuc2ZlcnMgKHRoZSBmaXJtd2FyZSBmZXRjaCBwcm9jZXNzIG1pZ2h0IGp1c3QgYmUg dXNpbmcgYW5vdGhlciB3YXkgdG8gZG8gdGhlIGJ1bGsgdHJhbnNmZXIpLg0KDQooV2hpbGUgd2Ug YXJlIHRhbGtpbmcgYWJvdXQgZmlybXdhcmUgdXBncmFkZXMsIGhlcmUncyBhIHBlcnRpbmVudCBw b2ludGVyOg0KaHR0cHM6Ly9kb3duLmRzZy5jcy50Y2QuaWUvaW90c3UvDQpKdXN0IHR3byB3ZWVr cyBsZWZ0IGJlZm9yZSB0aGUgc3VibWlzc2lvbiBkZWFkbGluZS4uLikNCg0KR3LDvMOfZSwgQ2Fy c3Rlbg0K From nobody Wed May 11 05:59:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188A612DA95 for ; Wed, 11 May 2016 05:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7to4GbM9hnrL for ; Wed, 11 May 2016 05:59:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3622B12DAA2 for ; Wed, 11 May 2016 05:59:32 -0700 (PDT) Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4WRI-1bqNxt3SlY-00yiYf for ; Wed, 11 May 2016 14:59:30 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57332CB1.1050609@gmx.net> Date: Wed, 11 May 2016 14:59:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CO3Sb2JPtNRQqghidd1GR8SoH9L2aomBs" X-Provags-ID: V03:K0:CXddt5shD4sG8wa5i/PC0sI1kPbc0GNhzUAZfMEilqsRiRYrO0i M59GlM7XAbUJuJGzTovU1afNvNaToeUf7rifbF4NVEHLozZopHndoPvk7idCqmDqH1puQCM 4RThvGYCELdr//Yj3dawFBd7oUD/IMkDVYQ2DK0nJ62VawLUgJGs3VTwXWhGlVphEKzKHm2 Ol1SrQHvq4RjyoNgC4xYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:SPDU3l2YE9M=:yKnd9WMv63A1tQjv8k1nk4 idkF56FD+booxauBmNltloOO5xtZ9pEwou9J1tsOJXSrLQuxWpWkLfucmfxgrmOjT7LGxxg+Y DrS2uP24uTkE28T7pn/xEdwRDZDPR+Ya+Wgu6cRwGg0aN5uNIR06Gjh+jeNEBEdeOY46DfUaG CG6wFAVLCLREsA7vb8PaMUjbC0nueUipGH8sscy+igzNqIh47agqaWm3KgVoJGWaZkLOH0AVB pFpTsSwSL0Vh6DSWQ3rDBMSEijapD7QOggGPL3UtWrSt3yry3+VYXac/OeD+u91wepxvsjPAp pKlGHssokUu/pcIbSL3RfAzjTZCTCLdWgrQzNRNGMsRnDE+GEL3GJH8gJR0VvOQVrOcQztAK4 GZGRSKGQW0+ej1GXy2PCPOdVMOwDhhOLJ+RHrHqO3AXoCreC2Vh9azGeqOQDloyAbNSbBbQjG YrwGJbD/VazhSacXbr28IKY4DHkO6RQj1R80BRuEyIwf46am/yfz8nxCKf0YzY8JGT7MMNVc+ tnZYaklJOXLHLOgWTWIdGTthKtPe2VTCc4xfTxtsoYFXtzYV2ffnENhhsl1CGmRViRY8CcRqM k3tGGTguDjbJSiJ4XQ6iySJzJnwSTcP4d7BcNEdjyoEXyMdMu/Ct9UcGcBe6X5SKEolw4OEbC OmjVnmHsJM8YzIPG1ruQVwpLg+2JQ4r6cMM9/9sWTTXkErMH4ZMz4zYpVxPiMP78SbmY6OAWd c5/CD850mKCYLmLaaLfYY9SwxDw3tIykHPlGcHn9agMpLML56UvuPB6vO4Y= Archived-At: Subject: [core] CoAP over TCP/TLS -- Resolving Open Issues X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 12:59:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CO3Sb2JPtNRQqghidd1GR8SoH9L2aomBs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, in an attempt to address the open issues regarding the CoAP over TCP/TLS draft you can track our progress here: https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-coap-tcp-tls-xx.tx= t Note that this is the most recent snapshot and does not necessarily reflect even the agreement of the document authors. It may still be useful for some to get a better idea what is in the pipeline. We will try to post a new draft version by the end of the week. Ciao Hannes --CO3Sb2JPtNRQqghidd1GR8SoH9L2aomBs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXMyyxAAoJEGhJURNOOiAtyi0H/2fC310K5WhqmVwQKCsO5G8V SFRAKSj6DkerqGlKekzee1sitnPm0qs/nhp6xWaFp5jz3Srg6+lgjJ/tgVlAXZ8J Si6D+xu8GTExiXjyuQX2lkYmBLCS2GSPafibejjqPF7UvJ6umZh+qTGuVTN4w7b6 n12XYAAoIJuXMDKl5dxdVYFzKGjOAcxEXYQrQrGd9K0uvscWjinpeDGJF0Yt0AAv 9hWmXPs4cd4BMaRaKctze3kAaXqP5vzq1JJwnCToSbW/fbdpr7apbkDnnTkwjSwo 54v9u5a+x3ixLRQZhc2uucCKNamDns3xRuUJWaHQiPxASwk/Ik/Zt1ZbgrDjle8= =ezZc -----END PGP SIGNATURE----- --CO3Sb2JPtNRQqghidd1GR8SoH9L2aomBs-- From nobody Fri May 13 06:40:37 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5204D12D143; Fri, 13 May 2016 06:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513134033.10520.69223.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 06:40:33 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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 2016 13:40:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Guidelines for HTTP-to-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-10.txt Pages : 36 Date : 2016-05-13 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 13 06:45:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441EA12B014 for ; Fri, 13 May 2016 06:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKauPzJr2aA6 for ; Fri, 13 May 2016 06:45:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED61612B021 for ; Fri, 13 May 2016 06:45:49 -0700 (PDT) Received: from localhost ([::1]:54161 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1b1DPY-0005Bb-TN; Fri, 13 May 2016 06:45:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, akbar.rahman@interdigital.com X-Trac-Project: core Date: Fri, 13 May 2016 13:45:48 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/401#comment:1 Message-ID: <084.c2f31521e9b662666596238f77ad67f2@trac.tools.ietf.org> References: <069.73f5d27f1b947907c329ff6c0cb6514a@trac.tools.ietf.org> X-Trac-Ticket-ID: 401 In-Reply-To: <069.73f5d27f1b947907c329ff6c0cb6514a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, akbar.rahman@interdigital.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 Resent-To: draft-ietf-core-http-mapping@ietf.org Resent-Message-Id: <20160513134549.ED61612B021@ietfa.amsl.com> Resent-Date: Fri, 13 May 2016 06:45:49 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #401 (http-mapping): Update to also cover forward and interception proxy cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.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 2016 13:45:52 -0000 #401: Update to also cover forward and interception proxy cases Changes (by akbar.rahman@interdigital.com): * status: new => closed * resolution: => fixed Comment: Fixed in Rev -10. Clarified that draft covers not only Reverse HC Proxy but that many parts also apply to Forward and Interception Proxies. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core-http- akbar.rahman@interdigital.com | mapping@tools.ietf.org Type: protocol enhancement | Status: closed Priority: major | Milestone: Component: http-mapping | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: core From nobody Fri May 13 06:51:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360FD12B021 for ; Fri, 13 May 2016 06:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtlkiMD4vg8g for ; Fri, 13 May 2016 06:51:22 -0700 (PDT) Received: from smtp-in1.interdigital.com (unknown [68.168.94.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590E712B014 for ; Fri, 13 May 2016 06:51:22 -0700 (PDT) X-ASG-Debug-ID: 1463147480-06daaa10907e190001-aa7cYp Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id 9BcUttrukIQSidHR (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2016 09:51:20 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0279.002; Fri, 13 May 2016 09:51:20 -0400 From: "Rahman, Akbar" To: "cabo@tzi.org" , "jaime.jimenez@ericsson.com" Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-ASG-Orig-Subj: RE: [core] I-D Action: draft-ietf-core-http-mapping-10.txt Thread-Index: AQHRrR0WzJNnBq5QE0q4cwryK3YZrp+24c9g Date: Fri, 13 May 2016 13:51:20 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BAB947B@NABESITE.InterDigital.com> References: <20160513134033.10520.69223.idtracker@ietfa.amsl.com> In-Reply-To: <20160513134033.10520.69223.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.71] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252] X-Barracuda-Start-Time: 1463147480 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 3318 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29545 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 13:51:24 -0000 Hi Carsten/Jaime, We have updated the draft to cover the following: Changes from ietf-09 to ietf-10: o Addressed Ticket #401 - Clarified that draft covers not only Reverse HC Proxy but that many parts also apply to Forward and Interception Proxies. o Clarified that draft concentrates on the HTTP-to-CoAP mapping direction (i.e. the HC proxy is a HTTP server and a CoAP client). o Clarified the "null mapping" case where no CoAP URI information is embedded in the HTTP request URI. o Moved multicast related security text to the "Security Considerations" to consolidate all security information in one location. o Removed references to "placement" of proxy (e.g. server-side vs client-side) as is confusing and provides little added value. o Fixed version numbers on references that were corrupted in last revision due to outdated xml2rfc conversion tool local cache. o Various editorial improvements. Can you please review, and start the 2nd WGLC if you think that everything = looks in order. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, May 13, 2016 9:41 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-10.txt 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 of the IE= TF. Title : Guidelines for HTTP-to-CoAP Mapping Implementation= s Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-10.txt Pages : 36 Date : 2016-05-13 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Sat May 14 07:45:02 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6075212B021; Sat, 14 May 2016 07:45:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160514144500.31153.98462.idtracker@ietfa.amsl.com> Date: Sat, 14 May 2016 07:45:00 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-core-block-20=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 14:45:00 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-core-block-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for adding new text at the beginning of the doc. This addresses my previous concern and makes it usage more clear from my point of view. Sorry for my rather long delay! From nobody Mon May 16 05:55:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7C012D601 for ; Mon, 16 May 2016 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6FL1fBZOp6k for ; Mon, 16 May 2016 05:55:38 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 62E5612D0F1 for ; Mon, 16 May 2016 05:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1463403335; d=isode.com; s=selector; i=@isode.com; bh=kNqjeOMMgm4ZIX+75ePD82kSkKOEN0CClSbt21HzVB8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=h1pp0FzGnzXBysKrq9a2XfE6zOgOU9l2YcQT5auQ9Yu+mNRHl4lQMDrYbKkWgauMLHcIKq geSjDmxYvMMkXGvJd9WmJEvAzSGaQCdsP15fiAWoOAtlX56uyiCUVI1kWVoFnez9cN9JDv 9TGFK7SUCR+0NP7aiBXJby6JxSly99I=; Received: from [172.22.50.30] ((unknown) [62.232.206.186]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 May 2016 13:55:35 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13E238) In-Reply-To: <571B8563.2090508@tzi.org> Date: Mon, 16 May 2016 14:03:46 +0100 Message-Id: <0E85B4E9-3F6F-43ED-9622-E09DA8782B69@isode.com> References: <5707D6F8.40000@isode.com> <57186FC3.9010405@tzi.org> <571B6571.5010602@isode.com> <571B8563.2090508@tzi.org> To: Carsten Bormann MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core@ietf.org Subject: Re: [core] Incoming AD review of draft-ietf-core-block-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 12:55:41 -0000 Hi Carsten, Continuing the discussion: > On 23 Apr 2016, at 15:23, Carsten Bormann wrote: >=20 > Alexey Melnikov wrote: >> Hi Carsten, >> Thank you for your responses. Further discussions below: >>=20 >>> On 21/04/2016 07:14, Carsten Bormann wrote: >>> Alexey Melnikov wrote: >>>> Hi, >>>> I am mostly happy with this document, but I have a few comments/questio= ns: >>>>=20 >>>> On page 11: >>>>=20 >>>> Clients that want to retrieve >>>> all blocks of a resource SHOULD strive to do so without undue delay. >>>>=20 >>>> This is not an interoperability issue and it would be impossible to >>>> verify compliance with it, unless you have a number that specifies what= >>>> is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here. >>>> Just use lowercased "should" instead. >>> Indeed, you cannot measure compliance with this SHOULD. I still think >>> that it is important for interoperability to point out that clients will= >>> have more successful exchanges if they heed this. (=46rom an >>> interoperability point of view, this is a statement that relieves >>> servers of a potential onus to somehow cater for clients that don't.) >>>=20 >>>> Similarly, in 2.5: >>>>=20 >>>> Clients SHOULD strive to send all blocks of a >>>> request without undue delay. >>>>=20 >>>> (Similar text in 2.6) >>> (Ditto.) >>=20 >> I think I prefer to have some recommendations on what is "undue delay", >> if you can add some text. >=20 > Delay for which there isn't a good reason? >=20 > Another way to say this would be: "Servers will not go out of their way > to accommodate clients that take forever to finish a block-wise > transfer. If the resource changes while this proceeds, the ETag for a > further block obtained may be different. To avoid this happening all > the time for a fast-changing resource, a server MAY try to keep a cache > around for a specific client for a short amount of time, but the > lifetime for such a cache may be short, on the order of a few expected > round-trip times, counting from the previous block transferred." >=20 > Should we go to this level of detail here? I think your suggested text above is better, so I think the answer is yes. >=20 >>>> In 2.9.2: >>>>=20 >>>> Should probably also mention that this response code is also used for >>>> mismatching content-format options >>> That is one way to see this; section 2.3 takes the view that mismatching= >>> content-formats aren't reassembled into one body in the first place so >>> an incomplete body is the result of not having all parts. >>> (I added back reference in the editor's draft.) >>=20 >> What is the state of the resource in such condition? >=20 > We didn't make a guarantee here; after all, the client just violated a > MUST. A good server will just reject a block-wise transfer with NUM=E2=89= =A00 > and a different content-format than the current state of the resource: > Either it is stateless, and it matches up the content-format of the > block against that of the existing resource, or it is atomic, in which > case it matches up the block against the partially reassembled piece of > representation that is going to replace the state of the resource. I think adding such suggestion (about server behaviour) would be a good thin= g. >=20 >>>> In 2.10: >>>>=20 >>>> A response with a Block1 Option in control usage >>>> with the M bit set invalidates cached responses for the target URI. >>>>=20 >>>> Can you explain the reason for this? >>>=20 >>> If the M bit had not been set the response would have been a final >>> response and would be used to update the cache entries for this URI. >>> Now, with the M bit set, we know that there will be a final response >>> later, but we don't know what that will be. Continuing to serve a >>> previous response from the cache doesn't sound right. But then, it >>> could be argued that the server just promised to perform the request >>> atomically later, so nothing has happened yet. Good question. I thought keeping cached version until an update is final would be a reasona= ble implementation choice. But I will not insist on this changing. >>>=20 >>>> In 3.2: >>>>=20 >>>> A stateless server that simply builds/updates the resource in place >>>> (statelessly) may indicate this by not setting the more bit in the >>>> response (Figure 8); in this case, the response codes are valid >>>> separately for each block being updated. >>>>=20 >>>> What is the behaviour of both the client and the server if PUT on a >>>> particular block fails? Is this clear enough in the document? >>> In the stateless case, the resource is now probably broken (unless the >>> resource is somehow intrinsically robust to this case). The client >>> should not be using the resource (e.g., try to initiate a firmware >>> update from an image it just has been building). The server is >>> stateless with respect to individual requests, so it is patiently >>> sitting there for the broken resource to be mended. >>=20 >> How can a resource be "mended" if a PUT failed? I think it would be >> reasonable for a server implementation to discard the whole accumulated >> payload, so there would be no way to mend it other than by uploading the >> whole thing from the beginning. If my interpretation is invalid, I >> welcome some clarifications on this. >=20 > If the server is stateless (in-place replace), the failed PUT may have > had no effect (which should be the case for 4.xx response), so the > client can try doing something else to that block. If there was a 5.xx > response, that is harder to say. But the real problem is that the > previous blocks may already have had an effect on the resource, so it > may be inconsistent/incomplete. I think this demonstrates my concern. If a PUT fails, the client that did th= e PUT goes away and another client requests the same resource, what does the= server do? Will it serve a corrupted version? Lack of predictable behaviour in this case bothers me. >=20 >> So I think this needs more clarifying text, either describing what >> client might be able to do to fix the resource or explaining that the >> client need to restart upload. >=20 > Right, I'll try to separate out the cases and add some text (but not > here in the examples). [...] >=20 >>>> As block2 is a critical option, how can a server know if a particular >>>> client supports this option? >>> The assumption here is that CoAP clients generally do, unless they are >>> very specialized and never have to deal with non-trivial amounts of >>> information (such as a /.well-known/core). >>=20 >> Is this generally true for all COAP extensions or just some? >=20 > Just this one. Block-wise transfers were part of the design for the > CoAP protocol from the start, and implementers have been aware that they > had to do block-wise in order to support non-trivial payload sizes (but > they don't have to do them if they don't need to). >=20 >> Extensibility for most protocols is done by capability >> discovery/negotiation and graceful service degradation in absence of a >> particular extension. This seems to violate this principle. >=20 > Right. So, for instance Observe was designed so that it can be > gracefully ignored by a server that doesn't implement it. We still put > a mechanism in RFC 6690 so a server can signal that it offers Observe > for a resource. I would expect similar out of band information to be > provided for future extensions, so a client doesn't have to waste a > round-trip trying out the extension. Block is slightly weird in that a > server may need to offer the (critical) extension unsolicited for an > unextended request; we'd try to avoid that for any new extension, but > here we do have the luxury. Because Block is special, I think this needs extra text early in the documen= t. Also the document should have Update value for the base COAP RFC in the head= er to signal this. From nobody Mon May 16 16:13:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9C12DB06 for ; Mon, 16 May 2016 16:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2a_E1wPvLvD for ; Mon, 16 May 2016 16:13:21 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8D812DAE4 for ; Mon, 16 May 2016 16:13:20 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id x189so26336781ywe.3 for ; Mon, 16 May 2016 16:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=xwSHqXv4IsvfPsqrDTHoePYYOrGd0flQ1XKj38DCg84=; b=kSkKjpNOjH2O1w6sbQKlp2RgQtCJ8cyQVB0rJ8mi/bMhGa4tUWtWnh4oP6dw768Rgb 0fwU2VEYO64PZom7yLPkK3G/7CW0S70DYDpsCCdn/Q2+zUInadE4JQrU4psqr9OL/R8v ID+FrXEHwTlLT+NIxqWLD9Hu3NF4Z8qYxFVoaQq1BvF9suy5EQ6XAh09Uwg+VXg8qHzY DaYr+501frLWH7Uackje2cilLVV4P0ROwMt+kq63ivc9KU/D7L0br6WVsx3pO5VSqCxY dZnwicV4dokZBscL6tZMFG0b3f6jnESIl/DYazcbjOT7U7YrJHZGOehhrffcJSS40iw7 bJiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=xwSHqXv4IsvfPsqrDTHoePYYOrGd0flQ1XKj38DCg84=; b=VJDXkFVTq3P2jJaINL8l7UoqN5WtZR8eJ4+nsGgtxHtOCKTJUMPlVMnjWKOQN/UuVd ThJlGSVv9sMwHzhBz2TWz7cngV/5UxwF4zmdkpreehbWfq2U1rv//JeXIHOd8nLuwsvu VEetCRBY9bkTnKq7TYBK4mQljutG1L0ya+Utk/xryD4GRvbgLi5Yncw7OcFMtI0P6sRC fFelZzQJ8jTndNTFMXKrUH7GGbUF5O2fLgSYsMgZNMCRijMVoypraDUU9SJqvDr86Jb7 1UFJ8okHuBX22dV/ZytskneUhKbSCRJbgv2l8eX701TcVhavR8mW7e5reoqcVcu3QcEa oUnQ== X-Gm-Message-State: AOPr4FXqkMuZY2VI6t7qGw98ACTDdc+bLZ/Q8HhuEuZ9PVVcqtA0ojqxcPcJY+JwoYNhFfJFAucjc05PMNJW3A== MIME-Version: 1.0 X-Received: by 10.37.17.135 with SMTP id 129mr15714799ybr.170.1463440399959; Mon, 16 May 2016 16:13:19 -0700 (PDT) Received: by 10.37.44.130 with HTTP; Mon, 16 May 2016 16:13:19 -0700 (PDT) Date: Mon, 16 May 2016 16:13:19 -0700 Message-ID: From: Andy Bierman To: Core Content-Type: multipart/alternative; boundary=001a113e6ef630cb410532fdc53b Archived-At: Subject: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 23:13:23 -0000 --001a113e6ef630cb410532fdc53b Content-Type: text/plain; charset=UTF-8 Hi, Here are my comments on the YANG to CBOR draft Andy ------------------------------------------- sec. 3: para 4: The end user of this mapping specification can mandate the use of a specific key type or a specific subset of key types. C1) How does the end-user do this? ----------------------------------------- 4.2. The "container" Schema Node Collections such as containers, list instances, notifications, RPC inputs, RPC outputs, action inputs and action outputs MUST be encoded using a CBOR map data item (major type 5). A map is comprised of pairs of data items, with each data item consisting of a key and a value. C2) Add a comment that "key" refers to the child node identifier and value refers the the value of the child node. It does not refer to the YANG term "key". ---------------------------------------- sec 4.2: *SIDs as keys* Keys implemented using SIDs MUST be encoded using a CBOR unsigned integer (major type 0) 2nd bullet: Delta values may result in a negative number, clients and servers MUST support negative deltas. C3) Doesn't 2nd bullet require CBOR type 1? Summary: KEY ENCODING (3 variants): SID: Major type 0 or 1 string: Major type 3 hash: Major type 2 -------------------------------------------- 5.3. The "decimal64" Type Leafs of type decimal64 MUST be encoded using either CBOR unsigned integer (major type 0) or CBOR signed integer (major type 1), depending on the actual value. The position of the decimal point is defined by the fraction-digits YANG statement and is not available in the CBOR encoding. C4) How are decimal64 values that start with zero encoded? leaf foo { type decimal64 { fraction-digits 3; } default 0.005; } C5) You probably mean to convert the deciaml64 to a signed or unsigned integer: 1.005 == 1005 Then it is up to the decoder to know the YANG schema so it can adjust based on the fraction-digits value. --------------------------------------------------- 5.6. The "enumeration" Type Leafs of type enumeration MUST be encoded using a CBOR unsigned integer data item (major type 0). C6) Need to say that the implicit or explicit value-stmt value is used, not the enumeration name like in XML or JSON C7) Enumeration value is allowed to be negative, so major type 1 also allowed ------------------------------------------------------ 5.7. The "bits" Type Leafs of type bits MUST be encoded using a CBOR byte string data item (major type 2). C8) Need to say that the implicit or explicit position-stmt value is used, not the bit name like in XML or JSON ------------------------------------------------------ 5.8. The "binary" Type Leafs of type binary MUST be encoded using a CBOR byte string data item (major type 2). C9) What string format is used? base64? raw UTF-8? ------------------------------------------------------ 5.12. The "union" Type Leafs of type union MUST be encoded using the rules associated with one of the types listed. C10) This does not really work because so many YANG types use the same CBOR major encoding type union { type int32; type enumeration { enum A { value -5; } enum B { value 3; } } type bits { bit X { position 1; } bit Y { position 3; } } type decimal64 { fraction-digits 2; } } How do I know if '3' is for int32, enum B or bit Y? How do I know 103 is really decimal64 "1.03" and not an int32 "103"? C11) Need to specify that types are evaluated in YANG statement order (e.g., check int32, then enumeration, then bits) -------------------------------------------------------- sec. 5.13, para 5 When SIDs identify a YANG list, the presence of the key(s) for this list is optional. When the key(s) are present, the targeted instance within this list is selected. When the key(s) are absent, the entire YANG list is selected. C12) A YANG instance-identifier MUST identify exactly 1 instance. It cannot specify all instances of a YANG list. C13) If instance-identifier used in a union, no way to tell that SID, name, or hash encoding is really an instance-identifier and not a string or a number. C14) How are the keys specified? The CoMI draft specifies a URI encoding but nothing in CBOR. Seems like they would have to be a separate string (keys=A,14,fred). Examples (e.g. for SID) using an array are not clear. ----------------------------------------------------------- Attributes: C15) XML and YANG/JSON allow meta-data to be sent with the YANG data. (e.g. NETCONF "operation" or "default" attributes) How would meta-data be encoded in CBOR? ----------------------------------------------------------- YANG List Keys: C16) XML and YANG/JSON require YANG list keys to be encoded first even if they are not defined first in the list. This allows server code to dispatch or do entry lookup without requiring buffering. Should CBOR encoding of YANG lists require the same? --001a113e6ef630cb410532fdc53b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here are my comments on = the YANG to CBOR draft


Andy


------------------------------------------= -

sec. 3: para 4:

= =C2=A0 =C2=A0The end user of this mapping specification
=C2=A0 = =C2=A0can mandate the use of a specific key type or a specific subset of
=C2=A0 =C2=A0key types.

C1) =C2=A0How does= the end-user do this?


------------= -----------------------------

4.2.=C2=A0 The "= ;container" Schema Node

=C2=A0 =C2=A0Collecti= ons such as containers, list instances, notifications, RPC
=C2=A0= =C2=A0inputs, RPC outputs, action inputs and action outputs MUST be encode= d
=C2=A0 =C2=A0using a CBOR map data item (major type 5).=C2=A0 A= map is comprised of
=C2=A0 =C2=A0pairs of data items, with each = data item consisting of a key and a
=C2=A0 =C2=A0value.=C2=A0

C2) Add a comment that "key" refers to the = child node identifier
and value refers the the value of the child= node. It does not
refer to the YANG term "key".
<= div>

----------------------------------------<= /div>
sec 4.2:

=C2=A0 =C2=A0*SIDs as keys*

=C2=A0 =C2=A0Keys implemented using SIDs MUST be enco= ded using a CBOR unsigned
=C2=A0 =C2=A0integer (major type 0)

=C2=A0 2nd bullet:
=C2=A0 =C2=A0 Delta valu= es may result in a negative number, clients and servers
=C2=A0 = =C2=A0 =C2=A0 MUST support negative deltas.

C3) Do= esn't 2nd bullet require CBOR type 1?

Summary:= KEY ENCODING (3 variants):
=C2=A0 =C2=A0SID: =C2=A0 =C2=A0 Major= type 0 or 1
=C2=A0 =C2=A0string: =C2=A0Major type 3
= =C2=A0 =C2=A0hash: =C2=A0 =C2=A0Major type 2

-----= ---------------------------------------

5.3.=C2=A0= The "decimal64" Type

=C2=A0 =C2=A0Leafs= of type decimal64 MUST be encoded using either CBOR unsigned
=C2= =A0 =C2=A0integer (major type 0) or CBOR signed integer (major type 1),
=C2=A0 =C2=A0depending on the actual value.=C2=A0 The position of th= e decimal point is
=C2=A0 =C2=A0defined by the fraction-digits YA= NG statement and is not available in
=C2=A0 =C2=A0the CBOR encodi= ng.

C4) How are decimal64 values that start with z= ero encoded?

=C2=A0 =C2=A0leaf foo {
=C2= =A0 =C2=A0 =C2=A0type decimal64 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0frac= tion-digits 3;
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2= =A0default 0.005;
=C2=A0 =C2=A0}

C5) You= probably mean to convert the deciaml64 to a signed
or unsigned i= nteger:

=C2=A0 =C2=A01.005 =3D=3D 1005
<= br>
Then it is up to the decoder to know the YANG schema so it
can adjust based on the fraction-digits value.

=
---------------------------------------------------

5.6.=C2=A0 The "enumeration" Type

=C2=A0 =C2=A0Leafs of type enumeration MUST be encoded using a CBOR unsign= ed
=C2=A0 =C2=A0integer data item (major type 0).

<= /div>
C6) Need to say that the implicit or explicit value-stmt value
is used, not the enumeration name like in XML or JSON
C7) Enumeration value is allowed to be negative, so major type = 1 also
allowed


----------= --------------------------------------------

5.7.= =C2=A0 The "bits" Type

=C2=A0 =C2=A0Leaf= s of type bits MUST be encoded using a CBOR byte string data item
=C2=A0 =C2=A0(major type 2).

C8) Need to say that= the implicit or explicit position-stmt value
is used, not the bi= t name like in XML or JSON


--------= ----------------------------------------------

5.8= .=C2=A0 The "binary" Type

=C2=A0 =C2=A0L= eafs of type binary MUST be encoded using a CBOR byte string data
=C2=A0 =C2=A0item (major type 2).

C9) What string= format is used? base64? raw UTF-8?

--------------= ----------------------------------------

5.12.=C2= =A0 The "union" Type

=C2=A0 =C2=A0Leafs = of type union MUST be encoded using the rules associated with
=C2= =A0 =C2=A0one of the types listed.

C10) This does = not really work because so many YANG types use
the same CBOR majo= r encoding

=C2=A0 =C2=A0type union {
=C2= =A0 =C2=A0 =C2=A0 type int32;
=C2=A0 =C2=A0 =C2=A0 type enumerati= on {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum A { value -5; }
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum B { value 3; }
=C2=A0 =C2=A0 =C2= =A0 }
=C2=A0 =C2=A0 =C2=A0 type bits {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 bit X { position 1; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b= it Y { position 3; }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2= =A0 =C2=A0 type decimal64 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fraction-= digits 2;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}

How do I know if '3' is for int32, enum B or bit = Y?
How do I know 103 is really decimal64 "1.03" and not=
an int32 "103"?

C11) =C2=A0Ne= ed to specify that types are evaluated in YANG
statement order (e= .g., check int32, then enumeration, then bits)

--------------------------------------------------------
<= div>
sec. 5.13, para 5

=C2=A0 =C2=A0= When SIDs identify a YANG list, the presence of the key(s) for this
=C2=A0 =C2=A0list is optional.=C2=A0 When the key(s) are present, the ta= rgeted instance
=C2=A0 =C2=A0within this list is selected.=C2=A0 = When the key(s) are absent, the entire
=C2=A0 =C2=A0YANG list is = selected.

C12) A YANG instance-identifier MUST ide= ntify exactly 1 instance.
It cannot specify all instances of a YA= NG list.

C13) If instance-identifier used in a uni= on, no way to tell that
SID, name, or hash encoding is really an = instance-identifier
and not a string or a number.

<= /div>
C14) How are the keys specified?=C2=A0 The CoMI draft specifies a= URI encoding
but nothing in CBOR. Seems like they would have to = be a separate string
(keys=3DA,14,fred).=C2=A0 Examples (e.g. for= SID) using an array are not clear.

--------------= ---------------------------------------------

Attr= ibutes:

C15) XML and YANG/JSON allow meta-data to = be sent with
the YANG data. =C2=A0(e.g. NETCONF "operation&q= uot; or "default" attributes)
How would meta-data be en= coded in CBOR?

-----------------------------------= ------------------------

YANG List Keys:

C16) XML and YANG/JSON require YANG list keys to be encoded= first
even if they are not defined first in the list.=C2=A0 This= allows server
code to dispatch or do entry lookup without requir= ing buffering.
Should CBOR encoding of YANG lists require the sam= e?

--001a113e6ef630cb410532fdc53b-- From nobody Tue May 17 11:01:23 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECB912DC81 for ; Tue, 17 May 2016 11:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Elm2pm7XhWcK for ; Tue, 17 May 2016 11:01:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D3B12DC7C for ; Tue, 17 May 2016 11:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=955E9SHWYHQlc9k9P5GBr0ugRRVJ0GptecRRypDKqjI=; b=G4hrJCP3KZwgvUnzi5F6xGsFY81JSylifEMmVfiIMrrEwgZW5Hd9XuPrfxcGyGOihOo4NNRqMx9z/pM2+mihLnPQf6C1sHdlPB5MxLoaND2aTP3xm/DHWLtywmeuylkP6WhCZ07z64VNm5KiSmFnU+bIrynHD4fmkMXd0gM/NRY= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 18:00:58 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0497.019; Tue, 17 May 2016 18:00:58 +0000 From: Michel Veillette To: Andy Bierman , Core Thread-Topic: [core] Comments on draft-ietf-core-yang-cbor-00 Thread-Index: AQHRr8iPxRSRAjhbgEmS2wWjXvPI7Z+9MAuA Date: Tue, 17 May 2016 18:00:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 72cc28e0-da3c-4885-aeca-08d37e7d3341 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:RN/jHyheuIOorWfomx03zCE5HAOZE8+ylv8AOjvWBoKMBxJEXJdMwioZZyeXBS62iGg2zfNuOQlIqmZuj/fqGL+2rO54OQCAU56SmuCVJpPmPmSUf0k/6huPm+vzRoCy1p55nSnabitrNjM0bjXQXQ==; 24:geb4kv8XT4zlnD5F+u1DO7AzUX/oaAv9rG6CFKsFGYVHjBn6sZtqKC/cQTw83k4jTLIODf1rAviBEDc/kvy+VeRJgINNwczqYJ2XoPgfRcM=; 7:bKkfGBkh0AfXwY8OgPo4XskETxf2NQUeXM8A8UTPtXHDM46A9agrgDE5kI9nnNO+gkaURI1U5TtpfXTQZIgR/g3JXQ6MTYux3LX3CxmJF6WflAdjGouNnG/8q3Bobixl4br0aqVRYchkFHbGNwZv7uSV0xR3es0vseRmFM+4EdbxVC3mQg+Xvwwpk2wzjVkP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(16236675004)(189998001)(107886002)(2906002)(5008740100001)(19300405004)(19617315012)(2950100001)(5003600100002)(2900100001)(54356999)(76176999)(50986999)(5001770100001)(15975445007)(102836003)(790700001)(1220700001)(6116002)(3846002)(586003)(33656002)(19580395003)(230783001)(19625215002)(19580405001)(122556002)(77096005)(5002640100001)(66066001)(8676002)(8936002)(81166006)(87936001)(10400500002)(5004730100002)(9686002)(11100500001)(76576001)(74316001)(106116001)(86362001)(92566002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR06MB17631B5C2248C854DFC47906FE480BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 18:00:58.1419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:01:21 -0000 --_000_BLUPR06MB17631B5C2248C854DFC47906FE480BLUPR06MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSBhbmQgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KU2VlIFtNVl0gYmVsbG93IGZv ciBteSBhbnN3ZXJzLg0KDQpJJ2xsIHdhaXQgZm9yIHlvdXIgcmVwbHkgYmVmb3JlIGFwcGx5aW5n IGFueSBjaGFuZ2VzIHRvIHRoZSBsYXRlc3QgZHJhZnQuDQpodHRwOi8vY29yZS13Zy5naXRodWIu aW8veWFuZy1jYm9yL2RyYWZ0LWlldGYtY29yZS15YW5nLWNib3ItbGF0ZXN0Lmh0bWwNCg0KUmVn YXJkcywNCk1pY2hlbA0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiBNYXktMTYtMTYgNzoxMyBQTQ0KVG86 IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbY29yZV0gQ29tbWVudHMgb24gZHJhZnQt aWV0Zi1jb3JlLXlhbmctY2Jvci0wMA0KDQpIaSwNCg0KSGVyZSBhcmUgbXkgY29tbWVudHMgb24g dGhlIFlBTkcgdG8gQ0JPUiBkcmFmdA0KDQoNCkFuZHkNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCnNlYy4gMzogcGFyYSA0Og0KDQogICBUaGUgZW5k IHVzZXIgb2YgdGhpcyBtYXBwaW5nIHNwZWNpZmljYXRpb24NCiAgIGNhbiBtYW5kYXRlIHRoZSB1 c2Ugb2YgYSBzcGVjaWZpYyBrZXkgdHlwZSBvciBhIHNwZWNpZmljIHN1YnNldCBvZg0KICAga2V5 IHR5cGVzLg0KDQpDMSkgIEhvdyBkb2VzIHRoZSBlbmQtdXNlciBkbyB0aGlzPw0KDQpbTVZdDQpU aGUgImVuZCB1c2VyIiBpbiB0aGlzIGNvbnRleHQgaXMgdHlwaWNhbGx5IGEgc3BlY2lmaWNhdGlv bi4NCkZvciBleGFtcGxlLCBkcmFmdC12ZWlsbGV0dGUtY29yZS1jb29sLTAxIG1hbmRhdGUgU0lE IGFzIGtleSB0eXBlLg0KDQpXZSBzaG91bGQgcHJvYmFibHkgdXNlIHNvbWV0aGluZyBlbHNlIHRo YW4gImVuZCB1c2VyIg0KQ2FuIHlvdSBwcm9wb3NlIGEgbmV3IHRleHQgdG8gY2xhcmlmeSB0aGUg aW50ZW50IG9mIHRoaXMgc2VudGVuY2U/DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCjQuMi4gIFRoZSAiY29udGFpbmVyIiBTY2hlbWEgTm9kZQ0KDQogICBD b2xsZWN0aW9ucyBzdWNoIGFzIGNvbnRhaW5lcnMsIGxpc3QgaW5zdGFuY2VzLCBub3RpZmljYXRp b25zLCBSUEMNCiAgIGlucHV0cywgUlBDIG91dHB1dHMsIGFjdGlvbiBpbnB1dHMgYW5kIGFjdGlv biBvdXRwdXRzIE1VU1QgYmUgZW5jb2RlZA0KICAgdXNpbmcgYSBDQk9SIG1hcCBkYXRhIGl0ZW0g KG1ham9yIHR5cGUgNSkuICBBIG1hcCBpcyBjb21wcmlzZWQgb2YNCiAgIHBhaXJzIG9mIGRhdGEg aXRlbXMsIHdpdGggZWFjaCBkYXRhIGl0ZW0gY29uc2lzdGluZyBvZiBhIGtleSBhbmQgYQ0KICAg dmFsdWUuDQoNCkMyKSBBZGQgYSBjb21tZW50IHRoYXQgImtleSIgcmVmZXJzIHRvIHRoZSBjaGls ZCBub2RlIGlkZW50aWZpZXINCmFuZCB2YWx1ZSByZWZlcnMgdGhlIHRoZSB2YWx1ZSBvZiB0aGUg Y2hpbGQgbm9kZS4gSXQgZG9lcyBub3QNCnJlZmVyIHRvIHRoZSBZQU5HIHRlcm0gImtleSIuDQoN CltNVl0gSSBwcm9wb3NpbmcgdG8gYWRkIHRoZSBmb2xsb3dpbmcgdGV4dC4gRmVsbCBmcmVlIHRv IHByb3Bvc2UgYW4gYWx0ZXJuYXRlIHRleHQuDQoNCiJFYWNoIGtleSB3aXRoaW4gdGhlIENCT1Ig bWFwIGlzIHNldCB0byBhIGRhdGEgbm9kZSBpZGVudGlmaWVyLCBlYWNoDQp2YWx1ZSBpcyBzZXQg dG8gdGhlIHZhbHVlIG9mIHRoaXMgZGF0YSBub2RlIGluc3RhbmNlLiINCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpzZWMgNC4yOg0KDQogICAqU0lEcyBhcyBr ZXlzKg0KDQogICBLZXlzIGltcGxlbWVudGVkIHVzaW5nIFNJRHMgTVVTVCBiZSBlbmNvZGVkIHVz aW5nIGEgQ0JPUiB1bnNpZ25lZA0KICAgaW50ZWdlciAobWFqb3IgdHlwZSAwKQ0KDQogIDJuZCBi dWxsZXQ6DQogICAgRGVsdGEgdmFsdWVzIG1heSByZXN1bHQgaW4gYSBuZWdhdGl2ZSBudW1iZXIs IGNsaWVudHMgYW5kIHNlcnZlcnMNCiAgICAgIE1VU1Qgc3VwcG9ydCBuZWdhdGl2ZSBkZWx0YXMu DQoNCg0KQzMpIERvZXNuJ3QgMm5kIGJ1bGxldCByZXF1aXJlIENCT1IgdHlwZSAxPw0KDQpTdW1t YXJ5OiBLRVkgRU5DT0RJTkcgKDMgdmFyaWFudHMpOg0KICAgU0lEOiAgICAgTWFqb3IgdHlwZSAw IG9yIDENCiAgIHN0cmluZzogIE1ham9yIHR5cGUgMw0KICAgaGFzaDogICAgTWFqb3IgdHlwZSAy DQoNCltNVl0gVGhpcyBpc3N1ZSBpcyBhbHJlYWR5IGZpeGVkIGluIHRoZSBsYXRlc3QgZHJhZnQs IHNlZQ0KaHR0cDovL2NvcmUtd2cuZ2l0aHViLmlvL3lhbmctY2Jvci9kcmFmdC1pZXRmLWNvcmUt eWFuZy1jYm9yLWxhdGVzdC5odG1sI3JmYy5zZWN0aW9uLjQuMg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo1LjMuICBUaGUgImRlY2ltYWw2NCIgVHlw ZQ0KDQogICBMZWFmcyBvZiB0eXBlIGRlY2ltYWw2NCBNVVNUIGJlIGVuY29kZWQgdXNpbmcgZWl0 aGVyIENCT1IgdW5zaWduZWQNCiAgIGludGVnZXIgKG1ham9yIHR5cGUgMCkgb3IgQ0JPUiBzaWdu ZWQgaW50ZWdlciAobWFqb3IgdHlwZSAxKSwNCiAgIGRlcGVuZGluZyBvbiB0aGUgYWN0dWFsIHZh bHVlLiAgVGhlIHBvc2l0aW9uIG9mIHRoZSBkZWNpbWFsIHBvaW50IGlzDQogICBkZWZpbmVkIGJ5 IHRoZSBmcmFjdGlvbi1kaWdpdHMgWUFORyBzdGF0ZW1lbnQgYW5kIGlzIG5vdCBhdmFpbGFibGUg aW4NCiAgIHRoZSBDQk9SIGVuY29kaW5nLg0KDQpDNCkgSG93IGFyZSBkZWNpbWFsNjQgdmFsdWVz IHRoYXQgc3RhcnQgd2l0aCB6ZXJvIGVuY29kZWQ/DQoNCiAgIGxlYWYgZm9vIHsNCiAgICAgdHlw ZSBkZWNpbWFsNjQgew0KICAgICAgIGZyYWN0aW9uLWRpZ2l0cyAzOw0KICAgICB9DQogICAgIGRl ZmF1bHQgMC4wMDU7DQogICB9DQoNCltNVl0gSWYgSSB1c2UgdGhlIGRlZmF1bHQgdmFsdWUgYXMg ZXhhbXBsZSwgdGhlIHZhbHVlIDAuMDA1IGlzIGVuY29kZWQgYXMgMHgwNSBpbiBDQk9SLg0KSWYg YSB0ZXh0dWFsIHJlcHJlc2VudGF0aW9uIGlzIHJlcXVpcmVkLCB0aGUgbG9naWMgcGVyZm9ybWlu ZyB0aGlzIGNvbnZlcnNpb24gbmVlZHMgdG8gYWRkIHRoZSBsZWFkaW5nIHplcm8ocykgYW5kIHRo ZSBkZWNpbWFsIHBvaW50Lg0KDQpDNSkgWW91IHByb2JhYmx5IG1lYW4gdG8gY29udmVydCB0aGUg ZGVjaWFtbDY0IHRvIGEgc2lnbmVkDQpvciB1bnNpZ25lZCBpbnRlZ2VyOg0KDQogICAxLjAwNSA9 PSAxMDA1DQoNClRoZW4gaXQgaXMgdXAgdG8gdGhlIGRlY29kZXIgdG8ga25vdyB0aGUgWUFORyBz Y2hlbWEgc28gaXQNCmNhbiBhZGp1c3QgYmFzZWQgb24gdGhlIGZyYWN0aW9uLWRpZ2l0cyB2YWx1 ZS4NCg0KW01WXSBDb3JyZWN0Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KNS42LiAgVGhlICJlbnVtZXJhdGlvbiIgVHlwZQ0KDQogICBM ZWFmcyBvZiB0eXBlIGVudW1lcmF0aW9uIE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENCT1IgdW5z aWduZWQNCiAgIGludGVnZXIgZGF0YSBpdGVtIChtYWpvciB0eXBlIDApLg0KDQpDNikgTmVlZCB0 byBzYXkgdGhhdCB0aGUgaW1wbGljaXQgb3IgZXhwbGljaXQgdmFsdWUtc3RtdCB2YWx1ZQ0KaXMg dXNlZCwgbm90IHRoZSBlbnVtZXJhdGlvbiBuYW1lIGxpa2UgaW4gWE1MIG9yIEpTT04NCg0KQzcp IEVudW1lcmF0aW9uIHZhbHVlIGlzIGFsbG93ZWQgdG8gYmUgbmVnYXRpdmUsIHNvIG1ham9yIHR5 cGUgMSBhbHNvDQphbGxvd2VkDQoNCltNVl0NCkNvcnJlY3QgZm9yIGJvdGggY29tbWVudHMuDQpU aGUgZmlyc3Qgc2VudGVuY2UgbmVlZCB0byBiZSBmaXhlZCBhbmQgYSBjbGFyaWZpY2F0aW9uIG5l ZWQgdG8gYmUgYWRkZWQgYWJvdXQgdGhlIGF1dG9tYXRpYyBhc3NpZ25tZW50IGFsZ29yaXRobS4g SSBwcm9wb3NlOg0KDQoiTGVhZnMgb2YgdHlwZSBlbnVtZXJhdGlvbiBNVVNUIGJlIGVuY29kZWQg dXNpbmcgYSBDQk9SIHVuc2lnbmVkIGludGVnZXIgKG1ham9yIHR5cGUgMCkgb3IgQ0JPUiBzaWdu ZWQgaW50ZWdlciAobWFqb3IgdHlwZSAxKSwgZGVwZW5kaW5nIG9uIHRoZSBhY3R1YWwgdmFsdWUu IEVudW1lcmF0aW9uIHZhbHVlcyBhcmUgZWl0aGVyIGV4cGxpY2l0bHkgYXNzaWduZWQgdXNpbmcg dGhlIFlBTkcgc3RhdGVtZW50ICJ2YWx1ZSIgb3IgYXV0b21hdGljYWxseSBhc3NpZ25lZCBiYXNl ZCBvbiB0aGUgYWxnb3JpdGhtIGRlZmluZWQgaW4gW1JGQzYwMjBiaXNzXSBzZWN0aW9uIDkuNi40 LjIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQo1LjcuICBUaGUgImJpdHMiIFR5cGUNCg0KICAgTGVhZnMgb2YgdHlwZSBiaXRzIE1V U1QgYmUgZW5jb2RlZCB1c2luZyBhIENCT1IgYnl0ZSBzdHJpbmcgZGF0YSBpdGVtDQogICAobWFq b3IgdHlwZSAyKS4NCg0KQzgpIE5lZWQgdG8gc2F5IHRoYXQgdGhlIGltcGxpY2l0IG9yIGV4cGxp Y2l0IHBvc2l0aW9uLXN0bXQgdmFsdWUNCmlzIHVzZWQsIG5vdCB0aGUgYml0IG5hbWUgbGlrZSBp biBYTUwgb3IgSlNPTg0KDQpbTVZdDQpDb3JyZWN0LCBJIHByb3Bvc2U6DQoNCiJMZWFmcyBvZiB0 eXBlIGJpdHMgTVVTVCBiZSBlbmNvZGVkIHVzaW5nIGEgQ0JPUiBieXRlIHN0cmluZyBkYXRhIGl0 ZW0gKG1ham9yIHR5cGUgMikuIFRoZSBwb3NpdGlvbiBvZiBlYWNoIGJpdCBpcyBlaXRoZXIgZXhw bGljaXRseSBhc3NpZ25lZCB1c2luZyB0aGUgWUFORyBzdGF0ZW1lbnQgInBvc2l0aW9uIiBvciBh dXRvbWF0aWNhbGx5IGFzc2lnbmVkIGJhc2VkIG9uIHRoZSBhbGdvcml0aG0gZGVmaW5lZCBpbiBb UkZDNjAyMGJpc3NdIHNlY3Rpb24gOS43LjQuMi4iDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo1LjguICBUaGUgImJpbmFyeSIgVHlw ZQ0KDQogICBMZWFmcyBvZiB0eXBlIGJpbmFyeSBNVVNUIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9S IGJ5dGUgc3RyaW5nIGRhdGENCiAgIGl0ZW0gKG1ham9yIHR5cGUgMikuDQoNCkM5KSBXaGF0IHN0 cmluZyBmb3JtYXQgaXMgdXNlZD8gYmFzZTY0PyByYXcgVVRGLTg/DQoNCltNVl0gTm8gc3BlY2lh bCBmb3JtYXQsIGp1c3QgYmluYXJ5LCBzZWUgZXhhbXBsZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCjUuMTIuICBUaGUgInVuaW9u IiBUeXBlDQoNCiAgIExlYWZzIG9mIHR5cGUgdW5pb24gTVVTVCBiZSBlbmNvZGVkIHVzaW5nIHRo ZSBydWxlcyBhc3NvY2lhdGVkIHdpdGgNCiAgIG9uZSBvZiB0aGUgdHlwZXMgbGlzdGVkLg0KDQpD MTApIFRoaXMgZG9lcyBub3QgcmVhbGx5IHdvcmsgYmVjYXVzZSBzbyBtYW55IFlBTkcgdHlwZXMg dXNlDQp0aGUgc2FtZSBDQk9SIG1ham9yIGVuY29kaW5nDQoNCiAgIHR5cGUgdW5pb24gew0KICAg ICAgdHlwZSBpbnQzMjsNCiAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgICBlbnVtIEEg eyB2YWx1ZSAtNTsgfQ0KICAgICAgICBlbnVtIEIgeyB2YWx1ZSAzOyB9DQogICAgICB9DQogICAg ICB0eXBlIGJpdHMgew0KICAgICAgICBiaXQgWCB7IHBvc2l0aW9uIDE7IH0NCiAgICAgICAgYml0 IFkgeyBwb3NpdGlvbiAzOyB9DQogICAgICB9DQogICAgICB0eXBlIGRlY2ltYWw2NCB7DQogICAg ICAgIGZyYWN0aW9uLWRpZ2l0cyAyOw0KICAgICAgfQ0KICAgfQ0KDQpIb3cgZG8gSSBrbm93IGlm ICczJyBpcyBmb3IgaW50MzIsIGVudW0gQiBvciBiaXQgWT8NCkhvdyBkbyBJIGtub3cgMTAzIGlz IHJlYWxseSBkZWNpbWFsNjQgIjEuMDMiIGFuZCBub3QNCmFuIGludDMyICIxMDMiPw0KDQpbTVZd IE91Y2gsIHZlcnkgZ29vZCBwb2ludC4NCkknbSBwcm9wb3NpbmcgdG8gdXNlIENCT1IgdGFncyBm b3IgdGhlIGZvbGxvd2luZyBsaXN0IG9mIGRhdGF0eXBlcyB0byBhdm9pZCB0aGlzIGtpbmQgb2Yg YW1iaWd1aXRpZXMuDQoNCg0KwrcgICAgICAgIGJpdHMNCg0KwrcgICAgICAgIGRlY2ltYWw2NA0K DQrCtyAgICAgICAgZW51bWVyYXRpb24NCg0KwrcgICAgICAgIGlkZW50aXR5cmVmDQoNCsK3ICAg ICAgICBpbnN0YW5jZS1pZGVudGlmaWVyDQoNCsK3ICAgICAgICBsZWFmcmVmICAoT25seSBpZiBp ZiB0aGUgZGF0YXR5cGUgb2YgdGhlIHJlZmVyZW5jZWQgbGVhZiByZXF1aXJlIGEgQ0JPUiB0YWcp DQoNCkZvciB0aGUgZm9sbG93aW5nIGxpc3Qgb2YgIGRhdGF0eXBlcywgdGhleSBjYW4gYmUgdXNl ZCBkaXJlY3RseSB3aXRob3V0IENCT1IgdGFnLg0KDQoNCsK3ICAgICAgICBiaW5hcnkNCg0Kwrcg ICAgICAgIGJvb2xlYW4NCg0KwrcgICAgICAgIGVtcHR5DQoNCsK3ICAgICAgICBpbnQ4DQoNCsK3 ICAgICAgICBpbnQxNg0KDQrCtyAgICAgICAgaW50MzINCg0KwrcgICAgICAgIGludDY0DQoNCsK3 ICAgICAgICBzdHJpbmcNCg0KwrcgICAgICAgIHVpbnQ4DQoNCsK3ICAgICAgICB1aW50MTYNCg0K wrcgICAgICAgIHVpbnQzMg0KDQrCtyAgICAgICAgdWludDY0DQoNCi0tLS0tLS0NClByb3Bvc2Ug dGV4dDoNCg0KTGVhZnMgb2YgdHlwZSB1bmlvbiBNVVNUIGJlIGVuY29kZWQgdXNpbmcgdGhlIHJ1 bGVzIGFzc29jaWF0ZWQgd2l0aCBvbmUgb2YgdGhlIHR5cGVzIGxpc3RlZC4NCldoZW4gdXNlIGlu IGEgdW5pb24sIHRoZSBmb2xsb3dpbmcgbGlzdCBvZiBZQU5HIGRhdGF0eXBlcyBhcmUgcHJlZml4 ZWQgYnkgQ0JPUiB0YWcgdG8gYXZvaWQgY29uZnVzaW9uDQpiZXR3ZWVuIGRpZmZlcmVudCBZQU5H IGRhdGF0eXBlcyBlbmNvZGVkIHVzaW5nIHRoZSBzYW1lIENCT1IgbWFqb3IgdHlwZS4NCg0KbyBi aXRzDQpvIGRlY2ltYWw2NA0KbyBlbnVtZXJhdGlvbg0KbyBpZGVudGl0eXJlZg0KbyBpbnN0YW5j ZS1pZGVudGlmaWVyDQpvIGxlYWZyZWYgIChPbmx5IGlmIHRoZSBkYXRhdHlwZSBvZiB0aGUgbGVh ZiByZWZlcmVuY2VkIHVzaW5nIHRoZSAicGF0aCIgWUFORyBzdGF0ZW1lbnQgcmVxdWlyZSBhIENC T1IgdGFnKQ0KDQpTZWUgc2VjdGlvbiA3LjEgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgQ0JP UiB0YWdzLg0KDQotLS0tLS0tDQo3LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQo3LjEuICBUYWdz IFJlZ2lzdHJ5DQoNClRoaXMgc3BlY2lmaWNhdGlvbiByZXF1aXJlIHRoZSBhc3NpZ25tZW50IG9m IENCT1IgdGFncyBmb3IgdGhlIGZvbGxvd2luZyBZQU5HIGRhdGF0eXBlcy4NClRoZXNlIHRhZ3Mg YXJlIGFkZGVkIHRvIHRoZSBUYWdzIFJlZ2lzdHJ5IGFzIGRlZmluZWQgaW4gc2VjdGlvbiA3LjIg b2YgUkZDIDcwNDkuDQoNCnwgRGF0YSBJdGVtIHwgU2VtYW50aWNzIHwgUmVmZXJlbmNlDQp8IGJp dHMgfCBZQU5HIGJpdHMgZGF0YXR5cGUgfCBSRkM2MDIwYmlzcywgZHJhZnQtaWV0Zi1jb3JlLXlh bmctY2Jvcg0KfCBkZWNpbWFsNjQgfCBZQU5HIGRlY2ltYWw2NCBkYXRhdHlwZSB8IFJGQzYwMjBi aXNzLCBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yDQp8IGVudW1lcmF0aW9uIHwgWUFORyBlbnVt ZXJhdGlvbiBkYXRhdHlwZSB8IFJGQzYwMjBiaXNzLCBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9y DQp8ICBpZGVudGl0eXJlZiB8IFlBTkcgaWRlbnRpdHlyZWYgZGF0YXR5cGUgfCBSRkM2MDIwYmlz cywgZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvcg0KfCBpbnN0YW5jZS1pZGVudGlmaWVyIHwgWUFO RyBpbnN0YW5jZS1pZGVudGlmaWVyIGRhdGF0eXBlIHwgUkZDNjAyMGJpc3MsIGRyYWZ0LWlldGYt Y29yZS15YW5nLWNib3INCnwgIGxlYWZyZWYgIHwgWUFORyBsZWFmcmVmICBkYXRhdHlwZSB8IFJG QzYwMjBiaXNzLCBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yDQoNCg0KQzExKSAgTmVlZCB0byBz cGVjaWZ5IHRoYXQgdHlwZXMgYXJlIGV2YWx1YXRlZCBpbiBZQU5HDQpzdGF0ZW1lbnQgb3JkZXIg KGUuZy4sIGNoZWNrIGludDMyLCB0aGVuIGVudW1lcmF0aW9uLCB0aGVuIGJpdHMpDQoNCltNVl0g SSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50IG9yIHByb3Bvc2VkIHNvbHV0aW9uLg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpzZWMuIDUuMTMsIHBhcmEgNQ0KDQogICBXaGVuIFNJRHMgaWRlbnRpZnkgYSBZQU5HIGxp c3QsIHRoZSBwcmVzZW5jZSBvZiB0aGUga2V5KHMpIGZvciB0aGlzDQogICBsaXN0IGlzIG9wdGlv bmFsLiAgV2hlbiB0aGUga2V5KHMpIGFyZSBwcmVzZW50LCB0aGUgdGFyZ2V0ZWQgaW5zdGFuY2UN CiAgIHdpdGhpbiB0aGlzIGxpc3QgaXMgc2VsZWN0ZWQuICBXaGVuIHRoZSBrZXkocykgYXJlIGFi c2VudCwgdGhlIGVudGlyZQ0KICAgWUFORyBsaXN0IGlzIHNlbGVjdGVkLg0KDQpDMTIpIEEgWUFO RyBpbnN0YW5jZS1pZGVudGlmaWVyIE1VU1QgaWRlbnRpZnkgZXhhY3RseSAxIGluc3RhbmNlLg0K SXQgY2Fubm90IHNwZWNpZnkgYWxsIGluc3RhbmNlcyBvZiBhIFlBTkcgbGlzdC4NCg0KW01WXSBU aGUgZGVmaW5pdGlvbiBvZiBhIGxpc3QgaW4gUkZDIDYwMjAgc2VlbSBlZmZlY3RpdmVseSB0byBi YWNrLXVwIHRoaXMgY29uY2x1c2lvbi4NCg0KImxpc3Q6IEFuIGludGVyaW9yIGRhdGEgbm9kZSB0 aGF0IG1heSBleGlzdCBpbiBtdWx0aXBsZSBpbnN0YW5jZXMNCmluIHRoZSBkYXRhIHRyZWUuIEEg bGlzdCBoYXMgbm8gdmFsdWUsIGJ1dCByYXRoZXIgYSBzZXQgb2YgY2hpbGQgbm9kZXMuIg0KDQpB cmUgeW91IGF3YXJlIG9mIGFueSBvdGhlciBwbGFjZXMgd2hlcmUgdGhpcyBsaW1pdGF0aW9uIGlz IGRlc2NyaWJlZD8NCg0KSWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhlIGZvbGxvd2luZyBzZW50ZW5j ZXMgbmVlZCB0byBiZSByZW1vdmVkIGFuZCByZS1pbnRyb2R1Y2VkIGFzIGV4dGVuc2lvbiB3aXRo aW4NCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wgd2hlbiBpbnN0YW5jZS1pZGVudGlmaWVycyBh cmUgdXNlZCBpbiB0aGUgY29udGV4dCBvZiB0aGUgRkVUQ0ggb3IgaVBBVENIIG1ldGhvZHMuDQoN Cg0KIldoZW4gU0lEcyBpZGVudGlmeSBhIFlBTkcgbGlzdCwgdGhlIHByZXNlbmNlIG9mIHRoZSBr ZXkocykgZm9yIHRoaXMgbGlzdCBpcyBvcHRpb25hbC4NCg0KV2hlbiB0aGUga2V5KHMpIGFyZSBw cmVzZW50LCB0aGUgdGFyZ2V0ZWQgaW5zdGFuY2Ugd2l0aGluIHRoaXMgbGlzdCBpcyBzZWxlY3Rl ZC4NCg0KV2hlbiB0aGUga2V5KHMpIGFyZSBhYnNlbnQsIHRoZSBlbnRpcmUgWUFORyBsaXN0IGlz IHNlbGVjdGVkLiINCg0KTm90ZToNCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wgYWxyZWFkeSBh ZGQgdHdvIGV4dGVuc2lvbnMgdG8gaW5zdGFuY2UtaWRlbnRpZmllciBpbiB0aGUgY29udGV4dCBv ZiBhIEZFVENIIG9yIGlQQVRDSCwNCndlIHdpbGwgbmVlZCB0byBhZGQgYSB0aGlyZCBvbmUuIEkg c3RpbGwgYmVsaWV2ZSB0aGF0IHVzaW5nIGluc3RhbmNlLWlkZW50aWZpZXIgYXMgdGhlIGJhc2Ug Y29uc3RydWN0DQpmb3IgRkVUQ0ggYW5kIGlQQVRDSCBtYWtlIHNlbnNlIGluIG9yZGVyIHRvIG1p bmltaXplIGltcGxlbWVudGF0aW9uIGZvb3RwcmludCBldmVuIGlmIGV4dGVuc2lvbnMgYXJlIG5l ZWRlZC4NCg0KQzEzKSBJZiBpbnN0YW5jZS1pZGVudGlmaWVyIHVzZWQgaW4gYSB1bmlvbiwgbm8g d2F5IHRvIHRlbGwgdGhhdA0KU0lELCBuYW1lLCBvciBoYXNoIGVuY29kaW5nIGlzIHJlYWxseSBh biBpbnN0YW5jZS1pZGVudGlmaWVyDQphbmQgbm90IGEgc3RyaW5nIG9yIGEgbnVtYmVyLg0KDQpb TVZdIEFkZHJlc3NlZCBieSBteSBwcmV2aW91cyBhbnN3ZXIuDQoNCkMxNCkgSG93IGFyZSB0aGUg a2V5cyBzcGVjaWZpZWQ/ICBUaGUgQ29NSSBkcmFmdCBzcGVjaWZpZXMgYSBVUkkgZW5jb2RpbmcN CmJ1dCBub3RoaW5nIGluIENCT1IuIFNlZW1zIGxpa2UgdGhleSB3b3VsZCBoYXZlIHRvIGJlIGEg c2VwYXJhdGUgc3RyaW5nDQooa2V5cz1BLDE0LGZyZWQpLiAgRXhhbXBsZXMgKGUuZy4gZm9yIFNJ RCkgdXNpbmcgYW4gYXJyYXkgYXJlIG5vdCBjbGVhci4NCg0KW01WXSBXaGVuIGtleShzKSBhcmUg bmVlZGVkIHRvIHF1YWxpZnkgdGhlIGluc3RhbmNlLWlkZW50aWZpZXIsIGEgQ0JPUiBhcnJheSBp cyB1c2VkIGluc3RlYWQgb2YgYSBzaW1wbGUgQ0JPUiB1bnNpZ25lZCBpbnRlZ2VyLg0KVGhlIGZp cnN0IGVudHJ5IHdpdGhpbiB0aGUgQ0JPUiBhcnJheSBpcyB0aGUgU0lELCB0aGUgbmV4dCBlbnRy aWVzIGFyZSB0aGUga2V5KHMpIGVuY29kZWQgdXNpbmcgdGhlIHJ1bGVzIGRlZmluZWQgZm9yIHRo ZWlyIGRhdGF0eXBlcy4NClRoZXJlIGlzIG5vIHRleHQgY29udmVyc2lvbiByZXF1aXJlIHRvIG1p bmltaXNlIHRoZSBpbXBsZW1lbnRhdGlvbiBmb290cHJpbnQuDQoNClRoZSBmb2xsb3dpbmcgZXhh bXBsZToNCiIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0aW9uL3VzZXJbbmFtZT0nYm9i J10vYXV0aG9yaXplZC1rZXlbbmFtZT0nYWRtaW4nXS9rZXktZGF0YSINCg0KSXMgZW5jb2RlZCBh cyBmb2xsb3cgaW4gQ0JPUjoNClsxNzIxLCAiYm9iIiwgImFkbWluIl0NCg0KQ2FuIHlvdSBwcm9w b3NlIGV4dHJhIHRleHQgd2hpY2ggd2lsbCBjbGFyaWZ5IHRoaXMgaXRlbT8NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQXR0 cmlidXRlczoNCg0KQzE1KSBYTUwgYW5kIFlBTkcvSlNPTiBhbGxvdyBtZXRhLWRhdGEgdG8gYmUg c2VudCB3aXRoDQp0aGUgWUFORyBkYXRhLiAgKGUuZy4gTkVUQ09ORiAib3BlcmF0aW9uIiBvciAi ZGVmYXVsdCIgYXR0cmlidXRlcykNCkhvdyB3b3VsZCBtZXRhLWRhdGEgYmUgZW5jb2RlZCBpbiBD Qk9SPw0KDQpbTVZdIENhbiB5b3UgcHJvdmlkZSBtZSBzb21lIHJlZmVyZW5jZSB0byB0aGlzIHRv cGljLg0KSSBkaWRuJ3QgZmluZCBhbnkgcmVmZXJlbmNlcyB0byAib3BlcmF0aW9uIiBhbmQgImRl ZmF1bHQiIGluICJkcmFmdC1pZXRmLW5ldG1vZC15YW5nLWpzb24iDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCllBTkcgTGlz dCBLZXlzOg0KDQpDMTYpIFhNTCBhbmQgWUFORy9KU09OIHJlcXVpcmUgWUFORyBsaXN0IGtleXMg dG8gYmUgZW5jb2RlZCBmaXJzdA0KZXZlbiBpZiB0aGV5IGFyZSBub3QgZGVmaW5lZCBmaXJzdCBp biB0aGUgbGlzdC4gIFRoaXMgYWxsb3dzIHNlcnZlcg0KY29kZSB0byBkaXNwYXRjaCBvciBkbyBl bnRyeSBsb29rdXAgd2l0aG91dCByZXF1aXJpbmcgYnVmZmVyaW5nLg0KU2hvdWxkIENCT1IgZW5j b2Rpbmcgb2YgWUFORyBsaXN0cyByZXF1aXJlIHRoZSBzYW1lPw0KDQpbTVZdIFRoaXMgaXMgbm90 IHBvc3NpYmxlIGZvciBib3RoIEpTT04gYW5kIENCT1IuDQpUaGUgb3JkZXJpbmcgb2YgaXRlbXMg d2l0aGluIEpTT04gb2JqZWN0cyBvciBDQk9SIG1hcHMgYXJlIGFyYml0cmFyeS4NCg0KVGhpcyBp cyBhZGRyZXNzZWQgaW4gImRyYWZ0LWlldGYtbmV0bW9kLXlhbmctanNvbiIgc2VjdGlvbiA1LjQN Cg0KIlVubGlrZSB0aGUgWE1MIGVuY29kaW5nLCB3aGVyZSBsaXN0IGtleXMgYXJlIHJlcXVpcmVk IHRvIHByZWNlZGUgYW55DQpvdGhlciBzaWJsaW5ncyB3aXRoaW4gYSBsaXN0IGVudHJ5LCBhbmQg YXBwZWFyIGluIHRoZSBvcmRlciBzcGVjaWZpZWQNCmJ5IHRoZSBkYXRhIG1vZGVsLCB0aGUgb3Jk ZXIgb2YgbWVtYmVycyBpbiBhIEpTT04tZW5jb2RlZCBsaXN0IGVudHJ5DQppcyBhcmJpdHJhcnkg YmVjYXVzZSBKU09OIG9iamVjdHMgYXJlIGZ1bmRhbWVudGFsbHkgdW5vcmRlcmVkDQpjb2xsZWN0 aW9ucyBvZiBtZW1iZXJzLiAiDQoNCg== --_000_BLUPR06MB17631B5C2248C854DFC47906FE480BLUPR06MB1763namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNDg4NjkxODg7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTE4MzE0MDc2IDI2OTAyNTI4 MSAyNjkwMjUyODMgMjY5MDI1Mjg1IDI2OTAyNTI4MSAyNjkwMjUyODMgMjY5MDI1Mjg1IDI2OTAy NTI4MSAyNjkwMjUyODMgMjY5MDI1Mjg1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjExMjU2NjA3NjU7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODEzNDU0MzQg MjY5MDI1MjgxIDI2OTAyNTI4MyAyNjkwMjUyODUgMjY5MDI1MjgxIDI2OTAyNTI4MyAyNjkwMjUy ODUgMjY5MDI1MjgxIDI2OTAyNTI4MyAyNjkwMjUyODU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTU0MzYz ODM2NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE3 OTc5ODE5OCAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1Mjgz IDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NTt9DQpAbGlzdCBsMjpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbmR5IGFuZCB0aGFua3MgZm9yIHlv dXIgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlNlZSBbTVZdIGJlbGxvdyBmb3IgbXkgYW5zd2Vycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkknbGwgd2FpdCBmb3IgeW91ciByZXBseSBiZWZvcmUgYXBwbHlpbmcg YW55IGNoYW5nZXMgdG8gdGhlIGxhdGVzdCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly9jb3JlLXdn LmdpdGh1Yi5pby95YW5nLWNib3IvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci1sYXRlc3QuaHRt bCI+PHNwYW4gbGFuZz0iRU4tQ0EiPmh0dHA6Ly9jb3JlLXdnLmdpdGh1Yi5pby95YW5nLWNib3Iv ZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci1sYXRlc3QuaHRtbDwvc3Bhbj48L2E+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlItQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+TWljaGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6 PC9iPiBNYXktMTYtMTYgNzoxMyBQTTxicj4NCjxiPlRvOjwvYj4gQ29yZSAmbHQ7Y29yZUBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtY29yZS15YW5nLWNib3ItMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhlcmUgYXJlIG15IGNvbW1lbnRzIG9uIHRoZSBZQU5HIHRvIENCT1IgZHJhZnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VjLiAz OiBwYXJhIDQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtUaGUgZW5kIHVzZXIgb2YgdGhpcyBtYXBwaW5nIHNwZWNpZmlj YXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDtjYW4gbWFuZGF0ZSB0aGUgdXNlIG9mIGEgc3BlY2lmaWMga2V5IHR5cGUg b3IgYSBzcGVjaWZpYyBzdWJzZXQgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtrZXkgdHlwZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMxKSAmbmJzcDtIb3cgZG9l cyB0aGUgZW5kLXVzZXIgZG8gdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltNVl08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhlICZxdW90O2VuZCB1c2VyJnF1b3Q7IGluIHRoaXMgY29udGV4dCBpcyB0 eXBpY2FsbHkgYSBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gb3IgZXhhbXBsZSwgZHJh ZnQtdmVpbGxldHRlLWNvcmUtY29vbC0wMSBtYW5kYXRlIFNJRCBhcyBrZXkgdHlwZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlIHNob3VsZCBwcm9iYWJseSB1c2Ugc29t ZXRoaW5nIGVsc2UgdGhhbiAmcXVvdDtlbmQgdXNlciZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DYW4g eW91IHByb3Bvc2UgYSBuZXcgdGV4dCB0byBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgdGhpcyBzZW50 ZW5jZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+NC4yLiZuYnNwOyBUaGUgJnF1b3Q7Y29udGFpbmVyJnF1b3Q7IFNjaGVt YSBOb2RlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDtDb2xsZWN0aW9ucyBzdWNoIGFzIGNvbnRhaW5lcnMsIGxpc3QgaW5z dGFuY2VzLCBub3RpZmljYXRpb25zLCBSUEM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtpbnB1dHMsIFJQQyBvdXRwdXRzLCBh Y3Rpb24gaW5wdXRzIGFuZCBhY3Rpb24gb3V0cHV0cyBNVVNUIGJlIGVuY29kZWQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt1 c2luZyBhIENCT1IgbWFwIGRhdGEgaXRlbSAobWFqb3IgdHlwZSA1KS4mbmJzcDsgQSBtYXAgaXMg Y29tcHJpc2VkIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7cGFpcnMgb2YgZGF0YSBpdGVtcywgd2l0aCBlYWNoIGRhdGEg aXRlbSBjb25zaXN0aW5nIG9mIGEga2V5IGFuZCBhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dmFsdWUuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMyKSBBZGQg YSBjb21tZW50IHRoYXQgJnF1b3Q7a2V5JnF1b3Q7IHJlZmVycyB0byB0aGUgY2hpbGQgbm9kZSBp ZGVudGlmaWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hbmQgdmFsdWUgcmVmZXJzIHRoZSB0aGUgdmFsdWUgb2YgdGhlIGNoaWxkIG5vZGUuIEl0 IGRvZXMgbm90PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5yZWZlciB0byB0aGUgWUFORyB0ZXJtICZxdW90O2tleSZxdW90Oy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPltNVl0gSSBwcm9wb3NpbmcgdG8gYWRkIHRoZSBmb2xsb3dpbmcgdGV4dC4g RmVsbCBmcmVlIHRvIHByb3Bvc2UgYW4gYWx0ZXJuYXRlIHRleHQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mcXVvdDtFYWNoIGtleSB3aXRoaW4gdGhlIENCT1IgbWFwIGlz IHNldCB0byBhIGRhdGEgbm9kZSBpZGVudGlmaWVyLCBlYWNoPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnZhbHVl IGlzIHNldCB0byB0aGUgdmFsdWUgb2YgdGhpcyBkYXRhIG5vZGUgaW5zdGFuY2UuJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWMgNC4yOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7KlNJRHMgYXMg a2V5cyo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO0tleXMgaW1wbGVtZW50ZWQgdXNpbmcgU0lEcyBNVVNUIGJlIGVuY29k ZWQgdXNpbmcgYSBDQk9SIHVuc2lnbmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7aW50ZWdlciAobWFqb3IgdHlwZSAwKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgMm5kIGJ1bGxldDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgRGVsdGEgdmFsdWVzIG1heSByZXN1bHQgaW4gYSBuZWdh dGl2ZSBudW1iZXIsIGNsaWVudHMgYW5kIHNlcnZlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IE1VU1Qgc3Vw cG9ydCBuZWdhdGl2ZSBkZWx0YXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMzKSBEb2Vzbid0IDJuZCBidWxsZXQgcmVxdWlyZSBDQk9S IHR5cGUgMT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U3VtbWFyeTogS0VZIEVOQ09ESU5HICgzIHZhcmlhbnRzKTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtTSUQ6ICZu YnNwOyAmbmJzcDsgTWFqb3IgdHlwZSAwIG9yIDE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtzdHJpbmc6ICZuYnNwO01ham9y IHR5cGUgMzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO2hhc2g6ICZuYnNwOyAmbmJzcDtNYWpvciB0eXBlIDI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01WXSBUaGlzIGlzc3VlIGlz IGFscmVhZHkgZml4ZWQgaW4gdGhlIGxhdGVzdCBkcmFmdCwgc2VlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxhIGhyZWY9Imh0dHA6Ly9jb3JlLXdnLmdpdGh1Yi5pby95YW5nLWNib3IvZHJhZnQtaWV0Zi1j b3JlLXlhbmctY2Jvci1sYXRlc3QuaHRtbCNyZmMuc2VjdGlvbi40LjIiPmh0dHA6Ly9jb3JlLXdn LmdpdGh1Yi5pby95YW5nLWNib3IvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci1sYXRlc3QuaHRt bCNyZmMuc2VjdGlvbi40LjI8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NS4zLiZuYnNwOyBUaGUgJnF1b3Q7 ZGVjaW1hbDY0JnF1b3Q7IFR5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0xlYWZzIG9mIHR5cGUgZGVjaW1hbDY0IE1V U1QgYmUgZW5jb2RlZCB1c2luZyBlaXRoZXIgQ0JPUiB1bnNpZ25lZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2ludGVnZXIg KG1ham9yIHR5cGUgMCkgb3IgQ0JPUiBzaWduZWQgaW50ZWdlciAobWFqb3IgdHlwZSAxKSw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtkZXBlbmRpbmcgb24gdGhlIGFjdHVhbCB2YWx1ZS4mbmJzcDsgVGhlIHBvc2l0aW9uIG9m IHRoZSBkZWNpbWFsIHBvaW50IGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZGVmaW5lZCBieSB0aGUgZnJhY3Rpb24tZGln aXRzIFlBTkcgc3RhdGVtZW50IGFuZCBpcyBub3QgYXZhaWxhYmxlIGluPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dGhlIENC T1IgZW5jb2RpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkM0KSBIb3cgYXJlIGRlY2ltYWw2NCB2YWx1ZXMgdGhhdCBzdGFydCB3aXRoIHpl cm8gZW5jb2RlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwO2xlYWYgZm9vIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBkZWNp bWFsNjQgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZnJhY3Rpb24tZGlnaXRzIDM7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVmYXVsdCAwLjAwNTs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt9PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltNVl0gSWYgSSB1c2UgdGhl IGRlZmF1bHQgdmFsdWUgYXMgZXhhbXBsZSwgdGhlIHZhbHVlIDAuMDA1IGlzIGVuY29kZWQgYXMg MHgwNSBpbiBDQk9SLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBhIHRleHR1YWwgcmVwcmVzZW50YXRp b24gaXMgcmVxdWlyZWQsIHRoZSBsb2dpYyBwZXJmb3JtaW5nIHRoaXMgY29udmVyc2lvbiBuZWVk cyB0byBhZGQgdGhlIGxlYWRpbmcgemVybyhzKSBhbmQgdGhlIGRlY2ltYWwgcG9pbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkM1KSBZb3UgcHJvYmFibHkgbWVhbiB0byBjb252ZXJ0IHRo ZSBkZWNpYW1sNjQgdG8gYSBzaWduZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPm9yIHVuc2lnbmVkIGludGVnZXI6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsxLjAwNSA9 PSAxMDA1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZW4gaXQgaXMgdXAgdG8gdGhlIGRlY29kZXIgdG8ga25vdyB0aGUgWUFORyBzY2hlbWEg c28gaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmNhbiBhZGp1c3QgYmFzZWQgb24gdGhlIGZyYWN0aW9uLWRpZ2l0cyB2YWx1ZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01WXSBDb3JyZWN0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+NS42LiZuYnNwOyBUaGUgJnF1b3Q7ZW51bWVyYXRpb24mcXVvdDsgVHlw ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7TGVhZnMgb2YgdHlwZSBlbnVtZXJhdGlvbiBNVVNUIGJlIGVuY29kZWQgdXNp bmcgYSBDQk9SIHVuc2lnbmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7aW50ZWdlciBkYXRhIGl0ZW0gKG1ham9yIHR5cGUg MCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkM2KSBOZWVkIHRvIHNheSB0aGF0IHRoZSBpbXBsaWNpdCBvciBleHBsaWNpdCB2YWx1ZS1zdG10 IHZhbHVlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5pcyB1c2VkLCBub3QgdGhlIGVudW1lcmF0aW9uIG5hbWUgbGlrZSBpbiBYTUwgb3IgSlNPTjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkM3KSBFbnVtZXJhdGlvbiB2YWx1ZSBpcyBh bGxvd2VkIHRvIGJlIG5lZ2F0aXZlLCBzbyBtYWpvciB0eXBlIDEgYWxzbzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxsb3dlZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTVZdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkNvcnJlY3QgZm9yIGJvdGggY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBmaXJz dCBzZW50ZW5jZSBuZWVkIHRvIGJlIGZpeGVkIGFuZCBhIGNsYXJpZmljYXRpb24gbmVlZCB0byBi ZSBhZGRlZCBhYm91dCB0aGUgYXV0b21hdGljIGFzc2lnbm1lbnQgYWxnb3JpdGhtLiBJIHByb3Bv c2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZx dW90O0xlYWZzIG9mIHR5cGUgZW51bWVyYXRpb24gTVVTVCBiZSBlbmNvZGVkIHVzaW5nIGEgQ0JP UiB1bnNpZ25lZCBpbnRlZ2VyIChtYWpvciB0eXBlIDApIG9yIENCT1Igc2lnbmVkIGludGVnZXIg KG1ham9yIHR5cGUgMSksIGRlcGVuZGluZyBvbiB0aGUgYWN0dWFsIHZhbHVlLg0KIEVudW1lcmF0 aW9uIHZhbHVlcyBhcmUgZWl0aGVyIGV4cGxpY2l0bHkgYXNzaWduZWQgdXNpbmcgdGhlIFlBTkcg c3RhdGVtZW50ICZxdW90O3ZhbHVlJnF1b3Q7IG9yIGF1dG9tYXRpY2FsbHkgYXNzaWduZWQgYmFz ZWQgb24gdGhlIGFsZ29yaXRobSBkZWZpbmVkIGluIFtSRkM2MDIwYmlzc10gc2VjdGlvbiA5LjYu NC4yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41Ljcu Jm5ic3A7IFRoZSAmcXVvdDtiaXRzJnF1b3Q7IFR5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0xlYWZzIG9mIHR5cGUg Yml0cyBNVVNUIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9SIGJ5dGUgc3RyaW5nIGRhdGEgaXRlbTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyhtYWpvciB0eXBlIDIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DOCkgTmVlZCB0byBzYXkgdGhhdCB0aGUgaW1wbGljaXQgb3Ig ZXhwbGljaXQgcG9zaXRpb24tc3RtdCB2YWx1ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgdXNlZCwgbm90IHRoZSBiaXQgbmFtZSBsaWtlIGlu IFhNTCBvciBKU09OPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bTVZdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkNvcnJlY3QsIEkgcHJvcG9zZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZxdW90O0xlYWZzIG9mIHR5cGUgYml0cyBNVVNUIGJlIGVuY29kZWQgdXNpbmcg YSBDQk9SIGJ5dGUgc3RyaW5nIGRhdGEgaXRlbSAobWFqb3IgdHlwZSAyKS4gVGhlIHBvc2l0aW9u IG9mIGVhY2ggYml0IGlzIGVpdGhlciBleHBsaWNpdGx5IGFzc2lnbmVkIHVzaW5nIHRoZSBZQU5H IHN0YXRlbWVudA0KICZxdW90O3Bvc2l0aW9uJnF1b3Q7IG9yIGF1dG9tYXRpY2FsbHkgYXNzaWdu ZWQgYmFzZWQgb24gdGhlIGFsZ29yaXRobSBkZWZpbmVkIGluIFtSRkM2MDIwYmlzc10gc2VjdGlv biA5LjcuNC4yLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NS44LiZuYnNwOyBUaGUgJnF1 b3Q7YmluYXJ5JnF1b3Q7IFR5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0xlYWZzIG9mIHR5cGUgYmluYXJ5IE1VU1Qg YmUgZW5jb2RlZCB1c2luZyBhIENCT1IgYnl0ZSBzdHJpbmcgZGF0YTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2l0ZW0gKG1h am9yIHR5cGUgMikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkM5KSBXaGF0IHN0cmluZyBmb3JtYXQgaXMgdXNlZD8gYmFzZTY0PyByYXcgVVRG LTg/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltNVl0g Tm8gc3BlY2lhbCBmb3JtYXQsIGp1c3QgYmluYXJ5LCBzZWUgZXhhbXBsZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjUuMTIuJm5ic3A7IFRoZSAmcXVvdDt1bmlvbiZxdW90OyBUeXBlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDtMZWFmcyBvZiB0eXBlIHVuaW9uIE1VU1QgYmUgZW5jb2RlZCB1c2luZyB0aGUgcnVsZXMgYXNz b2NpYXRlZCB3aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7b25lIG9mIHRoZSB0eXBlcyBsaXN0ZWQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMxMCkgVGhpcyBkb2Vz IG5vdCByZWFsbHkgd29yayBiZWNhdXNlIHNvIG1hbnkgWUFORyB0eXBlcyB1c2U8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBzYW1lIENCT1Ig bWFqb3IgZW5jb2Rpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3R5cGUgdW5pb24gezxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlw ZSBpbnQzMjs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUgZW51bWVyYXRpb24gezxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGVudW0gQSB7IHZhbHVlIC01OyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW51 bSBCIHsgdmFsdWUgMzsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSBi aXRzIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiaXQgWCB7IHBvc2l0aW9uIDE7IH08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBiaXQgWSB7IHBvc2l0aW9uIDM7IH08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgJm5ic3A7IHR5cGUgZGVjaW1hbDY0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBm cmFjdGlvbi1kaWdpdHMgMjs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkbyBJIGtub3cg aWYgJzMnIGlzIGZvciBpbnQzMiwgZW51bSBCIG9yIGJpdCBZPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGRvIEkga25vdyAxMDMgaXMgcmVh bGx5IGRlY2ltYWw2NCAmcXVvdDsxLjAzJnF1b3Q7IGFuZCBub3Q8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuIGludDMyICZxdW90OzEwMyZxdW90 Oz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01WXSBPdWNoLCB2ZXJ5IGdv b2QgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkknbSBwcm9wb3NpbmcgdG8gdXNlIENCT1IgdGFn cyBmb3IgdGhlIGZvbGxvd2luZyBsaXN0IG9mIGRhdGF0eXBlcyB0byBhdm9pZCB0aGlzIGtpbmQg b2YgYW1iaWd1aXRpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5iaXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPmRlY2ltYWw2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5lbnVtZXJh dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpT eW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pZGVudGl0eXJlZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pbnN0YW5jZS1pZGVudGlmaWVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmxlYWZyZWYmbmJzcDsgKE9ubHkgaWYgaWYg dGhlIGRhdGF0eXBlIG9mIHRoZSByZWZlcmVuY2VkIGxlYWYgcmVxdWlyZSBhIENCT1IgdGFnKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIHRoZSBmb2xsb3dp bmcgbGlzdCBvZiAmbmJzcDtkYXRhdHlwZXMsIHRoZXkgY2FuIGJlIHVzZWQgZGlyZWN0bHkgd2l0 aG91dCBDQk9SIHRhZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPmJpbmFyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5ib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmVtcHR5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmludDg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+aW50MzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aW50NjQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+c3RyaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPnVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PnVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj51aW50MzI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dWludDY0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLS0tLS0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlByb3Bvc2UgdGV4dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkxlYWZzIG9mIHR5cGUgdW5pb24gTVVTVCBiZSBlbmNvZGVkIHVzaW5nIHRoZSBydWxlcyBhc3Nv Y2lhdGVkIHdpdGggb25lIG9mIHRoZSB0eXBlcyBsaXN0ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldo ZW4gdXNlIGluIGEgdW5pb24sIHRoZSBmb2xsb3dpbmcgbGlzdCBvZiBZQU5HIGRhdGF0eXBlcyBh cmUgcHJlZml4ZWQgYnkgQ0JPUiB0YWcgdG8gYXZvaWQgY29uZnVzaW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPmJldHdlZW4gZGlmZmVyZW50IFlBTkcgZGF0YXR5cGVzIGVuY29kZWQgdXNpbmcgdGhlIHNh bWUgQ0JPUiBtYWpvciB0eXBlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+byBiaXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm8gZGVjaW1hbDY0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPm8gZW51bWVyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+byBpZGVudGl0eXJlZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5vIGluc3RhbmNlLWlkZW50aWZpZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+byBsZWFm cmVmJm5ic3A7IChPbmx5IGlmIHRoZSBkYXRhdHlwZSBvZiB0aGUgbGVhZiByZWZlcmVuY2VkIHVz aW5nIHRoZSAmcXVvdDtwYXRoJnF1b3Q7IFlBTkcgc3RhdGVtZW50IHJlcXVpcmUgYSBDQk9SIHRh Zyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlZSBzZWN0aW9u IDcuMSBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBDQk9SIHRhZ3MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjcuJm5i c3A7IElBTkEgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjcuMS4mbmJzcDsgVGFncyBSZWdpc3RyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmUgdGhlIGFzc2ln bm1lbnQgb2YgQ0JPUiB0YWdzIGZvciB0aGUgZm9sbG93aW5nIFlBTkcgZGF0YXR5cGVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGVzZSB0YWdzIGFyZSBhZGRlZCB0byB0aGUgVGFncyBSZWdpc3RyeSBh cyBkZWZpbmVkIGluIHNlY3Rpb24gNy4yIG9mIFJGQyA3MDQ5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+fCBEYXRhIEl0ZW0gfCBTZW1hbnRpY3M8L3NwYW4+PHNw YW4gbGFuZz0iRVMtU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4gfCBSZWZlcmVuY2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+fCBiaXRzIHwgWUFORyBiaXRzIGRhdGF0eXBlIHwgUkZDNjAyMGJpc3Ms IGRyYWZ0LWlldGYtY29yZS15YW5nLWNib3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+fCBkZWNpbWFsNjQg fCBZQU5HIGRlY2ltYWw2NCBkYXRhdHlwZSB8IFJGQzYwMjBiaXNzLCBkcmFmdC1pZXRmLWNvcmUt eWFuZy1jYm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnwgZW51bWVyYXRpb24gfCBZQU5HIGVudW1lcmF0 aW9uIGRhdGF0eXBlIHwgUkZDNjAyMGJpc3MsIGRyYWZ0LWlldGYtY29yZS15YW5nLWNib3I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+fCAmbmJzcDtpZGVudGl0eXJlZiB8IFlBTkcgaWRlbnRpdHlyZWYgZGF0 YXR5cGUgfCBSRkM2MDIwYmlzcywgZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj58IGluc3RhbmNlLWlkZW50aWZpZXIgfCBZQU5HIGluc3RhbmNlLWlkZW50aWZpZXIg ZGF0YXR5cGUgfCBSRkM2MDIwYmlzcywgZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj58ICZuYnNwO2xlYWZyZWYmbmJzcDsgfCBZQU5HIGxlYWZyZWYmbmJzcDsgZGF0 YXR5cGUgfCBSRkM2MDIwYmlzcywgZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QzExKSAmbmJzcDtOZWVk IHRvIHNwZWNpZnkgdGhhdCB0eXBlcyBhcmUgZXZhbHVhdGVkIGluIFlBTkc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0YXRlbWVudCBvcmRlciAo ZS5nLiwgY2hlY2sgaW50MzIsIHRoZW4gZW51bWVyYXRpb24sIHRoZW4gYml0cyk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPltNVl0gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50 IG9yIHByb3Bvc2VkIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+c2VjLiA1LjEzLCBwYXJhIDU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1doZW4gU0lEcyBpZGVudGlmeSBh IFlBTkcgbGlzdCwgdGhlIHByZXNlbmNlIG9mIHRoZSBrZXkocykgZm9yIHRoaXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDts aXN0IGlzIG9wdGlvbmFsLiZuYnNwOyBXaGVuIHRoZSBrZXkocykgYXJlIHByZXNlbnQsIHRoZSB0 YXJnZXRlZCBpbnN0YW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3dpdGhpbiB0aGlzIGxpc3QgaXMgc2VsZWN0ZWQuJm5i c3A7IFdoZW4gdGhlIGtleShzKSBhcmUgYWJzZW50LCB0aGUgZW50aXJlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7WUFORyBs aXN0IGlzIHNlbGVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DMTIpIEEgWUFORyBpbnN0YW5jZS1pZGVudGlmaWVyIE1VU1QgaWRlbnRp ZnkgZXhhY3RseSAxIGluc3RhbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SXQgY2Fubm90IHNwZWNpZnkgYWxsIGluc3RhbmNlcyBvZiBhIFlB TkcgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ W01WXSBUaGUgZGVmaW5pdGlvbiBvZiBhIGxpc3QgaW4gUkZDIDYwMjAgc2VlbSBlZmZlY3RpdmVs eSB0byBiYWNrLXVwIHRoaXMgY29uY2x1c2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mcXVvdDtsaXN0OiBBbiBp bnRlcmlvciBkYXRhIG5vZGUgdGhhdCBtYXkgZXhpc3QgaW4gbXVsdGlwbGUgaW5zdGFuY2VzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pbiB0aGUgZGF0YSB0cmVl LiBBIGxpc3QgaGFzIG5vIHZhbHVlLCBidXQgcmF0aGVyIGEgc2V0IG9mIGNoaWxkIG5vZGVzLiZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXJlIHlvdSBh d2FyZSBvZiBhbnkgb3RoZXIgcGxhY2VzIHdoZXJlIHRoaXMgbGltaXRhdGlvbiBpcyBkZXNjcmli ZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB0aGlzIGlz IHRoZSBjYXNlLCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlcyBuZWVkIHRvIGJlIHJlbW92ZWQgYW5k IHJlLWludHJvZHVjZWQgYXMgZXh0ZW5zaW9uIHdpdGhpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kcmFm dC12ZWlsbGV0dGUtY29yZS1jb29sIHdoZW4gaW5zdGFuY2UtaWRlbnRpZmllcnMgYXJlIHVzZWQg aW4gdGhlIGNvbnRleHQgb2YgdGhlIEZFVENIIG9yIGlQQVRDSCBtZXRob2RzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZxdW90O1doZW4gU0lEcyBp ZGVudGlmeSBhIFlBTkcgbGlzdCwgdGhlIHByZXNlbmNlIG9mIHRoZSBrZXkocykgZm9yIHRoaXMg bGlzdCBpcyBvcHRpb25hbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoZW4gdGhlIGtleShz KSBhcmUgcHJlc2VudCwgdGhlIHRhcmdldGVkIGluc3RhbmNlIHdpdGhpbiB0aGlzIGxpc3QgaXMg c2VsZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGVuIHRoZSBrZXkocykgYXJlIGFi c2VudCwgdGhlIGVudGlyZSBZQU5HIGxpc3QgaXMgc2VsZWN0ZWQuJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk5vdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wgYWxyZWFk eSBhZGQgdHdvIGV4dGVuc2lvbnMgdG8gaW5zdGFuY2UtaWRlbnRpZmllciBpbiB0aGUgY29udGV4 dCBvZiBhIEZFVENIIG9yIGlQQVRDSCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2Ugd2lsbCBuZWVkIHRv IGFkZCBhIHRoaXJkIG9uZS4gSSBzdGlsbCBiZWxpZXZlIHRoYXQgdXNpbmcgaW5zdGFuY2UtaWRl bnRpZmllciBhcyB0aGUgYmFzZSBjb25zdHJ1Y3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Zm9yIEZFVENI IGFuZCBpUEFUQ0ggbWFrZSBzZW5zZSBpbiBvcmRlciB0byBtaW5pbWl6ZSBpbXBsZW1lbnRhdGlv biBmb290cHJpbnQgZXZlbiBpZiBleHRlbnNpb25zIGFyZSBuZWVkZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkMxMykgSWYgaW5zdGFuY2UtaWRlbnRpZmllciB1c2VkIGluIGEgdW5pb24s IG5vIHdheSB0byB0ZWxsIHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNJRCwgbmFtZSwgb3IgaGFzaCBlbmNvZGluZyBpcyByZWFsbHkgYW4g aW5zdGFuY2UtaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YW5kIG5vdCBhIHN0cmluZyBvciBhIG51bWJlci48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01WXSBBZGRyZXNzZWQgYnkgbXkg cHJldmlvdXMgYW5zd2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DMTQpIEhvdyBhcmUg dGhlIGtleXMgc3BlY2lmaWVkPyZuYnNwOyBUaGUgQ29NSSBkcmFmdCBzcGVjaWZpZXMgYSBVUkkg ZW5jb2Rpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmJ1dCBub3RoaW5nIGluIENCT1IuIFNlZW1zIGxpa2UgdGhleSB3b3VsZCBoYXZlIHRvIGJl IGEgc2VwYXJhdGUgc3RyaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4oa2V5cz1BLDE0LGZyZWQpLiZuYnNwOyBFeGFtcGxlcyAoZS5nLiBmb3Ig U0lEKSB1c2luZyBhbiBhcnJheSBhcmUgbm90IGNsZWFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTVZdIFdoZW4ga2V5KHMpIGFyZSBuZWVkZWQgdG8g cXVhbGlmeSB0aGUgaW5zdGFuY2UtaWRlbnRpZmllciwgYSBDQk9SIGFycmF5IGlzIHVzZWQgaW5z dGVhZCBvZiBhIHNpbXBsZSBDQk9SIHVuc2lnbmVkIGludGVnZXIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoZSBmaXJzdCBlbnRyeSB3aXRoaW4gdGhlIENCT1IgYXJyYXkgaXMgdGhlIFNJRCwgdGhlIG5l eHQgZW50cmllcyBhcmUgdGhlIGtleShzKSBlbmNvZGVkIHVzaW5nIHRoZSBydWxlcyBkZWZpbmVk IGZvciB0aGVpciBkYXRhdHlwZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIHRleHQg Y29udmVyc2lvbiByZXF1aXJlIHRvIG1pbmltaXNlIHRoZSBpbXBsZW1lbnRhdGlvbiBmb290cHJp bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZm9sbG93 aW5nIGV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZxdW90Oy9pZXRmLXN5c3RlbTpzeXN0ZW0v YXV0aGVudGljYXRpb24vdXNlcltuYW1lPSdib2InXS9hdXRob3JpemVkLWtleVtuYW1lPSdhZG1p biddL2tleS1kYXRhJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5JcyBlbmNvZGVkIGFzIGZvbGxvdyBpbiBDQk9SOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bMTcy MSwgJnF1b3Q7Ym9iJnF1b3Q7LCAmcXVvdDthZG1pbiZxdW90O108bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNhbiB5b3UgcHJvcG9zZSBleHRyYSB0ZXh0IHdoaWNo IHdpbGwgY2xhcmlmeSB0aGlzIGl0ZW0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0dHJp YnV0ZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkMxNSkgWE1MIGFuZCBZQU5HL0pTT04gYWxsb3cgbWV0YS1kYXRhIHRvIGJlIHNlbnQgd2l0 aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhl IFlBTkcgZGF0YS4gJm5ic3A7KGUuZy4gTkVUQ09ORiAmcXVvdDtvcGVyYXRpb24mcXVvdDsgb3Ig JnF1b3Q7ZGVmYXVsdCZxdW90OyBhdHRyaWJ1dGVzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IHdvdWxkIG1ldGEtZGF0YSBiZSBlbmNvZGVk IGluIENCT1I/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltNVl0gQ2FuIHlvdSBwcm92aWRlIG1lIHNvbWUgcmVmZXJlbmNlIHRvIHRoaXMgdG9waWMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkkgZGlkbid0IGZpbmQgYW55IHJlZmVyZW5jZXMgdG8gJnF1b3Q7b3Bl cmF0aW9uJnF1b3Q7IGFuZCAmcXVvdDtkZWZhdWx0JnF1b3Q7IGluICZxdW90O2RyYWZ0LWlldGYt bmV0bW9kLXlhbmctanNvbiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZQU5HIExp c3QgS2V5czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QzE2KSBYTUwgYW5kIFlBTkcvSlNPTiByZXF1aXJlIFlBTkcgbGlzdCBrZXlzIHRvIGJl IGVuY29kZWQgZmlyc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmV2ZW4gaWYgdGhleSBhcmUgbm90IGRlZmluZWQgZmlyc3QgaW4gdGhlIGxpc3Qu Jm5ic3A7IFRoaXMgYWxsb3dzIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29kZSB0byBkaXNwYXRjaCBvciBkbyBlbnRyeSBsb29rdXAg d2l0aG91dCByZXF1aXJpbmcgYnVmZmVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hvdWxkIENCT1IgZW5jb2Rpbmcgb2YgWUFORyBsaXN0 cyByZXF1aXJlIHRoZSBzYW1lPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5b TVZdIFRoaXMgaXMgbm90IHBvc3NpYmxlIGZvciBib3RoIEpTT04gYW5kIENCT1IuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoZSBvcmRlcmluZyBvZiBpdGVtcyB3aXRoaW4gSlNPTiBvYmplY3RzIG9yIENC T1IgbWFwcyBhcmUgYXJiaXRyYXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+VGhpcyBpcyBhZGRyZXNzZWQgaW4gJnF1b3Q7ZHJhZnQtaWV0Zi1uZXRtb2QteWFu Zy1qc29uJnF1b3Q7IHNlY3Rpb24gNS40PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mcXVvdDtVbmxpa2UgdGhlIFhNTCBlbmNvZGluZywgd2hlcmUgbGlzdCBrZXlz IGFyZSByZXF1aXJlZCB0byBwcmVjZWRlIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5vdGhlciBzaWJs aW5ncyB3aXRoaW4gYSBsaXN0IGVudHJ5LCBhbmQgYXBwZWFyIGluIHRoZSBvcmRlciBzcGVjaWZp ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+YnkgdGhlIGRhdGEgbW9kZWwsIHRoZSBvcmRlciBvZiBtZW1i ZXJzIGluIGEgSlNPTi1lbmNvZGVkIGxpc3QgZW50cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXMgYXJi aXRyYXJ5IGJlY2F1c2UgSlNPTiBvYmplY3RzIGFyZSBmdW5kYW1lbnRhbGx5IHVub3JkZXJlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5jb2xsZWN0aW9ucyBvZiBtZW1iZXJzLiAmcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BLUPR06MB17631B5C2248C854DFC47906FE480BLUPR06MB1763namp_-- From nobody Tue May 17 13:16:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9DC12D985 for ; Tue, 17 May 2016 13:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvPa5vSf8glu for ; Tue, 17 May 2016 13:16:21 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591FF12D972 for ; Tue, 17 May 2016 13:16:21 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id g133so27480681ywb.2 for ; Tue, 17 May 2016 13:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nQ03lYoKf7JwFn2VaOGoTY6q1xBS1IJOJW1RPtoIces=; b=o4xbF4v8bSCxYzE26YzWp7ZVPDNTx88DkULXtuWLQXswg41aWmIv+AUuTjnrb7AHwg fOf+DjuqBFBUcA9CNnm3+DD32rpjs1FZURIe0GQIZD/Q2OVNo5C+kUqy4NDQGQVtK/B0 qKJgBjUUZLAgj/fM9zvSE3aICaP4iUJXPx26CJY6VS+qO1g1ENL/2EwVa60cfYcguMeJ 5avr82fJd1xFF3ohES3ZYzcr4nJMNoofMd3CpfU9xvAPTv1UpHbcuOxodu8PtJ+Q6L78 o4dyf9STI4y8YNPIKJJDgUNKzXbUX0aETbdyrnwnJUz63OWF1mRuAfbcl+S2BlQ8HC+8 vGZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nQ03lYoKf7JwFn2VaOGoTY6q1xBS1IJOJW1RPtoIces=; b=kx1V200/b2yylreigF89dphbp0cVKjCLZwg5uxhc3AsL4YGs6XZN/mCauF+Bef8vNU 1dHyJDFeT281spkWgD09J7+sKoYIbuunDgu9k/BhT+je/CcP9z+dWwsrYRKMUC5zKhOG qOyBzd7sPEOSF7r5VnZhp0iDaA9t5I1NRIewAmtVc/yQsl1QIiXSi6fIAIjMs0v3yFdI v8IcPksSq0oWFal+mMclNdKF5QrhMLbzQPYn2W/Yu5Z8ttqQhBhceYDat5cO5aOch3Y7 rU88D9z9ly4aknZsnc7fJL9rHv3qRyxOppPaqPLplmwNcdHUo3w2L++cmhir9QuPatgP VnLw== X-Gm-Message-State: AOPr4FXuwKvdM9qvUPd63+s99LW43ghMZqn6Ijp1vap02p3v1mfLe+wPkCeEgB4d9LEBV4mOnSqH70bgx9Jn9g== MIME-Version: 1.0 X-Received: by 10.129.94.85 with SMTP id s82mr1755317ywb.259.1463516180466; Tue, 17 May 2016 13:16:20 -0700 (PDT) Received: by 10.37.44.130 with HTTP; Tue, 17 May 2016 13:16:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 May 2016 13:16:20 -0700 Message-ID: From: Andy Bierman To: Michel Veillette Content-Type: multipart/alternative; boundary=001a1149153a0f845b05330f6ada Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:16:25 -0000 --001a1149153a0f845b05330f6ada Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michel, All of your proposed changes look good. Re (C11): YANG 1.1 already specifies how the union type must be evaluated. (In the order the member types are listed). However, the results may not be the same for all encodings. E.g, type union { type string; type int32; } In XML, the element 42 would match the first type 'string'. In JSON or CBOR, the encoding will specify string vs. integer, so the positive integer 42 would not match type 'string'. { "foo": 42 } { "foo": "42" } This is a problem for internal instrumentation that wants to be encoding-independent, but I do not know what to do about it. We could force a type conversion like XPath, but this seems broken. You should always design a YANG union so the pickiest types are listed first, always make string last. On Tue, May 17, 2016 at 11:00 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy and thanks for your comments. > > See [MV] bellow for my answers. > > > > I'll wait for your reply before applying any changes to the latest draft. > > http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.html > > > > Regards, > > Michel > > > > *From:* core [mailto:core-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* May-16-16 7:13 PM > *To:* Core > *Subject:* [core] Comments on draft-ietf-core-yang-cbor-00 > > > > Hi, > > > > Here are my comments on the YANG to CBOR draft > > > > > > Andy > > > Andy > > > ------------------------------------------- > > > > sec. 3: para 4: > > > > The end user of this mapping specification > > can mandate the use of a specific key type or a specific subset of > > key types. > > > > C1) How does the end-user do this? > > > > [MV] > > The "end user" in this context is typically a specification. > > For example, draft-veillette-core-cool-01 mandate SID as key type. > > > > We should probably use something else than "end user" > > Can you propose a new text to clarify the intent of this sentence? > > > > ----------------------------------------- > > > > 4.2. The "container" Schema Node > > > > Collections such as containers, list instances, notifications, RPC > > inputs, RPC outputs, action inputs and action outputs MUST be encoded > > using a CBOR map data item (major type 5). A map is comprised of > > pairs of data items, with each data item consisting of a key and a > > value. > > > > C2) Add a comment that "key" refers to the child node identifier > > and value refers the the value of the child node. It does not > > refer to the YANG term "key". > > > > [MV] I proposing to add the following text. Fell free to propose an > alternate text. > > > > "Each key within the CBOR map is set to a data node identifier, each > > value is set to the value of this data node instance." > > > > > > ---------------------------------------- > > sec 4.2: > > > > *SIDs as keys* > > > > Keys implemented using SIDs MUST be encoded using a CBOR unsigned > > integer (major type 0) > > > > 2nd bullet: > > Delta values may result in a negative number, clients and servers > > MUST support negative deltas. > > > > > > C3) Doesn't 2nd bullet require CBOR type 1? > > > > Summary: KEY ENCODING (3 variants): > > SID: Major type 0 or 1 > > string: Major type 3 > > hash: Major type 2 > > > > [MV] This issue is already fixed in the latest draft, see > > > http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.html#= rfc.section.4.2 > > > > -------------------------------------------- > > > > 5.3. The "decimal64" Type > > > > Leafs of type decimal64 MUST be encoded using either CBOR unsigned > > integer (major type 0) or CBOR signed integer (major type 1), > > depending on the actual value. The position of the decimal point is > > defined by the fraction-digits YANG statement and is not available in > > the CBOR encoding. > > > > C4) How are decimal64 values that start with zero encoded? > > > > leaf foo { > > type decimal64 { > > fraction-digits 3; > > } > > default 0.005; > > } > > > > [MV] If I use the default value as example, the value 0.005 is encoded as > 0x05 in CBOR. > > If a textual representation is required, the logic performing this > conversion needs to add the leading zero(s) and the decimal point. > > > > C5) You probably mean to convert the deciaml64 to a signed > > or unsigned integer: > > > > 1.005 =3D=3D 1005 > > > > Then it is up to the decoder to know the YANG schema so it > > can adjust based on the fraction-digits value. > > > > [MV] Correct. > > > > --------------------------------------------------- > > > > 5.6. The "enumeration" Type > > > > Leafs of type enumeration MUST be encoded using a CBOR unsigned > > integer data item (major type 0). > > > > C6) Need to say that the implicit or explicit value-stmt value > > is used, not the enumeration name like in XML or JSON > > > > C7) Enumeration value is allowed to be negative, so major type 1 also > > allowed > > > > [MV] > > Correct for both comments. > > The first sentence need to be fixed and a clarification need to be added > about the automatic assignment algorithm. I propose: > > > > "Leafs of type enumeration MUST be encoded using a CBOR unsigned integer > (major type 0) or CBOR signed integer (major type 1), depending on the > actual value. Enumeration values are either explicitly assigned using the > YANG statement "value" or automatically assigned based on the algorithm > defined in [RFC6020biss] section 9.6.4.2. > > > > ------------------------------------------------------ > > > > 5.7. The "bits" Type > > > > Leafs of type bits MUST be encoded using a CBOR byte string data item > > (major type 2). > > > > C8) Need to say that the implicit or explicit position-stmt value > > is used, not the bit name like in XML or JSON > > > > [MV] > > Correct, I propose: > > > > "Leafs of type bits MUST be encoded using a CBOR byte string data item > (major type 2). The position of each bit is either explicitly assigned > using the YANG statement "position" or automatically assigned based on th= e > algorithm defined in [RFC6020biss] section 9.7.4.2." > > > > ------------------------------------------------------ > > > > 5.8. The "binary" Type > > > > Leafs of type binary MUST be encoded using a CBOR byte string data > > item (major type 2). > > > > C9) What string format is used? base64? raw UTF-8? > > > > [MV] No special format, just binary, see example. > > > > ------------------------------------------------------ > > > > 5.12. The "union" Type > > > > Leafs of type union MUST be encoded using the rules associated with > > one of the types listed. > > > > C10) This does not really work because so many YANG types use > > the same CBOR major encoding > > > > type union { > > type int32; > > type enumeration { > > enum A { value -5; } > > enum B { value 3; } > > } > > type bits { > > bit X { position 1; } > > bit Y { position 3; } > > } > > type decimal64 { > > fraction-digits 2; > > } > > } > > > > How do I know if '3' is for int32, enum B or bit Y? > > How do I know 103 is really decimal64 "1.03" and not > > an int32 "103"? > > > > [MV] Ouch, very good point. > > I'm proposing to use CBOR tags for the following list of datatypes to > avoid this kind of ambiguities. > > > > =C2=B7 bits > > =C2=B7 decimal64 > > =C2=B7 enumeration > > =C2=B7 identityref > > =C2=B7 instance-identifier > > =C2=B7 leafref (Only if if the datatype of the referenced leaf re= quire > a CBOR tag) > > > > For the following list of datatypes, they can be used directly without > CBOR tag. > > > > =C2=B7 binary > > =C2=B7 boolean > > =C2=B7 empty > > =C2=B7 int8 > > =C2=B7 int16 > > =C2=B7 int32 > > =C2=B7 int64 > > =C2=B7 string > > =C2=B7 uint8 > > =C2=B7 uint16 > > =C2=B7 uint32 > > =C2=B7 uint64 > > > > ------- > > Propose text: > > > > Leafs of type union MUST be encoded using the rules associated with one o= f > the types listed. > > When use in a union, the following list of YANG datatypes are prefixed by > CBOR tag to avoid confusion > > between different YANG datatypes encoded using the same CBOR major type. > > > > o bits > > o decimal64 > > o enumeration > > o identityref > > o instance-identifier > > o leafref (Only if the datatype of the leaf referenced using the "path" > YANG statement require a CBOR tag) > > > > See section 7.1 for more information about CBOR tags. > > > > ------- > > 7. IANA Considerations > > > > 7.1. Tags Registry > > > > This specification require the assignment of CBOR tags for the following > YANG datatypes. > > These tags are added to the Tags Registry as defined in section 7.2 of RF= C > 7049. > > > > | Data Item | Semantics | Reference > > | bits | YANG bits datatype | RFC6020biss, draft-ietf-core-yang-cbor > > | decimal64 | YANG decimal64 datatype | RFC6020biss, > draft-ietf-core-yang-cbor > > | enumeration | YANG enumeration datatype | RFC6020biss, > draft-ietf-core-yang-cbor > > | identityref | YANG identityref datatype | RFC6020biss, > draft-ietf-core-yang-cbor > > | instance-identifier | YANG instance-identifier datatype | RFC6020biss, > draft-ietf-core-yang-cbor > > | leafref | YANG leafref datatype | RFC6020biss, > draft-ietf-core-yang-cbor > > > > > > C11) Need to specify that types are evaluated in YANG > > statement order (e.g., check int32, then enumeration, then bits) > > > > [MV] I don=E2=80=99t understand this comment or proposed solution. > > > > -------------------------------------------------------- > > > > sec. 5.13, para 5 > > > > When SIDs identify a YANG list, the presence of the key(s) for this > > list is optional. When the key(s) are present, the targeted instance > > within this list is selected. When the key(s) are absent, the entire > > YANG list is selected. > > > > C12) A YANG instance-identifier MUST identify exactly 1 instance. > > It cannot specify all instances of a YANG list. > > > > [MV] The definition of a list in RFC 6020 seem effectively to back-up thi= s > conclusion. > > > > "list: An interior data node that may exist in multiple instances > > in the data tree. A list has no value, but rather a set of child nodes." > > > > Are you aware of any other places where this limitation is described? > > > > If this is the case, the following sentences need to be removed and > re-introduced as extension within > > draft-veillette-core-cool when instance-identifiers are used in the > context of the FETCH or iPATCH methods. > > > > "When SIDs identify a YANG list, the presence of the key(s) for this list > is optional. > > When the key(s) are present, the targeted instance within this list is > selected. > > When the key(s) are absent, the entire YANG list is selected." > > > > Note: > > draft-veillette-core-cool already add two extensions to > instance-identifier in the context of a FETCH or iPATCH, > > we will need to add a third one. I still believe that using > instance-identifier as the base construct > > for FETCH and iPATCH make sense in order to minimize implementation > footprint even if extensions are needed. > > > > C13) If instance-identifier used in a union, no way to tell that > > SID, name, or hash encoding is really an instance-identifier > > and not a string or a number. > > > > [MV] Addressed by my previous answer. > > > > C14) How are the keys specified? The CoMI draft specifies a URI encoding > > but nothing in CBOR. Seems like they would have to be a separate string > > (keys=3DA,14,fred). Examples (e.g. for SID) using an array are not clear= . > > > > [MV] When key(s) are needed to qualify the instance-identifier, a CBOR > array is used instead of a simple CBOR unsigned integer. > > The first entry within the CBOR array is the SID, the next entries are th= e > key(s) encoded using the rules defined for their datatypes. > > There is no text conversion require to minimise the implementation > footprint. > > > > The following example: > > > "/ietf-system:system/authentication/user[name=3D'bob']/authorized-key[nam= e=3D'admin']/key-data" > > > > Is encoded as follow in CBOR: > > [1721, "bob", "admin"] > > > > Can you propose extra text which will clarify this item? > > > > ----------------------------------------------------------- > > > > Attributes: > > > > C15) XML and YANG/JSON allow meta-data to be sent with > > the YANG data. (e.g. NETCONF "operation" or "default" attributes) > > How would meta-data be encoded in CBOR? > > > > [MV] Can you provide me some reference to this topic. > > I didn't find any references to "operation" and "default" in > "draft-ietf-netmod-yang-json" > > > > ----------------------------------------------------------- > > > > YANG List Keys: > > > > C16) XML and YANG/JSON require YANG list keys to be encoded first > > even if they are not defined first in the list. This allows server > > code to dispatch or do entry lookup without requiring buffering. > > Should CBOR encoding of YANG lists require the same? > > > > [MV] This is not possible for both JSON and CBOR. > > The ordering of items within JSON objects or CBOR maps are arbitrary. > > > > This is addressed in "draft-ietf-netmod-yang-json" section 5.4 > > > > "Unlike the XML encoding, where list keys are required to precede any > > other siblings within a list entry, and appear in the order specified > > by the data model, the order of members in a JSON-encoded list entry > > is arbitrary because JSON objects are fundamentally unordered > > collections of members. " > > > --001a1149153a0f845b05330f6ada Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michel,

All of your proposed changes= look good.
Re (C11): YANG 1.1 already specifies how the union ty= pe must be evaluated.
(In the order the member types are listed).=
However, the results may not be the same for all encodings.
<= /div>

E.g,

=C2=A0 =C2=A0type un= ion {
=C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 = =C2=A0 type int32;
=C2=A0 =C2=A0}

In XML= , the element <foo>42</foo> would match the first type 'str= ing'.
In JSON or CBOR, the encoding will specify string vs. i= nteger, so
the positive integer 42 would not match type 'stri= ng'.

=C2=A0 { "foo": 42 }
= =C2=A0 { "foo": "42" }


This is a problem for internal instrumentation that wants to be enc= oding-independent,
but I do not know what to do about it.=C2=A0 W= e could force a type conversion like XPath,
but this seems broken= .

You should always design a YANG union so the pic= kiest types are listed first,
always make string last.
=

On= Tue, May 17, 2016 at 11:00 AM, Michel Veillette <Michel.V= eillette@trilliantinc.com> wrote:

Hi Andy and thanks for your comments.=

See [MV] bellow for my answers.

=C2=A0

I'll wait for your reply before a= pplying any changes to the latest draft.

http://core-wg.github.io/yang-cbor/draft-ietf-co= re-yang-cbor-latest.html

=C2=A0

Regards,=

Michel

=C2=A0

From: = core [mailto:cor= e-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: May-16-16 7:13 PM
To: Core <core= @ietf.org>
Subject: [core] Comments on draft-ietf-core-yang-cbor-00

=C2=A0

Hi,

=C2=A0

Here are my comments on the YANG to CBOR draft

=C2=A0

=C2=A0

Andy

=C2=A0



Andy
=C2=A0
=

=C2=A0

-------------------------------------------

=C2=A0

sec. 3: para 4:

=C2=A0

=C2=A0 =C2=A0The end user of this mapping specificat= ion

=C2=A0 =C2=A0can mandate the use of a specific key t= ype or a specific subset of

=C2=A0 =C2=A0key types.

=C2=A0

C1) =C2=A0How does the end-user do this?

=C2=A0

[MV]

The "end user&quo= t; in this context is typically a specification.

For example, draft-vei= llette-core-cool-01 mandate SID as key type.

=C2=A0

We should probably use= something else than "end user"

Can you propose a new = text to clarify the intent of this sentence?

=C2=A0

-----------------------------------------<= /u>

=C2=A0

4.2.=C2=A0 The "container" Schema Node<= /u>

=C2=A0

=C2=A0 =C2=A0Collections such as containers, list in= stances, notifications, RPC

=C2=A0 =C2=A0inputs, RPC outputs, action inputs and = action outputs MUST be encoded

=C2=A0 =C2=A0using a CBOR map data item (major type = 5).=C2=A0 A map is comprised of

=C2=A0 =C2=A0pairs of data items, with each data ite= m consisting of a key and a

=C2=A0 =C2=A0value.=C2=A0

=C2=A0

C2) Add a comment that "key" refers to the= child node identifier

and value refers the the value of the child node. It= does not

refer to the YANG term "key".

=C2=A0

[MV] I proposing to ad= d the following text. Fell free to propose an alternate text.=

=C2=A0

"Each key within = the CBOR map is set to a data node identifier, each

value is set to the va= lue of this data node instance."

=C2=A0

=C2=A0

----------------------------------------

sec 4.2:

=C2=A0

=C2=A0 =C2=A0*SIDs as keys*

=C2=A0

=C2=A0 =C2=A0Keys implemented using SIDs MUST be enc= oded using a CBOR unsigned

=C2=A0 =C2=A0integer (major type 0)

=C2=A0

=C2=A0 2nd bullet:

=C2=A0 =C2=A0 Delta values may result in a negative = number, clients and servers

=C2=A0 =C2=A0 =C2=A0 MUST support negative deltas.

=C2=A0

=C2=A0

C3) Doesn't 2nd bullet require CBOR type 1?

=C2=A0

Summary: KEY ENCODING (3 variants):

=C2=A0 =C2=A0SID: =C2=A0 =C2=A0 Major type 0 or 1=

=C2=A0 =C2=A0string: =C2=A0Major type 3

=C2=A0 =C2=A0hash: =C2=A0 =C2=A0Major type 2<= u>

=C2=A0

[MV] This issue is already fixed in t= he latest draft, see

http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.= html#rfc.section.4.2

=C2=A0

--------------------------------------------<= u>

=C2=A0

5.3.=C2=A0 The "decimal64" Type<= /u>

=C2=A0

=C2=A0 =C2=A0Leafs of type decimal64 MUST be encoded= using either CBOR unsigned

=C2=A0 =C2=A0integer (major type 0) or CBOR signed i= nteger (major type 1),

=C2=A0 =C2=A0depending on the actual value.=C2=A0 Th= e position of the decimal point is

=C2=A0 =C2=A0defined by the fraction-digits YANG sta= tement and is not available in

=C2=A0 =C2=A0the CBOR encoding.

=C2=A0

C4) How are decimal64 values that start with zero en= coded?

=C2=A0

=C2=A0 =C2=A0leaf foo {

=C2=A0 =C2=A0 =C2=A0type decimal64 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0fraction-digits 3;=

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0default 0.005;

=C2=A0 =C2=A0}

=C2=A0

[MV] If I use the default value as ex= ample, the value 0.005 is encoded as 0x05 in CBOR.

If a textual representation is requir= ed, the logic performing this conversion needs to add the leading zero(s) a= nd the decimal point.

=C2=A0

C5) You probably mean to convert the deciaml64 to a = signed

or unsigned integer:

=C2=A0

=C2=A0 =C2=A01.005 =3D=3D 1005

=C2=A0

Then it is up to the decoder to know the YANG schema= so it

can adjust based on the fraction-digits value.

=C2=A0

[MV] Correct.

=C2=A0

---------------------------------------------------<= u>

=C2=A0

5.6.=C2=A0 The "enumeration" Type

=C2=A0

=C2=A0 =C2=A0Leafs of type enumeration MUST be encod= ed using a CBOR unsigned

=C2=A0 =C2=A0integer data item (major type 0).

=C2=A0

C6) Need to say that the implicit or explicit value-= stmt value

is used, not the enumeration name like in XML or JSO= N

=C2=A0

C7) Enumeration value is allowed to be negative, so = major type 1 also

allowed

=C2=A0

[MV]

Correct for both comments.<= /u>

The first sentence need to be fixed a= nd a clarification need to be added about the automatic assignment algorith= m. I propose:

=C2=A0

"Leafs of type enumeration MUST = be encoded using a CBOR unsigned integer (major type 0) or CBOR signed inte= ger (major type 1), depending on the actual value. Enumeration values are either explicitly assigned using the YANG statement= "value" or automatically assigned based on the algorithm defined= in [RFC6020biss] section 9.6.4.2.

=C2=A0

----------------------------------------------------= --

=C2=A0

5.7.=C2=A0 The "bits" Type

=C2=A0

=C2=A0 =C2=A0Leafs of type bits MUST be encoded usin= g a CBOR byte string data item

=C2=A0 =C2=A0(major type 2).

=C2=A0

C8) Need to say that the implicit or explicit positi= on-stmt value

is used, not the bit name like in XML or JSON=

=C2=A0

[MV]

Correct, I propose:

=C2=A0

"Leafs of type bits MUST be enco= ded using a CBOR byte string data item (major type 2). The position of each= bit is either explicitly assigned using the YANG statement "position" or automatically assigned based on the algorithm defi= ned in [RFC6020biss] section 9.7.4.2."

=C2=A0

----------------------------------------------------= --

=C2=A0

5.8.=C2=A0 The "binary" Type=

=C2=A0

=C2=A0 =C2=A0Leafs of type binary MUST be encoded us= ing a CBOR byte string data

=C2=A0 =C2=A0item (major type 2).

=C2=A0

C9) What string format is used? base64? raw UTF-8?

=C2=A0

[MV] No special format, just binary, = see example.

=C2=A0

----------------------------------------------------= --

=C2=A0

5.12.=C2=A0 The "union" Type=

=C2=A0

=C2=A0 =C2=A0Leafs of type union MUST be encoded usi= ng the rules associated with

=C2=A0 =C2=A0one of the types listed.<= /p>

=C2=A0

C10) This does not really work because so many YANG = types use

the same CBOR major encoding

=C2=A0

=C2=A0 =C2=A0type union {

=C2=A0 =C2=A0 =C2=A0 type int32;

=C2=A0 =C2=A0 =C2=A0 type enumeration {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum A { value -5; }<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum B { value 3; }

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 type bits {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 bit X { position 1; }=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 bit Y { position 3; }=

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 type decimal64 {<= /p>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 fraction-digits 2;

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0}

=C2=A0

How do I know if '3' is for int32, enum B or= bit Y?

How do I know 103 is really decimal64 "1.03&quo= t; and not

an int32 "103"?

=C2=A0

[MV] Ouch, very good point.=

I'm proposing to use CBOR tags fo= r the following list of datatypes to avoid this kind of ambiguities.=

=C2=A0

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bits

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 decimal64

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enumeration=

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref=

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 instance-identifier

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leafref=C2=A0 (Only if if the da= tatype of the referenced leaf require a CBOR tag)

=C2=A0

For the following list of =C2=A0datat= ypes, they can be used directly without CBOR tag.

=C2=A0

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 binary

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int8

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int16

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int32

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int64

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint8

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint16

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint32

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint64

=C2=A0

-------<= /span>

Propose text:

=C2=A0

Leafs of type union MUST be encoded u= sing the rules associated with one of the types listed.

When use in a union, the following li= st of YANG datatypes are prefixed by CBOR tag to avoid confusion<= /u>

between different YANG datatypes enco= ded using the same CBOR major type.

=C2=A0

o bits

o decimal64

o enumeration

o identityref

o instance-identifier

o leafref=C2=A0 (Only if the datatype= of the leaf referenced using the "path" YANG statement require a= CBOR tag)

=C2=A0

See section 7.1 for more information = about CBOR tags.

=C2=A0

-------<= /span>

7.=C2=A0 IANA Considerations

=C2=A0

7.1.=C2=A0 Tags Registry

=C2=A0

This specification require the assign= ment of CBOR tags for the following YANG datatypes.

These tags are added to the Tags Regi= stry as defined in section 7.2 of RFC 7049.

=C2=A0

| Data Item | Semantics | Reference

| bits | YANG bits datatype | RFC6020= biss, draft-ietf-core-yang-cbor

| decimal64 | YANG decimal64 datatype= | RFC6020biss, draft-ietf-core-yang-cbor

| enumeration | YANG enumeration data= type | RFC6020biss, draft-ietf-core-yang-cbor

| =C2=A0identityref | YANG identityre= f datatype | RFC6020biss, draft-ietf-core-yang-cbor

| instance-identifier | YANG instance= -identifier datatype | RFC6020biss, draft-ietf-core-yang-cbor=

| =C2=A0leafref=C2=A0 | YANG leafref= =C2=A0 datatype | RFC6020biss, draft-ietf-core-yang-cbor

=C2=A0

=C2=A0

C11) =C2=A0Need to specify that types are evaluated = in YANG

statement order (e.g., check int32, then enumeration= , then bits)

=C2=A0

[MV] I don=E2=80=99t understand this = comment or proposed solution.

=C2=A0

----------------------------------------------------= ----

=C2=A0

sec. 5.13, para 5

=C2=A0

=C2=A0 =C2=A0When SIDs identify a YANG list, the pre= sence of the key(s) for this

=C2=A0 =C2=A0list is optional.=C2=A0 When the key(s)= are present, the targeted instance

=C2=A0 =C2=A0within this list is selected.=C2=A0 Whe= n the key(s) are absent, the entire

=C2=A0 =C2=A0YANG list is selected.

=C2=A0

C12) A YANG instance-identifier MUST identify exactl= y 1 instance.

It cannot specify all instances of a YANG list.

=C2=A0

[MV] The definition of a list in RFC = 6020 seem effectively to back-up this conclusion.

=C2=A0

"list= : An interior data node that may exist in multiple instances<= /span>

in the dat= a tree. A list has no value, but rather a set of child nodes."<= u>

=C2=A0

Are you aware of any other places whe= re this limitation is described?

=C2=A0

If this is the case, the following se= ntences need to be removed and re-introduced as extension within<= /u>

draft-veillette-core-cool when instan= ce-identifiers are used in the context of the FETCH or iPATCH methods.

=C2=A0

"When SIDs identify a YANG list, the presence of the= key(s) for this list is optional.

When the key(s) are present, the targeted instance within= this list is selected.

When the key(s) are absent, the entire YANG list is selec= ted."

= =C2=A0

Note:

draft-veillette-core-cool already add= two extensions to instance-identifier in the context of a FETCH or iPATCH,=

we will need to add a third one. I st= ill believe that using instance-identifier as the base construct<= /u>

for FETCH and iPATCH make sense in or= der to minimize implementation footprint even if extensions are needed.<= /u>

=C2=A0

C13) If instance-identifier used in a union, no way = to tell that

SID, name, or hash encoding is really an instance-id= entifier

and not a string or a number.

=C2=A0

[MV] Addressed by my previous answer.=

=C2=A0

C14) How are the keys specified?=C2=A0 The CoMI draf= t specifies a URI encoding

but nothing in CBOR. Seems like they would have to b= e a separate string

(keys=3DA,14,fred).=C2=A0 Examples (e.g. for SID) us= ing an array are not clear.

=C2=A0

[MV] When key(s) are needed to qualif= y the instance-identifier, a CBOR array is used instead of a simple CBOR un= signed integer.

The first entry within the CBOR array= is the SID, the next entries are the key(s) encoded using the rules define= d for their datatypes.

There is no text conversion require t= o minimise the implementation footprint.

=C2=A0

The following example:<= /span>

"/ietf-system:system/authenticat= ion/user[name=3D'bob']/authorized-key[name=3D'admin']/key-d= ata"

=C2=A0

Is encoded as follow in CBOR:<= u>

[1721, "bob", "admin&q= uot;]

=C2=A0

Can you propose extra text which will= clarify this item?

=C2=A0

----------------------------------------------------= -------

=C2=A0

Attributes:

=C2=A0

C15) XML and YANG/JSON allow meta-data to be sent wi= th

the YANG data. =C2=A0(e.g. NETCONF "operation&q= uot; or "default" attributes)

How would meta-data be encoded in CBOR?

=C2=A0

[MV] Can you provide me some referenc= e to this topic.

I didn't find any references to &= quot;operation" and "default" in "draft-ietf-netmod-yan= g-json"

=C2=A0

----------------------------------------------------= -------

=C2=A0

YANG List Keys:

=C2=A0

C16) XML and YANG/JSON require YANG list keys to be = encoded first

even if they are not defined first in the list.=C2= =A0 This allows server

code to dispatch or do entry lookup without requirin= g buffering.

Should CBOR encoding of YANG lists require the same?=

=C2=A0

[MV] This is not possible for both JS= ON and CBOR.

The ordering of items within JSON obj= ects or CBOR maps are arbitrary.

=C2=A0

This is addressed in "draft-ietf= -netmod-yang-json" section 5.4

=C2=A0

"Unlike the XML encoding, where = list keys are required to precede any

other siblings within a list entry, a= nd appear in the order specified

by the data model, the order of membe= rs in a JSON-encoded list entry

is arbitrary because JSON objects are= fundamentally unordered

collections of members. "=

=C2=A0


--001a1149153a0f845b05330f6ada-- From nobody Tue May 17 14:32:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC90F12D1E0 for ; Tue, 17 May 2016 14:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5esJAfuETmEG for ; Tue, 17 May 2016 14:32:35 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE84B12D9D1 for ; Tue, 17 May 2016 14:32:34 -0700 (PDT) Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 58737FB8B1; Tue, 17 May 2016 23:32:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ZZ4WSa9rxDhD; Tue, 17 May 2016 23:32:31 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 33D39FB8B8; Tue, 17 May 2016 23:32:29 +0200 (CEST) Message-ID: <573B8DEC.7040507@tzi.org> Date: Tue, 17 May 2016 23:32:28 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Andy Bierman References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:32:37 -0000 Andy Bierman wrote: > but this seems broken. Ouch. I would have said the breakage is clearly on the XML side, except that we have the same problem between, say, integer and decimal64. I think the breakage we really need to avoid is where XML can tell the types apart and the CBOR mapping cannot. Is there such a case? Grüße, Carsten From nobody Tue May 17 14:42:00 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C542212DB17 for ; Tue, 17 May 2016 14:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui73VFtue_L3 for ; Tue, 17 May 2016 14:41:57 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D11712DA42 for ; Tue, 17 May 2016 14:41:57 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g133so29688912ywb.2 for ; Tue, 17 May 2016 14:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8x3M6M9HEjSvFrWnYoS7WhxMByrtbRujn/E2i36SOc0=; b=tSeo78P4Pl0z8xqNpeAooP/MykMvvzkXAqOOMnNm5RY3fDUlAveUjQMeztBkikUFE6 JjZdZ90jk7+HP2YpLI1+AG4dtUnxKUw9sqH+CLsCfurKzH0gp5hpeXw8hIcHlJfPwBdL Sr7yfiWcSdvZnest5F3KV/NFtmhtaibOqbuqFzT9X3hzGDA26/FAx+PkH4VAICU5NOel Lb7V+SfhgJH3SB5OxU1nYCAS5KarTi9kpNJjsShlQqxGO99MbR+8eiSfmA2e6lAcpTVp hTDAitoExufk9w0voQP0GQSf/X8sqtKCzpnv7obLHMZPb8HXVTRF6vTCpU6R0lK+zCt5 NHOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8x3M6M9HEjSvFrWnYoS7WhxMByrtbRujn/E2i36SOc0=; b=iGcW6ojYNTQMq+tC3v0L+RAKdT3BZZ0PhRFHdOmkvb8GpedgXX1X+DbYJyDEg8zQFm 58f0wL1TNkeEUO8d+o8E7MBo7qWVqWAD2JvHQlyJ6VDKx1QYWougqs4/X8f7qPBwQyYX RP1VKJKA6W+OmZ1qjcSmzkZsGC7KbUAosi7Vw5Yr5JhHPyGcl/Mj0hpCeR0VdIyYKuiN PC+zBA8i5b4CnOQAHcHn/WEJgCTnV9LIzUYfDZmUIIx92gYPVDDT4aKRxIFFWdvOjCWq ZbV6h9mHO+pFqCHST5oRDTKlQlXMf6y2j8eBYPadHpKOBvhAFcQST3evBg9fPqGHGeMX bSLA== X-Gm-Message-State: AOPr4FUo/RGKLCp6lxaJLchsD/qc8KIKecHX58VibSL14y/H999fC1ya8QMrs/Jk2/vbxj/uM/A2OuQhrSn37A== MIME-Version: 1.0 X-Received: by 10.129.137.129 with SMTP id z123mr2172561ywf.101.1463521316792; Tue, 17 May 2016 14:41:56 -0700 (PDT) Received: by 10.37.44.130 with HTTP; Tue, 17 May 2016 14:41:56 -0700 (PDT) In-Reply-To: <573B8DEC.7040507@tzi.org> References: <573B8DEC.7040507@tzi.org> Date: Tue, 17 May 2016 14:41:56 -0700 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: multipart/alternative; boundary=94eb2c06bf3835cd930533109ca0 Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:41:59 -0000 --94eb2c06bf3835cd930533109ca0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 17, 2016 at 2:32 PM, Carsten Bormann wrote: > Andy Bierman wrote: > > but this seems broken. > > Ouch. > > I would have said the breakage is clearly on the XML side, except that > we have the same problem between, say, integer and decimal64. > > I think the breakage we really need to avoid is where XML can tell the > types apart and the CBOR mapping cannot. Is there such a case? > > No, I think the problems are with XML. There are a few derived types like "xpath1.0" in ietf-yang-types.yang that rely on prefix to namespace mappings that cannot be represented in CBOR, but I think the base types are OK. Gr=C3=BC=C3=9Fe, Carsten > Andy --94eb2c06bf3835cd930533109ca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 17, 2016 at 2:32 PM, Carsten Bormann <= cabo@tzi.org> wrote:
Andy Bierman wrote:
> but this seems broken.

Ouch.

I would have said the breakage is clearly on the XML side, except that
we have the same problem between, say, integer and decimal64.

I think the breakage we really need to avoid is where XML can tell the
types apart and the CBOR mapping cannot.=C2=A0 Is there such a case?


No, I think the problems are with XML.=
There are a few derived types like "xpath1.0" in ietf-= yang-types.yang
that rely on prefix to namespace mappings that ca= nnot be represented in CBOR,
but I think the base types are OK.



Gr=C3=BC=C3=9Fe, Carsten

Andy

--94eb2c06bf3835cd930533109ca0-- From nobody Tue May 17 20:19:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA7012DA23 for ; Tue, 17 May 2016 20:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySFUoqF6ninR for ; Tue, 17 May 2016 20:19:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960C912D89C for ; Tue, 17 May 2016 20:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e3H0tPcA+1mVRo+27VeVsn3+GArmYBvIknuMEQKp9MA=; b=TWhASohGgL57ug2YvZiOXb+9yr3wY0Zhv6bNTYai+o2iooX64dhGxkAqhkdi9AfEWyd1LBuZxMKy+hvDoewWfi7uTwe00MjplxJBNxg5MHKzvNXsKzr+3s3LLOKlZWLvK0/duewVF3r0rnYWah1Sm2P1LoTmRjbnddZeuheLXH8= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 03:19:29 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0497.019; Wed, 18 May 2016 03:19:29 +0000 From: Michel Veillette To: Andy Bierman , Carsten Bormann Thread-Topic: [core] Comments on draft-ietf-core-yang-cbor-00 Thread-Index: AQHRr8iPxRSRAjhbgEmS2wWjXvPI7Z+9MAuAgABiVwCAABVFAIAAAqUAgABaraA= Date: Wed, 18 May 2016 03:19:29 +0000 Message-ID: References: <573B8DEC.7040507@tzi.org> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [24.225.215.88] x-ms-office365-filtering-correlation-id: 181cdc05-3a79-4e52-de5f-08d37ecb3967 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:9Uh+hO/SG2rUNuugnhWatESnisnUN8Jty29XByNytHIYqB6eUA9l71lMDdUsvergOs5M85qzMUHXvYI61mJGAvV2qwrYxYKkjdhWQJV7dhqZc3enOYDM9QNJEoC6oJLcBilOoDEZqnRxUAN5yfbHzg==; 24:D/aIJa7OTa5SrWxnN8ShcHIc3sc2zeiF07d/Pv4F/s+8wGktpWHBMwPJWcpKWx4pbVmGkPMOJgJJq9Foly7O1L5gT16f8yMUqI5sUkBDBiA=; 7:W60EEOxcgOWyV8PJAK51JVr3O4GFGERu3S2rpSSIq4HkfkIkeCJek3WABCAJH/+G6G0W7iPfEyYB7v9XcVDuTFmNGjK04wot8t0YBJndICWtU6f1caKl6Xu3tMf8e94NgTQWHaCr/M2+GCJEVAQZVvrT+fLID1PZuho3t//0DgqLpo68YLjdhU3hLOAOdkPo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(43784003)(24454002)(377454003)(5004730100002)(11100500001)(9686002)(10400500002)(93886004)(66066001)(92566002)(86362001)(99286002)(106116001)(74316001)(76576001)(5003600100002)(2950100001)(2900100001)(19617315012)(54356999)(50986999)(5001770100001)(15975445007)(76176999)(5002640100001)(189998001)(16236675004)(5008740100001)(4326007)(19300405004)(2906002)(77096005)(81166006)(87936001)(8936002)(8676002)(586003)(102836003)(790700001)(6116002)(3846002)(1220700001)(19580395003)(19625215002)(230783001)(122556002)(19580405001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR06MB1763976139D6ABCB8FF010B0FE490BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 03:19:29.0941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 03:19:51 -0000 --_000_BLUPR06MB1763976139D6ABCB8FF010B0FE490BLUPR06MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpUaGUgZHJhZnQgaGF2ZSBiZWVuIHVwZGF0ZWQgdG8gYWRkcmVzcyB5b3VyIGNv bW1lbnRzLg0KDQpEaWZmIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L3lhbmctY2Jvci9jb21taXQvYzUwYjY4NDBmNGM4N2EwMDQxZTRhNDFjZjA1YTA5Mjc4Yzk5YTVh OA0KTGF0ZXN0IGRvY3VtZW50IGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly9jb3JlLXdnLmdpdGh1Yi5p by95YW5nLWNib3IvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci1sYXRlc3QuaHRtbA0KDQpUaGFu a3MgYWdhaW4gZm9yIHJldmlld2luZyB0aGlzIGRyYWZ0Lg0KDQpNaWNoZWwNCg0KRnJvbTogQW5k eSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogTWF5LTE3LTE2IDU6 NDIgUE0NClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCkNjOiBNaWNoZWwgVmVp bGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+OyBDb3JlIDxjb3JlQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvcmUt eWFuZy1jYm9yLTAwDQoNCg0KDQpPbiBUdWUsIE1heSAxNywgMjAxNiBhdCAyOjMyIFBNLCBDYXJz dGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4gd3JvdGU6DQpB bmR5IEJpZXJtYW4gd3JvdGU6DQo+IGJ1dCB0aGlzIHNlZW1zIGJyb2tlbi4NCg0KT3VjaC4NCg0K SSB3b3VsZCBoYXZlIHNhaWQgdGhlIGJyZWFrYWdlIGlzIGNsZWFybHkgb24gdGhlIFhNTCBzaWRl LCBleGNlcHQgdGhhdA0Kd2UgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtIGJldHdlZW4sIHNheSwgaW50 ZWdlciBhbmQgZGVjaW1hbDY0Lg0KDQpJIHRoaW5rIHRoZSBicmVha2FnZSB3ZSByZWFsbHkgbmVl ZCB0byBhdm9pZCBpcyB3aGVyZSBYTUwgY2FuIHRlbGwgdGhlDQp0eXBlcyBhcGFydCBhbmQgdGhl IENCT1IgbWFwcGluZyBjYW5ub3QuICBJcyB0aGVyZSBzdWNoIGEgY2FzZT8NCg0KTm8sIEkgdGhp bmsgdGhlIHByb2JsZW1zIGFyZSB3aXRoIFhNTC4NClRoZXJlIGFyZSBhIGZldyBkZXJpdmVkIHR5 cGVzIGxpa2UgInhwYXRoMS4wIiBpbiBpZXRmLXlhbmctdHlwZXMueWFuZw0KdGhhdCByZWx5IG9u IHByZWZpeCB0byBuYW1lc3BhY2UgbWFwcGluZ3MgdGhhdCBjYW5ub3QgYmUgcmVwcmVzZW50ZWQg aW4gQ0JPUiwNCmJ1dCBJIHRoaW5rIHRoZSBiYXNlIHR5cGVzIGFyZSBPSy4NCg0KDQoNCkdyw7zD n2UsIENhcnN0ZW4NCg0KQW5keQ0KDQo= --_000_BLUPR06MB1763976139D6ABCB8FF010B0FE490BLUPR06MB1763namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1D QSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbmR5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo ZSBkcmFmdCBoYXZlIGJlZW4gdXBkYXRlZCB0byBhZGRyZXNzIHlvdXIgY29tbWVudHMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkRpZmYgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUt d2cveWFuZy1jYm9yL2NvbW1pdC9jNTBiNjg0MGY0Yzg3YTAwNDFlNGE0MWNmMDVhMDkyNzhjOTlh NWE4Ij5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy95YW5nLWNib3IvY29tbWl0L2M1MGI2ODQw ZjRjODdhMDA0MWU0YTQxY2YwNWEwOTI3OGM5OWE1YTg8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5MYXRlc3QgZG9jdW1lbnQgYXZh aWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cDovL2NvcmUtd2cuZ2l0aHViLmlvL3lhbmctY2Jvci9k cmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLWxhdGVzdC5odG1sIj5odHRwOi8vY29yZS13Zy5naXRo dWIuaW8veWFuZy1jYm9yL2RyYWZ0LWlldGYtY29yZS15YW5nLWNib3ItbGF0ZXN0Lmh0bWw8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlRoYW5rcyBhZ2FpbiBmb3IgcmV2aWV3aW5nIHRoaXMgZHJhZnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pk1pY2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTWF5LTE3LTE2IDU6NDIgUE08YnI+DQo8Yj5U bzo8L2I+IENhcnN0ZW4gQm9ybWFubiAmbHQ7Y2Fib0B0emkub3JnJmd0Ozxicj4NCjxiPkNjOjwv Yj4gTWljaGVsIFZlaWxsZXR0ZSAmbHQ7TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29t Jmd0OzsgQ29yZSAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLTAwPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIFR1ZSwgTWF5IDE3LCAyMDE2IGF0IDI6MzIgUE0sIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5BbmR5IEJpZXJtYW4gd3JvdGU6PGJyPg0KJmd0OyBidXQgdGhpcyBzZWVtcyBicm9rZW4u PGJyPg0KPGJyPg0KT3VjaC48YnI+DQo8YnI+DQpJIHdvdWxkIGhhdmUgc2FpZCB0aGUgYnJlYWth Z2UgaXMgY2xlYXJseSBvbiB0aGUgWE1MIHNpZGUsIGV4Y2VwdCB0aGF0PGJyPg0Kd2UgaGF2ZSB0 aGUgc2FtZSBwcm9ibGVtIGJldHdlZW4sIHNheSwgaW50ZWdlciBhbmQgZGVjaW1hbDY0Ljxicj4N Cjxicj4NCkkgdGhpbmsgdGhlIGJyZWFrYWdlIHdlIHJlYWxseSBuZWVkIHRvIGF2b2lkIGlzIHdo ZXJlIFhNTCBjYW4gdGVsbCB0aGU8YnI+DQp0eXBlcyBhcGFydCBhbmQgdGhlIENCT1IgbWFwcGlu ZyBjYW5ub3QuJm5ic3A7IElzIHRoZXJlIHN1Y2ggYSBjYXNlPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vLCBJIHRoaW5rIHRoZSBwcm9i bGVtcyBhcmUgd2l0aCBYTUwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGFyZSBhIGZldyBk ZXJpdmVkIHR5cGVzIGxpa2UgJnF1b3Q7eHBhdGgxLjAmcXVvdDsgaW4gaWV0Zi15YW5nLXR5cGVz Lnlhbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhhdCByZWx5IG9uIHByZWZpeCB0byBuYW1lc3Bh Y2UgbWFwcGluZ3MgdGhhdCBjYW5ub3QgYmUgcmVwcmVzZW50ZWQgaW4gQ0JPUiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+YnV0IEkgdGhpbmsgdGhlIGJhc2UgdHlwZXMgYXJlIE9LLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HcsO8w59lLCBDYXJz dGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BLUPR06MB1763976139D6ABCB8FF010B0FE490BLUPR06MB1763namp_-- From nobody Wed May 18 06:56:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FDA12D1DC for ; Wed, 18 May 2016 06:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4RvmajM4woy for ; Wed, 18 May 2016 06:56:01 -0700 (PDT) Received: from smtp-in1.interdigital.com (unknown [68.168.94.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C701F12D0A3 for ; Wed, 18 May 2016 06:56:00 -0700 (PDT) X-ASG-Debug-ID: 1463579756-06daaa108eaeb90001-aa7cYp Received: from NALENITE.InterDigital.com (nalenite.interdigital.com [10.2.64.253]) by smtp-in1.interdigital.com with ESMTP id zSbifbrjiyXNNyGs (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 May 2016 09:55:58 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0279.002; Wed, 18 May 2016 09:55:57 -0400 From: "Rahman, Akbar" To: "cabo@tzi.org" , "jaime.jimenez@ericsson.com" Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-ASG-Orig-Subj: RE: [core] I-D Action: draft-ietf-core-http-mapping-10.txt Thread-Index: AQHRrR0WzJNnBq5QE0q4cwryK3YZrp+24c9ggAfdY7A= Date: Wed, 18 May 2016 13:55:56 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BABBC1B@NABESITE.InterDigital.com> References: <20160513134033.10520.69223.idtracker@ietfa.amsl.com> <36F5869FE31AB24485E5E3222C288E1F5BAB947B@NABESITE.InterDigital.com> In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BAB947B@NABESITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.107] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nalenite.interdigital.com[10.2.64.253] X-Barracuda-Start-Time: 1463579757 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 3990 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29692 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 13:56:05 -0000 Hi Carsten/Jamie, Just resending this email as I believe the first time it did not get correc= tly to Carsten due to some problem with my mail server. I've been told by = me IST department that the problem has now been fixed so I am resending thi= s request to re-start the WGLC. Thanks, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar Sent: Friday, May 13, 2016 9:51 AM To: cabo@tzi.org; jaime.jimenez@ericsson.com Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt Hi Carsten/Jaime, We have updated the draft to cover the following: Changes from ietf-09 to ietf-10: o Addressed Ticket #401 - Clarified that draft covers not only Reverse HC Proxy but that many parts also apply to Forward and Interception Proxies. o Clarified that draft concentrates on the HTTP-to-CoAP mapping direction (i.e. the HC proxy is a HTTP server and a CoAP client). o Clarified the "null mapping" case where no CoAP URI information is embedded in the HTTP request URI. o Moved multicast related security text to the "Security Considerations" to consolidate all security information in one location. o Removed references to "placement" of proxy (e.g. server-side vs client-side) as is confusing and provides little added value. o Fixed version numbers on references that were corrupted in last revision due to outdated xml2rfc conversion tool local cache. o Various editorial improvements. Can you please review, and start the 2nd WGLC if you think that everything = looks in order. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, May 13, 2016 9:41 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-10.txt 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 of the IE= TF. Title : Guidelines for HTTP-to-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-10.txt Pages : 36 Date : 2016-05-13 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu May 19 04:03:25 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7DD12D928 for ; Thu, 19 May 2016 04:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSPIHuar-42h for ; Thu, 19 May 2016 04:03:21 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE39A12D903 for ; Thu, 19 May 2016 04:03:19 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 19 May 2016 13:03:11 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0266.001; Thu, 19 May 2016 13:03:16 +0200 From: "Kovatsch Matthias" To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNw== Date: Thu, 19 May 2016 11:03:16 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 11:03:24 -0000 Hi Michael I got a question whether it is possible to register multiple endpoints (ep)= from the same (socket) address. The use case is a device/service with mult= iple virtual endpoints or a gateway that provides multiple logical endpoint= s. I did not have the time to test this in my implementation, but this should = be possible out of the box: The same socket address registers each virtual/= logical endpoint with different endpoint names and receives different handl= es (Location-Paths) from the RD. I propose to include an example in the document. Best regards Matthias From nobody Thu May 19 06:00:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0FA12D0E1 for ; Thu, 19 May 2016 06:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC4eubWpiATj for ; Thu, 19 May 2016 06:00:49 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B12712D0B9 for ; Thu, 19 May 2016 06:00:49 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id bt5so28805038pac.3 for ; Thu, 19 May 2016 06:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QELPmJEnLqEgWl6yhmkZ32B7YGySq4IHeI1rYWVyN4c=; b=NUtBv8FyW/ErTHSpb+UnMGSid4AFkhU2Pr4DFNZ4Pb0U9XW+lP1ve2H1VjXb36fqaK qKepPcGOnZM8H/SKLbnDAgiQgMbmO9gpCD7g7A1AAQtoKr5xfHCzbbNrDz1IJz6JLPP5 LKQpJp/B3iYiOXP6IfleAOf7o4bbVhm0l8lc+bbc5ov36L6d0b0LhReAB8DNQIcl7drQ 6/yk1smPYJYkPCM+7/cCLzmiqRYAx5FixZsKgKbmmfLUGKr6Hg+mqs5iSi5T1aMufM7s ywt7Z6m2p96Aevqx7pDHdEvQMNpAZpqX39VzIkskh19OWa/9NXSVBYzLjTgp8OFfdmza CCEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QELPmJEnLqEgWl6yhmkZ32B7YGySq4IHeI1rYWVyN4c=; b=mNU5tsxHG9Z88+Obt6pMOi4xzpz/KndYvu+7S+SnqgA7jReQMTYmRZvYpnnK5H6EyV lvwHJkiE4VlOkXIK6xvSrElh7ciGIB+5bGxMjI6iRWuW+UPsNRk0K2YG84CoPyNh0cXS ovPS3ST1sGZFP1K0l2VDevEIOMJmtob2MEYcW2SLW/oEz9gNZuZGHlzASBewLswHzUmd bj4SUheEkXLjD+/IysCcuhKHWCYDLuFxS31I4VYgk58fVDcggvwT/ZkTl7PczxFVge5u AcBY/y5wE1LqSSzuwDt6i+zA2CFd2Sq45Zvfxs83zoq1pyz1EyTbkhKgiMc9yXQnh1qW Oaqg== X-Gm-Message-State: AOPr4FWAf224vt6GneIreS/uxxhluJGPvdJZxz+rRJnxeVaXtS/+cmJh++ttjptbZeM20g== X-Received: by 10.66.6.35 with SMTP id x3mr19534100pax.135.1463662848887; Thu, 19 May 2016 06:00:48 -0700 (PDT) Received: from [10.0.0.7] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 76sm19869681pfz.44.2016.05.19.06.00.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 May 2016 06:00:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> Date: Thu, 19 May 2016 06:00:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 13:00:54 -0000 Hi Matthias Yes, I believe this should be expected to work, though I have not tested = it with any implementation. The RD should maintain a database by unique endpoint ID with associated = scheme/host/port addressing information that it determines from the = request, or has been set explicitly with con=3D on registration. Of course, if the device registers the same resource in both = registrations, RD would return the same link value. I will make a note to state this explicitly in the RD draft and provide = an example. Best regards, Michael > On May 19, 2016, at 4:03 AM, Kovatsch Matthias = wrote: >=20 > Hi Michael >=20 > I got a question whether it is possible to register multiple endpoints = (ep) from the same (socket) address. The use case is a device/service = with multiple virtual endpoints or a gateway that provides multiple = logical endpoints. >=20 > I did not have the time to test this in my implementation, but this = should be possible out of the box: The same socket address registers = each virtual/logical endpoint with different endpoint names and receives = different handles (Location-Paths) from the RD. >=20 > I propose to include an example in the document. >=20 > Best regards > Matthias From nobody Thu May 19 08:06:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE8112B011 for ; Thu, 19 May 2016 08:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2avdO5er2Q40 for ; Thu, 19 May 2016 08:06:46 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9812D0DE for ; Thu, 19 May 2016 08:06:45 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 19 May 2016 08:05:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,334,1459839600"; d="scan'208";a="980514709" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga002.jf.intel.com with ESMTP; 19 May 2016 08:05:06 -0700 Received: from orsmsx112.amr.corp.intel.com (10.22.240.13) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 19 May 2016 08:05:05 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX112.amr.corp.intel.com ([169.254.3.229]) with mapi id 14.03.0248.002; Thu, 19 May 2016 08:05:05 -0700 From: "Subramaniam, Ravi" To: Michael Koster , Kovatsch Matthias Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WA= Date: Thu, 19 May 2016 15:05:04 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTliZWRiMWMtNjk2My00ZjA3LWJkNmQtYjQzMzcyYTJiMjUxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkJncnF0WjhoR0JmV1FRQjlCeHhUbzhRbnN1SGprcGE4Yjkzc21ZeHR6MGc9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 15:06:51 -0000 Hi Michael/Matthias, Apologies if I am missing the point... There are a couple of ways to interpret the use case that Matthias indicate= s " The use case is a device/service with multiple virtual endpoints or a g= ateway that provides multiple logical endpoints." 1. One is using the "authority" - in which case different "authorities" map= to the same endpoint - using multiple unique endpoint ID (as authority) th= at maps to the same (socket) address. In this case the device/server would = need to register the Resource URIs and then endpoint information for each u= nique endpoint ID.=20 2. The other is to use the "path" - in this case only one endpoint needs to= be registered with RD. The server demuxes on info that the server has embe= dded into the path. Both these should be possible, right? Ravi=20 =20 -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster Sent: Thursday, May 19, 2016 6:01 AM To: Kovatsch Matthias Cc: core@ietf.org WG Subject: Re: [core] draft-ietf-core-resource-directory Hi Matthias Yes, I believe this should be expected to work, though I have not tested it= with any implementation. The RD should maintain a database by unique endpoint ID with associated sch= eme/host/port addressing information that it determines from the request, o= r has been set explicitly with con=3D on registration. Of course, if the device registers the same resource in both registrations,= RD would return the same link value. I will make a note to state this explicitly in the RD draft and provide an = example. Best regards, Michael > On May 19, 2016, at 4:03 AM, Kovatsch Matthias wro= te: >=20 > Hi Michael >=20 > I got a question whether it is possible to register multiple endpoints (e= p) from the same (socket) address. The use case is a device/service with mu= ltiple virtual endpoints or a gateway that provides multiple logical endpoi= nts. >=20 > I did not have the time to test this in my implementation, but this shoul= d be possible out of the box: The same socket address registers each virtua= l/logical endpoint with different endpoint names and receives different han= dles (Location-Paths) from the RD. >=20 > I propose to include an example in the document. >=20 > Best regards > Matthias _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu May 19 10:21:44 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5072812DB09 for ; Thu, 19 May 2016 10:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5kfUtaxz1Bt for ; Thu, 19 May 2016 10:21:40 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1AC12DAF7 for ; Thu, 19 May 2016 10:21:39 -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.3.266.1; Thu, 19 May 2016 19:21:30 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0266.001; Thu, 19 May 2016 19:21:37 +0200 From: "Kovatsch Matthias" To: "Subramaniam, Ravi" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwAAQDgAAARXVAAACLJEEA== Date: Thu, 19 May 2016 17:21:35 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:21:43 -0000 Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints: The server uses the Uri-Path prefixes to multiplex, like= a gateway that translates to another technology and maps different devices= into its resource structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster ; Kovatsch Matthias > > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory >=20 > Hi Michael/Matthias, >=20 > Apologies if I am missing the point... >=20 > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a gat= eway > that provides multiple logical endpoints." >=20 > 1. One is using the "authority" - in which case different "authorities" m= ap to the > same endpoint - using multiple unique endpoint ID (as authority) that map= s to > the same (socket) address. In this case the device/server would need to r= egister > the Resource URIs and then endpoint information for each unique endpoint = ID. > 2. The other is to use the "path" - in this case only one endpoint needs = to be > registered with RD. The server demuxes on info that the server has embedd= ed > into the path. >=20 > Both these should be possible, right? >=20 > Ravi >=20 >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > Cc: core@ietf.org WG > Subject: Re: [core] draft-ietf-core-resource-directory >=20 > Hi Matthias >=20 > Yes, I believe this should be expected to work, though I have not tested = it with > any implementation. >=20 > The RD should maintain a database by unique endpoint ID with associated > scheme/host/port addressing information that it determines from the reque= st, > or has been set explicitly with con=3D on registration. >=20 > Of course, if the device registers the same resource in both registration= s, RD > would return the same link value. >=20 > I will make a note to state this explicitly in the RD draft and provide a= n > example. >=20 > Best regards, >=20 > Michael >=20 > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple endpoints = (ep) from > the same (socket) address. The use case is a device/service with multiple > virtual endpoints or a gateway that provides multiple logical endpoints. > > > > I did not have the time to test this in my implementation, but this sho= uld be > possible out of the box: The same socket address registers each virtual/l= ogical > endpoint with different endpoint names and receives different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu May 19 10:34:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774D312DB21 for ; Thu, 19 May 2016 10:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUEwXoOY5RTT for ; Thu, 19 May 2016 10:34:50 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ietfa.amsl.com (Postfix) with ESMTP id A122212DAFD for ; Thu, 19 May 2016 10:34:47 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP; 19 May 2016 10:34:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,334,1459839600"; d="scan'208";a="958240152" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga001.jf.intel.com with ESMTP; 19 May 2016 10:34:43 -0700 Received: from orsmsx161.amr.corp.intel.com (10.22.240.84) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 19 May 2016 10:34:41 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX161.amr.corp.intel.com ([10.22.240.84]) with mapi id 14.03.0248.002; Thu, 19 May 2016 10:34:41 -0700 From: "Subramaniam, Ravi" To: "Kovatsch Matthias" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WD///DvgIAAc5aw Date: Thu, 19 May 2016 17:34:41 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmYyYzY1YzYtMTRlYS00ZTJmLTk1MmYtYjY5MmJmODUxNTZkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjNkKzVTTGMxbnBlYkY5VTY4TjhiTGVOYndLV0dLSDMweGZ1ekM2Rml2OE09In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:34:52 -0000 Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]=20 Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster ; Kovatsch Matthias=20 > > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory >=20 > Hi Michael/Matthias, >=20 > Apologies if I am missing the point... >=20 > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a=20 > gateway that provides multiple logical endpoints." >=20 > 1. One is using the "authority" - in which case different=20 > "authorities" map to the same endpoint - using multiple unique=20 > endpoint ID (as authority) that maps to the same (socket) address. In=20 > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint=20 > needs to be registered with RD. The server demuxes on info that the=20 > server has embedded into the path. >=20 > Both these should be possible, right? >=20 > Ravi >=20 >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > Cc: core@ietf.org WG > Subject: Re: [core] draft-ietf-core-resource-directory >=20 > Hi Matthias >=20 > Yes, I believe this should be expected to work, though I have not=20 > tested it with any implementation. >=20 > The RD should maintain a database by unique endpoint ID with=20 > associated scheme/host/port addressing information that it determines=20 > from the request, or has been set explicitly with con=3D on registration. >=20 > Of course, if the device registers the same resource in both=20 > registrations, RD would return the same link value. >=20 > I will make a note to state this explicitly in the RD draft and=20 > provide an example. >=20 > Best regards, >=20 > Michael >=20 > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias=20 > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple=20 > > endpoints (ep) from > the same (socket) address. The use case is a device/service with=20 > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this=20 > > should be > possible out of the box: The same socket address registers each=20 > virtual/logical endpoint with different endpoint names and receives=20 > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri May 20 00:41:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A684712D6D2 for ; Fri, 20 May 2016 00:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sslx4oZnyUVv for ; Fri, 20 May 2016 00:41:07 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087E812D6D1 for ; Fri, 20 May 2016 00:41:05 -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.3.266.1; Fri, 20 May 2016 09:40:56 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0266.001; Fri, 20 May 2016 09:41:03 +0200 From: "Kovatsch Matthias" To: "Subramaniam, Ravi" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwAAQDgAAARXVAAACLJEEP//5DuAgAEN//s= Date: Fri, 20 May 2016 07:41:02 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_so6c1soj1nbsxuxkm9tsux1e1463729754158emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 07:41:11 -0000 --_000_so6c1soj1nbsxuxkm9tsux1e1463729754158emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias , Michael Koster Cc: "core@ietf.org WG" Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster ; Kovatsch Matthias > > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > Cc: core@ietf.org WG > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_so6c1soj1nbsxuxkm9tsux1e1463729754158emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There shouldn't be any implication for RD in this. The registering ent= ity simply needs to provide this UUID as context and the RD serves that in = its lookup results. The virtual and logical cases here should also work.

You then need a DNS-like service to resolve the UUIDs / OCF URIs to th= e preferred "socket address" (which depends on the communications= ).

Do I read you correctly that you want to ensure that the RD draft refl= ects this explicitly? :)

Ciao
Matthias 



-------- Original message --------
From: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>=
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Koster <= ;michaeljohnkoster@gmail.com>
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster &l= t;michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <michaeljohnkoster@gmail.com>; Kovatsch Matth= ias
> <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core
 --_000_so6c1soj1nbsxuxkm9tsux1e1463729754158emailandroidcom_-- From nobody Fri May 20 09:17:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290F12DDA0 for ; Fri, 20 May 2016 09:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvFxDyUtVSBx for ; Fri, 20 May 2016 09:17:50 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5083712DD84 for ; Fri, 20 May 2016 09:17:44 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 20 May 2016 09:17:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,340,1459839600"; d="scan'208,217";a="971240057" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga001.fm.intel.com with ESMTP; 20 May 2016 09:17:27 -0700 Received: from orsmsx163.amr.corp.intel.com (10.22.240.88) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 20 May 2016 09:17:26 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX163.amr.corp.intel.com ([169.254.9.70]) with mapi id 14.03.0248.002; Fri, 20 May 2016 09:17:26 -0700 From: "Subramaniam, Ravi" To: "Kovatsch Matthias" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WD///DvgIAAc5awgAB8iwD//+c0oA== Date: Fri, 20 May 2016 16:17:25 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2QyYjE1OWQtODZjNy00OTNhLTgwYzYtNTBmMjFkNGVjM2JkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkEzempsOE5hVXpIQm1Sc0VVN2Z5VHZSRkNIelc4SkdqSHBYZURqd1F4azA9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_D40BA8183A12B448ACB9448546032E089C9A76E4ORSMSX116amrcor_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 16:17:53 -0000 --_000_D40BA8183A12B448ACB9448546032E089C9A76E4ORSMSX116amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matthias, Thanks yes, that would be great. (Actually the "DNS-like" service can be si= milar to Resource discovery and so a separate service is not necessary). BTW: end point information can also be returned as part of Resource retriev= al - so the resolution can be "piggybacked" even though endpoint informatio= n is distinct. This depends on how the endpoint information is represented.= Need to read the draft to make sure that this method is also possible. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_D40BA8183A12B448ACB9448546032E089C9A76E4ORSMSX116amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Matthias,

 

Thanks yes, that would be great. (Actually= the “DNS-like” service can be similar to Resource discovery an= d so a separate service is not necessary).

 

BTW: end point information can also be ret= urned as part of Resource retrieval – so the resolution can be “= ;piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read = the draft to make sure that this method is also possible.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 12:41 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Ko= ster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

There shouldn't be any implication for RD in this. T= he registering entity simply needs to provide this UUID as context and the = RD serves that in its lookup results. The virtual and logical cases here sh= ould also work.

 

You then need a DNS-like service to resolve the UUID= s / OCF URIs to the preferred "socket address" (which depends on = the communications).

 

Do I read you correctly that you want to ensure that= the RD draft reflects this explicitly? :)

 

Ciao

Matthias 

 

 

 

-------- Original message --------

From: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>

Date: 5/19/16 19:34 (GMT+01:00)

To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Koster <michaeljohnkoster@gmail.com>

Subject: RE: [core] draft-ietf-core-resource-directo= ry

 

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <rav= i.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <= michaeljohnkoster@gmail.com>; Kovatsch Matthias
> <kovatsch@inf.ethz.ch&g= t;
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kova= tsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch<= /a>>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_D40BA8183A12B448ACB9448546032E089C9A76E4ORSMSX116amrcor_-- From nobody Fri May 20 09:20:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8D412DD59 for ; Fri, 20 May 2016 09:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.345 X-Spam-Level: X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3jWmEdgNPUL for ; Fri, 20 May 2016 09:20:52 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9735412D514 for ; Fri, 20 May 2016 09:20:48 -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.3.266.1; Fri, 20 May 2016 18:20:38 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0266.001; Fri, 20 May 2016 18:20:46 +0200 From: "Kovatsch Matthias" To: "Subramaniam, Ravi" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwAAQDgAAARXVAAACLJEEP//5DuAgAEN//uAAG6/gP//3iZA Date: Fri, 20 May 2016 16:20:45 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B551D4A6DDMBX210dethzch_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 16:20:56 -0000 --_000_55877B3AFB359744BA0F2140E36F52B551D4A6DDMBX210dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the "DNS-like" service can be si= milar to Resource discovery and so a separate service is not necessary). BTW: end point information can also be returned as part of Resource retriev= al - so the resolution can be "piggybacked" even though endpoint informatio= n is distinct. This depends on how the endpoint information is represented.= Need to read the draft to make sure that this method is also possible. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_55877B3AFB359744BA0F2140E36F52B551D4A6DDMBX210dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When only relying on the RD for such a resolution, there might be a pr= oblem with expressing both the authority name and the socket address: The RD basically returns URIs, which can only carry ei= ther. The additional information would need to go into a link attributeR= 30;

 

Ciao

Matthias

 

From: = Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:17
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; Michael Koster &= lt;michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Thanks yes, that would be g= reat. (Actually the “DNS-like” service can be similar to Resour= ce discovery and so a separate service is not necessary).=

 

BTW: end point information = can also be returned as part of Resource retrieval – so the resolutio= n can be “piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. = Need to read the draft to make sure that this method is also possible.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 12:41 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

There shouldn't be any implicat= ion for RD in this. The registering entity simply needs to provide this UUI= D as context and the RD serves that in its lookup results. The virtual and = logical cases here should also work.

 

You then need a DNS-like servic= e to resolve the UUIDs / OCF URIs to the preferred "socket address&quo= t; (which depends on the communications).

 

Do I read you correctly that yo= u want to ensure that the RD draft reflects this explicitly? :)<= /span>

 

Ciao

Matthias 

 

 

 

-------- Original message -----= ---

From: "Subramaniam, Ravi&q= uot; <ravi.subramaniam@int= el.com>

Date: 5/19/16 19:34 (GMT+01= :00)

To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Ko= ster <michaeljohnkoster@g= mail.com>

Subject: RE: [core] draft-ietf-= core-resource-directory

 

Hi M= atthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <rav= i.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <= michaeljohnkoster@gmail.com>; Kovatsch Matthias
> <kovatsch@inf.ethz.ch&g= t;
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kova= tsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch<= /a>>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_55877B3AFB359744BA0F2140E36F52B551D4A6DDMBX210dethzch_-- From nobody Fri May 20 09:45:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A61C12DE11 for ; Fri, 20 May 2016 09:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UxLcOIHUdiz for ; Fri, 20 May 2016 09:44:57 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE7F12DE08 for ; Fri, 20 May 2016 09:44:57 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 20 May 2016 09:44:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,340,1459839600"; d="scan'208,217";a="107610717" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga004.fm.intel.com with ESMTP; 20 May 2016 09:44:50 -0700 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 20 May 2016 09:44:50 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX151.amr.corp.intel.com ([169.254.7.222]) with mapi id 14.03.0248.002; Fri, 20 May 2016 09:44:50 -0700 From: "Subramaniam, Ravi" To: "Kovatsch Matthias" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WD///DvgIAAc5awgAB8iwD//+c0oIAAqgGAgABxBxA= Date: Fri, 20 May 2016 16:44:50 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTg1NWNlM2EtODUwNi00NDJlLTk0Y2ItNDJhNmM1ZTAwNjgzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik9odUZNTFhTa09qaWVUOTAwYit6XC9lZDdEUDNORm1IY2szclZPbEpBcHBBPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_D40BA8183A12B448ACB9448546032E089C9A782EORSMSX116amrcor_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 16:45:00 -0000 --_000_D40BA8183A12B448ACB9448546032E089C9A782EORSMSX116amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthias, Yes, IMO, there are 3 approaches: 1. Link attribute in the same link 2. Separate links (endpoints as resources) 3. Wellknown endpoint resource on RD for ep lookups. 2 is more flexible but requires additional setup interactions. Basically try to use the available CoRE paradigms for endpoint discovery (a= nd optimize discovery). DNS has been around and useful but technically it i= s a different system and something that has to be deployed/available along = with CoRE implementations. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:21 AM To: Subramaniam, Ravi ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the "DNS-like" service can be si= milar to Resource discovery and so a separate service is not necessary). BTW: end point information can also be returned as part of Resource retriev= al - so the resolution can be "piggybacked" even though endpoint informatio= n is distinct. This depends on how the endpoint information is represented.= Need to read the draft to make sure that this method is also possible. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_D40BA8183A12B448ACB9448546032E089C9A782EORSMSX116amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthias,

 

Yes, IMO, there are 3 approaches:

 

1.   &nbs= p; Link attribute in the same link

2.    Separate links (endpoints as resou= rces)

3.    Wellknown endpoint resource on RD = for ep lookups.

 

2 is more flexible but requires additional= setup interactions.

 

Basically try to use the available CoRE pa= radigms for endpoint discovery (and optimize discovery). DNS has been aroun= d and useful but technically it is a different system and something that has to be deployed/available along with CoRE imp= lementations.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 9:21 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Ko= ster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

When only relying on the RD for such = a resolution, there might be a problem with expressing both the authority n= ame and the socket address: The RD basically returns URIs, which can only carry either. The additional information would need t= o go into a link attribute…

 

Ciao

Matthias

 

From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:17
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Thanks yes, that would be great. (Actually= the “DNS-like” service can be similar to Resource discovery an= d so a separate service is not necessary).

 

BTW: end point information can also be ret= urned as part of Resource retrieval – so the resolution can be “= ;piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read = the draft to make sure that this method is also possible.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 12:41 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

There shouldn't be any implication for RD in this. T= he registering entity simply needs to provide this UUID as context and the = RD serves that in its lookup results. The virtual and logical cases here sh= ould also work.

 

You then need a DNS-like service to resolve the UUID= s / OCF URIs to the preferred "socket address" (which depends on = the communications).

 

Do I read you correctly that you want to ensure that= the RD draft reflects this explicitly? :)

 

Ciao

Matthias 

 

 

 

-------- Original message --------

From: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>

Date: 5/19/16 19:34 (GMT+01:00)

To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Koster <michaeljohnkoster@gmail.com>

Subject: RE: [core] draft-ietf-core-resource-directo= ry

 

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <rav= i.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <= michaeljohnkoster@gmail.com>; Kovatsch Matthias
> <kovatsch@inf.ethz.ch&g= t;
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kova= tsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch<= /a>>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_D40BA8183A12B448ACB9448546032E089C9A782EORSMSX116amrcor_-- From nobody Fri May 20 09:53:44 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D263412DA99 for ; Fri, 20 May 2016 09:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucN_PRtPFx2C for ; Fri, 20 May 2016 09:53:37 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B37012DA9B for ; Fri, 20 May 2016 09:53:35 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 20 May 2016 18:53:26 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.03.0266.001; Fri, 20 May 2016 18:53:33 +0200 From: "Kovatsch Matthias" To: "Subramaniam, Ravi" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwAAQDgAAARXVAAACLJEEP//5DuAgAEN//uAAG6/gP//3iZAgAApgwD//93NAA== Date: Fri, 20 May 2016 16:53:32 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B551D4A75BMBX210dethzch_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 16:53:43 -0000 --_000_55877B3AFB359744BA0F2140E36F52B551D4A75BMBX210dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understood it is about resolving the authority name/UUID/... in a URI to = the socket address. When this is handled by the RD and not an external serv= ice (e.g., DNS), the RD has a problem to encode this in its responses, the = link lists. The latter are URI based, so either the URI has the name/UUID/.= .. which has the information for vhosts (e.g., fill the Uri-Host option), b= ut not the transport layer address or the URI has the transport layer addre= ss in the authority field, but then lacks the name/UUID/... for multiplexin= g virtual endpoints behind the same transport layer address. Maybe you just need the resolve feature from RD, but not the vhost support.= There are use cases for both behaviors of the RD, so we should look into a= way to accommodate both explicitly, so there will not be issues depending = on which RD implementation on picks... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:45 To: Kovatsch Matthias ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory Matthias, Yes, IMO, there are 3 approaches: 1. Link attribute in the same link 2. Separate links (endpoints as resources) 3. Wellknown endpoint resource on RD for ep lookups. 2 is more flexible but requires additional setup interactions. Basically try to use the available CoRE paradigms for endpoint discovery (a= nd optimize discovery). DNS has been around and useful but technically it i= s a different system and something that has to be deployed/available along = with CoRE implementations. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:21 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the "DNS-like" service can be si= milar to Resource discovery and so a separate service is not necessary). BTW: end point information can also be returned as part of Resource retriev= al - so the resolution can be "piggybacked" even though endpoint informatio= n is distinct. This depends on how the endpoint information is represented.= Need to read the draft to make sure that this method is also possible. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_55877B3AFB359744BA0F2140E36F52B551D4A75BMBX210dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I understood it is about resolving the authority name/UUID/… in = a URI to the socket address. When this is handled by the RD and not an external service (e.g., DNS), the RD has a problem to encode= this in its responses, the link lists. The latter are URI based, so either= the URI has the name/UUID/… which has the information for vhosts (e.= g., fill the Uri-Host option), but not the transport layer address or the URI has the transport layer address in = the authority field, but then lacks the name/UUID/… for multiplexing = virtual endpoints behind the same transport layer address.

 

Maybe you just need the resolve feature from RD, but not the vhost sup= port. There are use cases for both behaviors of the RD, so we should look into a way to accommodate both explicitly, so th= ere will not be issues depending on which RD implementation on picks…

 

Ciao

Matthias

 

From: = Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:45
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; Michael Koster &= lt;michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Matthias,=

 

Yes, IMO, there are 3 appro= aches:

 

1. =     Link attribute in t= he same link

2. =    Separate links (end= points as resources)

3. =    Wellknown endpoint = resource on RD for ep lookups.

 

2 is more flexible but requ= ires additional setup interactions.

 

Basically try to use the av= ailable CoRE paradigms for endpoint discovery (and optimize discovery). DNS= has been around and useful but technically it is a different system and something that has to be deployed/available along w= ith CoRE implementations.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 9:21 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

When only relying on t= he RD for such a resolution, there might be a problem with expressing both = the authority name and the socket address: The RD basically returns URIs, which can only carry either. The additional inform= ation would need to go into a link attribute…

 

Ciao=

Matthias

 

From: = Subramaniam, Ravi [mailto:rav= i.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:17
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Thanks yes, that would be g= reat. (Actually the “DNS-like” service can be similar to Resour= ce discovery and so a separate service is not necessary).=

 

BTW: end point information = can also be returned as part of Resource retrieval – so the resolutio= n can be “piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. = Need to read the draft to make sure that this method is also possible.

 

Ravi

 

From: = Kovatsch Matthias [mailto:kovatsch@= inf.ethz.ch]
Sent: Friday, May 20, 2016 12:41 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

There shouldn't be any implicat= ion for RD in this. The registering entity simply needs to provide this UUI= D as context and the RD serves that in its lookup results. The virtual and = logical cases here should also work.

 

You then need a DNS-like servic= e to resolve the UUIDs / OCF URIs to the preferred "socket address&quo= t; (which depends on the communications).

 

Do I read you correctly that yo= u want to ensure that the RD draft reflects this explicitly? :)<= /span>

 

Ciao

Matthias 

 

 

 

-------- Original message -----= ---

From: "Subramaniam, Ravi&q= uot; <ravi.subramaniam@int= el.com>

Date: 5/19/16 19:34 (GMT+01= :00)

To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Ko= ster <michaeljohnkoster@g= mail.com>

Subject: RE: [core] draft-ietf-= core-resource-directory

 

Hi M= atthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <rav= i.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <= michaeljohnkoster@gmail.com>; Kovatsch Matthias
> <kovatsch@inf.ethz.ch&g= t;
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kova= tsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch<= /a>>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_55877B3AFB359744BA0F2140E36F52B551D4A75BMBX210dethzch_-- From nobody Fri May 20 10:05:43 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CB512D6E2 for ; Fri, 20 May 2016 10:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8OhgProAZBu for ; Fri, 20 May 2016 10:05:37 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2AE12D570 for ; Fri, 20 May 2016 10:05:37 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP; 20 May 2016 10:05:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,340,1459839600"; d="scan'208,217";a="107620808" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga004.fm.intel.com with ESMTP; 20 May 2016 10:05:37 -0700 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 20 May 2016 10:05:36 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX158.amr.corp.intel.com ([10.22.240.20]) with mapi id 14.03.0248.002; Fri, 20 May 2016 10:05:35 -0700 From: "Subramaniam, Ravi" To: "Kovatsch Matthias" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WD///DvgIAAc5awgAB8iwD//+c0oIAAqgGAgABxBxD//5giAIAAdQSQ Date: Fri, 20 May 2016 17:05:35 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGJlYjU5MjItNzA1ZC00MWNiLTk0YjktMjJiYzRiZmQ2YTgxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlBWVHordWNWZnVsM3JJenRlVXVtVytQNXBkYldYZFcxeW1GUGhHQjZseVE9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_D40BA8183A12B448ACB9448546032E089C9A7950ORSMSX116amrcor_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 17:05:41 -0000 --_000_D40BA8183A12B448ACB9448546032E089C9A7950ORSMSX116amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matthias, Maybe I was not clear - the RD does not have to "resolve" the UUID - it wou= ld not be possible when there are multiple endpoints. Also to allow the dem= uxing with Authority for a single endpoint, the UUID has to be in the URI -= which means the endpoint info has to be separated and will be used in the = messaging layer. The difference is that instead of "looking up UUID as a hostname" in DNS, t= he ideas is to make a request to a well-known "endpoint" lookup resource on= the RD using UUID as a filter (well ... there are a few ways to do this he= re). In either case of DNS or RD, it is a two-step process. But if one uses RD t= here are opportunities to optimize which will not be possible with an exter= nal system like DNS. (I guess I got into the optimization before I was clea= r with the base model :) ) Makes sense? Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:54 AM To: Subramaniam, Ravi ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory I understood it is about resolving the authority name/UUID/... in a URI to = the socket address. When this is handled by the RD and not an external serv= ice (e.g., DNS), the RD has a problem to encode this in its responses, the = link lists. The latter are URI based, so either the URI has the name/UUID/.= .. which has the information for vhosts (e.g., fill the Uri-Host option), b= ut not the transport layer address or the URI has the transport layer addre= ss in the authority field, but then lacks the name/UUID/... for multiplexin= g virtual endpoints behind the same transport layer address. Maybe you just need the resolve feature from RD, but not the vhost support.= There are use cases for both behaviors of the RD, so we should look into a= way to accommodate both explicitly, so there will not be issues depending = on which RD implementation on picks... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:45 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Matthias, Yes, IMO, there are 3 approaches: 1. Link attribute in the same link 2. Separate links (endpoints as resources) 3. Wellknown endpoint resource on RD for ep lookups. 2 is more flexible but requires additional setup interactions. Basically try to use the available CoRE paradigms for endpoint discovery (a= nd optimize discovery). DNS has been around and useful but technically it i= s a different system and something that has to be deployed/available along = with CoRE implementations. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:21 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the "DNS-like" service can be si= milar to Resource discovery and so a separate service is not necessary). BTW: end point information can also be returned as part of Resource retriev= al - so the resolution can be "piggybacked" even though endpoint informatio= n is distinct. This depends on how the endpoint information is represented.= Need to read the draft to make sure that this method is also possible. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_D40BA8183A12B448ACB9448546032E089C9A7950ORSMSX116amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Matthias,

 

Maybe I was not clear – the RD does = not have to “resolve” the UUID – it would not be possible= when there are multiple endpoints. Also to allow the demuxing with Authori= ty for a single endpoint, the UUID has to be in the URI – which means t= he endpoint info has to be separated and will be used in the messaging laye= r.

 

The difference is that instead of “l= ooking up UUID as a hostname” in DNS, the ideas is to make a request = to a well-known “endpoint” lookup resource on the RD using UUID as a filter (well … there are a few ways to do this here).=

 

In either case of DNS or RD, it is a two-s= tep process. But if one uses RD there are opportunities to optimize which w= ill not be possible with an external system like DNS. (I guess I got into the optimization before I was clear with the base= model J )

 

Makes sense?

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 9:54 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Ko= ster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

I understood it is about resolving th= e authority name/UUID/… in a URI to the socket address. When this is = handled by the RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the link lists= . The latter are URI based, so either the URI has the name/UUID/… whi= ch has the information for vhosts (e.g., fill the Uri-Host option), but not= the transport layer address or the URI has the transport layer address in the authority field, but then lacks the= name/UUID/… for multiplexing virtual endpoints behind the same trans= port layer address.

 

Maybe you just need the resolve featu= re from RD, but not the vhost support. There are use cases for both behavio= rs of the RD, so we should look into a way to accommodate both explicitly, so there will not be issues depending on whic= h RD implementation on picks…

 

Ciao

Matthias

 

From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:45
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Matthias,

 

Yes, IMO, there are 3 approaches:

 

1.   &nbs= p; Link attribute in the same link

2.    Separate links (endpoints as resou= rces)

3.    Wellknown endpoint resource on RD = for ep lookups.

 

2 is more flexible but requires additional= setup interactions.

 

Basically try to use the available CoRE pa= radigms for endpoint discovery (and optimize discovery). DNS has been aroun= d and useful but technically it is a different system and something that has to be deployed/available along with CoRE imp= lementations.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 9:21 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

When only relying on the RD for such = a resolution, there might be a problem with expressing both the authority n= ame and the socket address: The RD basically returns URIs, which can only carry either. The additional information would need t= o go into a link attribute…

 

Ciao

Matthias

 

From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:17
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Thanks yes, that would be great. (Actually= the “DNS-like” service can be similar to Resource discovery an= d so a separate service is not necessary).

 

BTW: end point information can also be ret= urned as part of Resource retrieval – so the resolution can be “= ;piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read = the draft to make sure that this method is also possible.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 12:41 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

There shouldn't be any implication for RD in this. T= he registering entity simply needs to provide this UUID as context and the = RD serves that in its lookup results. The virtual and logical cases here sh= ould also work.

 

You then need a DNS-like service to resolve the UUID= s / OCF URIs to the preferred "socket address" (which depends on = the communications).

 

Do I read you correctly that you want to ensure that= the RD draft reflects this explicitly? :)

 

Ciao

Matthias 

 

 

 

-------- Original message --------

From: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>

Date: 5/19/16 19:34 (GMT+01:00)

To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Koster <michaeljohnkoster@gmail.com>

Subject: RE: [core] draft-ietf-core-resource-directo= ry

 

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <rav= i.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <= michaeljohnkoster@gmail.com>; Kovatsch Matthias
> <kovatsch@inf.ethz.ch&g= t;
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kova= tsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch<= /a>>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_D40BA8183A12B448ACB9448546032E089C9A7950ORSMSX116amrcor_-- From nobody Fri May 20 10:10:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F219212DE3E for ; Fri, 20 May 2016 10:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gHLSKH0AyaF for ; Fri, 20 May 2016 10:10:13 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD1412DE3F for ; Fri, 20 May 2016 10:10:11 -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.3.266.1; Fri, 20 May 2016 19:10:02 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0266.001; Fri, 20 May 2016 19:10:09 +0200 From: "Kovatsch Matthias" To: "Subramaniam, Ravi" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwAAQDgAAARXVAAACLJEEP//5DuAgAEN//uAAG6/gP//3iZAgAApgwD//93NAIAAJ/+A///d8mA= Date: Fri, 20 May 2016 17:10:09 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B551D4A7B5@MBX210.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B551D4A7B5MBX210dethzch_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 17:10:18 -0000 --_000_55877B3AFB359744BA0F2140E36F52B551D4A7B5MBX210dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ravi I think I got you now: There is a look-up interface in RD (probably the ep lookup to finally make = it more useful :P) that will return a list of two or more URIs, where one h= as the UUID in the authority field and the remaining carry the transport-la= yer specific addresses (and usually there are two URIs only in this list...= ). Best wishes Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 19:06 To: Kovatsch Matthias ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Maybe I was not clear - the RD does not have to "resolve" the UUID - it wou= ld not be possible when there are multiple endpoints. Also to allow the dem= uxing with Authority for a single endpoint, the UUID has to be in the URI -= which means the endpoint info has to be separated and will be used in the = messaging layer. The difference is that instead of "looking up UUID as a hostname" in DNS, t= he ideas is to make a request to a well-known "endpoint" lookup resource on= the RD using UUID as a filter (well ... there are a few ways to do this he= re). In either case of DNS or RD, it is a two-step process. But if one uses RD t= here are opportunities to optimize which will not be possible with an exter= nal system like DNS. (I guess I got into the optimization before I was clea= r with the base model :) ) Makes sense? Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:54 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory I understood it is about resolving the authority name/UUID/... in a URI to = the socket address. When this is handled by the RD and not an external serv= ice (e.g., DNS), the RD has a problem to encode this in its responses, the = link lists. The latter are URI based, so either the URI has the name/UUID/.= .. which has the information for vhosts (e.g., fill the Uri-Host option), b= ut not the transport layer address or the URI has the transport layer addre= ss in the authority field, but then lacks the name/UUID/... for multiplexin= g virtual endpoints behind the same transport layer address. Maybe you just need the resolve feature from RD, but not the vhost support.= There are use cases for both behaviors of the RD, so we should look into a= way to accommodate both explicitly, so there will not be issues depending = on which RD implementation on picks... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:45 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Matthias, Yes, IMO, there are 3 approaches: 1. Link attribute in the same link 2. Separate links (endpoints as resources) 3. Wellknown endpoint resource on RD for ep lookups. 2 is more flexible but requires additional setup interactions. Basically try to use the available CoRE paradigms for endpoint discovery (a= nd optimize discovery). DNS has been around and useful but technically it i= s a different system and something that has to be deployed/available along = with CoRE implementations. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:21 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the "DNS-like" service can be si= milar to Resource discovery and so a separate service is not necessary). BTW: end point information can also be returned as part of Resource retriev= al - so the resolution can be "piggybacked" even though endpoint informatio= n is distinct. This depends on how the endpoint information is represented.= Need to read the draft to make sure that this method is also possible. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_55877B3AFB359744BA0F2140E36F52B551D4A7B5MBX210dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ravi

 = ;

I think I got you now:

 

There is a look-up interface in RD (probably the ep lookup to finally = make it more useful :P) that will return a list of two or more URIs, where one has the UUID in the authority field and the= remaining carry the transport-layer specific addresses (and usually there = are two URIs only in this list…).

 

Best wishes

Matthias

 

 

From: = Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 19:06
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; Michael Koster &= lt;michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Maybe I was not clear ̵= 1; the RD does not have to “resolve” the UUID – it would = not be possible when there are multiple endpoints. Also to allow the demuxi= ng with Authority for a single endpoint, the UUID has to be in the URI –= ; which means the endpoint info has to be separated and will be used in the= messaging layer.

 

The difference is that inst= ead of “looking up UUID as a hostname” in DNS, the ideas is to = make a request to a well-known “endpoint” lookup resource on the RD using UUID as a filter (well … there are a few ways to do thi= s here).

 

In either case of DNS or RD= , it is a two-step process. But if one uses RD there are opportunities to o= ptimize which will not be possible with an external system like DNS. (I guess I got into the optimization before I was clear w= ith the base model J )

 

Makes sense?

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 9:54 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

I understood it is abo= ut resolving the authority name/UUID/… in a URI to the socket address= . When this is handled by the RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the lin= k lists. The latter are URI based, so either the URI has the name/UUID/R= 30; which has the information for vhosts (e.g., fill the Uri-Host option), = but not the transport layer address or the URI has the transport layer address in the authority field, but then l= acks the name/UUID/… for multiplexing virtual endpoints behind the sa= me transport layer address.

 

Maybe you just need th= e resolve feature from RD, but not the vhost support. There are use cases f= or both behaviors of the RD, so we should look into a way to accommodate both explicitly, so there will not be issues dependin= g on which RD implementation on picks…

 

Ciao=

Matthias

 

From: = Subramaniam, Ravi [mailto:rav= i.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:45
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Matthias,=

 

Yes, IMO, there are 3 appro= aches:

 

1. =     Link attribute in t= he same link

2. =    Separate links (end= points as resources)

3. =    Wellknown endpoint = resource on RD for ep lookups.

 

2 is more flexible but requ= ires additional setup interactions.

 

Basically try to use the av= ailable CoRE paradigms for endpoint discovery (and optimize discovery). DNS= has been around and useful but technically it is a different system and something that has to be deployed/available along w= ith CoRE implementations.

 

Ravi

 

From: = Kovatsch Matthias [mailto:kovatsch@= inf.ethz.ch]
Sent: Friday, May 20, 2016 9:21 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

When only relying on t= he RD for such a resolution, there might be a problem with expressing both = the authority name and the socket address: The RD basically returns URIs, which can only carry either. The additional inform= ation would need to go into a link attribute…

 

Ciao=

Matthias

 

From: = Subramaniam, Ravi [mailto:rav= i.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:17
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Thanks yes, that would be g= reat. (Actually the “DNS-like” service can be similar to Resour= ce discovery and so a separate service is not necessary).=

 

BTW: end point information = can also be returned as part of Resource retrieval – so the resolutio= n can be “piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. = Need to read the draft to make sure that this method is also possible.

 

Ravi

 

From: = Kovatsch Matthias [mailto:kovatsch@= inf.ethz.ch]
Sent: Friday, May 20, 2016 12:41 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

There shouldn't be any implicat= ion for RD in this. The registering entity simply needs to provide this UUI= D as context and the RD serves that in its lookup results. The virtual and = logical cases here should also work.

 

You then need a DNS-like servic= e to resolve the UUIDs / OCF URIs to the preferred "socket address&quo= t; (which depends on the communications).

 

Do I read you correctly that yo= u want to ensure that the RD draft reflects this explicitly? :)<= /span>

 

Ciao

Matthias 

 

 

 

-------- Original message -----= ---

From: "Subramaniam, Ravi&q= uot; <ravi.subramaniam@int= el.com>

Date: 5/19/16 19:34 (GMT+01= :00)

To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Ko= ster <michaeljohnkoster@g= mail.com>

Subject: RE: [core] draft-ietf-= core-resource-directory

 

Hi M= atthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <rav= i.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <= michaeljohnkoster@gmail.com>; Kovatsch Matthias
> <kovatsch@inf.ethz.ch&g= t;
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kova= tsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch<= /a>>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_55877B3AFB359744BA0F2140E36F52B551D4A7B5MBX210dethzch_-- From nobody Fri May 20 10:12:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4251B12DA6C for ; Fri, 20 May 2016 10:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtivXHq0nR8G for ; Fri, 20 May 2016 10:12:21 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 167A212D5CA for ; Fri, 20 May 2016 10:12:21 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 20 May 2016 10:12:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,340,1459839600"; d="scan'208,217";a="971270296" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga001.fm.intel.com with ESMTP; 20 May 2016 10:12:22 -0700 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 20 May 2016 10:12:20 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX157.amr.corp.intel.com ([10.22.240.23]) with mapi id 14.03.0248.002; Fri, 20 May 2016 10:12:20 -0700 From: "Subramaniam, Ravi" To: "Kovatsch Matthias" , Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WD///DvgIAAc5awgAB8iwD//+c0oIAAqgGAgABxBxD//5giAIAAdQSQ//+PoIAADpxLEA== Date: Fri, 20 May 2016 17:12:19 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch>, <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A7B5@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B551D4A7B5@MBX210.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzI0MjNmOWItNjViMi00MzVkLWI0ZjgtNzIyYTQ1YzdhOTY2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjAwem13VnZ2bFlWZkFVMkVha2tXVVVuaWpCbVQ4THIrMlFqQk15SXpoSzA9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_D40BA8183A12B448ACB9448546032E089C9A7A1BORSMSX116amrcor_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 17:12:25 -0000 --_000_D40BA8183A12B448ACB9448546032E089C9A7A1BORSMSX116amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right - Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 10:10 AM To: Subramaniam, Ravi ; Michael Koster Cc: core@ietf.org WG Subject: RE: [core] draft-ietf-core-resource-directory Hi Ravi I think I got you now: There is a look-up interface in RD (probably the ep lookup to finally make = it more useful :P) that will return a list of two or more URIs, where one h= as the UUID in the authority field and the remaining carry the transport-la= yer specific addresses (and usually there are two URIs only in this list...= ). Best wishes Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 19:06 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Maybe I was not clear - the RD does not have to "resolve" the UUID - it wou= ld not be possible when there are multiple endpoints. Also to allow the dem= uxing with Authority for a single endpoint, the UUID has to be in the URI -= which means the endpoint info has to be separated and will be used in the = messaging layer. The difference is that instead of "looking up UUID as a hostname" in DNS, t= he ideas is to make a request to a well-known "endpoint" lookup resource on= the RD using UUID as a filter (well ... there are a few ways to do this he= re). In either case of DNS or RD, it is a two-step process. But if one uses RD t= here are opportunities to optimize which will not be possible with an exter= nal system like DNS. (I guess I got into the optimization before I was clea= r with the base model :) ) Makes sense? Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:54 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory I understood it is about resolving the authority name/UUID/... in a URI to = the socket address. When this is handled by the RD and not an external serv= ice (e.g., DNS), the RD has a problem to encode this in its responses, the = link lists. The latter are URI based, so either the URI has the name/UUID/.= .. which has the information for vhosts (e.g., fill the Uri-Host option), b= ut not the transport layer address or the URI has the transport layer addre= ss in the authority field, but then lacks the name/UUID/... for multiplexin= g virtual endpoints behind the same transport layer address. Maybe you just need the resolve feature from RD, but not the vhost support.= There are use cases for both behaviors of the RD, so we should look into a= way to accommodate both explicitly, so there will not be issues depending = on which RD implementation on picks... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:45 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Matthias, Yes, IMO, there are 3 approaches: 1. Link attribute in the same link 2. Separate links (endpoints as resources) 3. Wellknown endpoint resource on RD for ep lookups. 2 is more flexible but requires additional setup interactions. Basically try to use the available CoRE paradigms for endpoint discovery (a= nd optimize discovery). DNS has been around and useful but technically it i= s a different system and something that has to be deployed/available along = with CoRE implementations. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:21 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute... Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the "DNS-like" service can be si= milar to Resource discovery and so a separate service is not necessary). BTW: end point information can also be returned as part of Resource retriev= al - so the resolution can be "piggybacked" even though endpoint informatio= n is distinct. This depends on how the endpoint information is represented.= Need to read the draft to make sure that this method is also possible. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_D40BA8183A12B448ACB9448546032E089C9A7A1BORSMSX116amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right - Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 10:10 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Ko= ster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Ravi

 

I think I got you now:

 

There is a look-up interface in RD (p= robably the ep lookup to finally make it more useful :P) that will return a= list of two or more URIs, where one has the UUID in the authority field and the remaining carry the transport-layer specifi= c addresses (and usually there are two URIs only in this list…).=

 

Best wishes

Matthias

 

 

From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 19:06
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Maybe I was not clear – the RD does = not have to “resolve” the UUID – it would not be possible= when there are multiple endpoints. Also to allow the demuxing with Authori= ty for a single endpoint, the UUID has to be in the URI – which means t= he endpoint info has to be separated and will be used in the messaging laye= r.

 

The difference is that instead of “l= ooking up UUID as a hostname” in DNS, the ideas is to make a request = to a well-known “endpoint” lookup resource on the RD using UUID as a filter (well … there are a few ways to do this here).=

 

In either case of DNS or RD, it is a two-s= tep process. But if one uses RD there are opportunities to optimize which w= ill not be possible with an external system like DNS. (I guess I got into the optimization before I was clear with the base= model J )

 

Makes sense?

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 9:54 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

I understood it is about resolving th= e authority name/UUID/… in a URI to the socket address. When this is = handled by the RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the link lists= . The latter are URI based, so either the URI has the name/UUID/… whi= ch has the information for vhosts (e.g., fill the Uri-Host option), but not= the transport layer address or the URI has the transport layer address in the authority field, but then lacks the= name/UUID/… for multiplexing virtual endpoints behind the same trans= port layer address.

 

Maybe you just need the resolve featu= re from RD, but not the vhost support. There are use cases for both behavio= rs of the RD, so we should look into a way to accommodate both explicitly, so there will not be issues depending on whic= h RD implementation on picks…

 

Ciao

Matthias

 

From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:45
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Matthias,

 

Yes, IMO, there are 3 approaches:

 

1.   &nbs= p; Link attribute in the same link

2.    Separate links (endpoints as resou= rces)

3.    Wellknown endpoint resource on RD = for ep lookups.

 

2 is more flexible but requires additional= setup interactions.

 

Basically try to use the available CoRE pa= radigms for endpoint discovery (and optimize discovery). DNS has been aroun= d and useful but technically it is a different system and something that has to be deployed/available along with CoRE imp= lementations.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 9:21 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

When only relying on the RD for such = a resolution, there might be a problem with expressing both the authority n= ame and the socket address: The RD basically returns URIs, which can only carry either. The additional information would need t= o go into a link attribute…

 

Ciao

Matthias

 

From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
Sent: Freitag, 20. Mai 2016 18:17
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

Hi Matthias,

 

Thanks yes, that would be great. (Actually= the “DNS-like” service can be similar to Resource discovery an= d so a separate service is not necessary).

 

BTW: end point information can also be ret= urned as part of Resource retrieval – so the resolution can be “= ;piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read = the draft to make sure that this method is also possible.

 

Ravi

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, May 20, 2016 12:41 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

 

There shouldn't be any implication for RD in this. T= he registering entity simply needs to provide this UUID as context and the = RD serves that in its lookup results. The virtual and logical cases here sh= ould also work.

 

You then need a DNS-like service to resolve the UUID= s / OCF URIs to the preferred "socket address" (which depends on = the communications).

 

Do I read you correctly that you want to ensure that= the RD draft reflects this explicitly? :)

 

Ciao

Matthias 

 

 

 

-------- Original message --------

From: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>

Date: 5/19/16 19:34 (GMT+01:00)

To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Koster <michaeljohnkoster@gmail.com>

Subject: RE: [core] draft-ietf-core-resource-directo= ry

 

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kov= atsch@inf.ethz.ch]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <rav= i.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <= michaeljohnkoster@gmail.com>; Kovatsch Matthias
> <kovatsch@inf.ethz.ch&g= t;
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
>
> Hi Michael/Matthias,
>
> Apologies if I am missing the point...
>
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a =
> gateway that provides multiple logical endpoints."
>
> 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple uniq= ue
> endpoint ID (as authority) that maps to the same (socket) address. In =
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint
> needs to be registered with RD. The server demuxes on info that the > server has embedded into the path.
>
> Both these should be possible, right?
>
> Ravi
>
>
> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kova= tsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
>
> Hi Matthias
>
> Yes, I believe this should be expected to work, though I have not
> tested it with any implementation.
>
> The RD should maintain a database by unique endpoint ID with
> associated scheme/host/port addressing information that it determines =
> from the request, or has been set explicitly with con=3D on registrati= on.
>
> Of course, if the device registers the same resource in both
> registrations, RD would return the same link value.
>
> I will make a note to state this explicitly in the RD draft and
> provide an example.
>
> Best regards,
>
> Michael
>
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias
> > <kovatsch@inf.ethz.ch<= /a>>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is
> > should be
> possible out of the box: The same socket address registers each
> virtual/logical endpoint with different endpoint names and receives > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_D40BA8183A12B448ACB9448546032E089C9A7A1BORSMSX116amrcor_-- From nobody Fri May 20 10:26:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2CC12D18E for ; Fri, 20 May 2016 10:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cut4d3AsY5zn for ; Fri, 20 May 2016 10:25:56 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C254F12DA6F for ; Fri, 20 May 2016 10:25:49 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id bt5so41284305pac.3 for ; Fri, 20 May 2016 10:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=c5iX6oKg640oLne81FttrwI9nXtlRooqQBJMyxMCm4E=; b=cFLagDDkI9HVno9FHNX2LaxoeEkocSbh9Jt1Fctk1dcli5BR32TWI3tdrUPfa6/zGE 1LIbnnBKFXyrOyUV7winc3vY4ssAjj3dL+Y/WEKA2xdKMMWRcss2jEsJ/EHRgd5IQkiE TCTqArJikTnC/zgQtvU/G5rmmPxnEiQAliu63hqTpEMHYs5J1Vu05wC15CNT+n6ZBQnL J7nnBLjF7UPHmPShExrge6+dqsHk41U91a+T3uL/3mSeKGGoLQsAiQ+fNIOosSJK2LUL GKGY2GuvN7mHjnLVE8ZbCfcyipH9nlRoQPmDG4VofxdQd0z/KukKHEGKp5ditUQhXN6T dOoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=c5iX6oKg640oLne81FttrwI9nXtlRooqQBJMyxMCm4E=; b=AdlVzjMn/nNHkuqJrq8hSt6bU97gN9sd/VVDoisc9H7vQAjaidgPCpN6Y+YUAjJ8JN pjZxDCnf+tMSQQck6S3aF7OiK6zcINt0/xsKsfqQaGg7R7X6dj1y2QE+d3BeEWWEqmgm QzC5XB8IQnwBb2C3bGllGhkTApobbKzVwVyxa/fQ3FV+HOF5T3dVWcPxgRFgo8Qav6Ry ilBWV6XWA4NvZuq2fEx6evNXxn2IjwRmj18Vt/PQx0bWFoEqPSgmq1fhQKASJcmR8NPA uvNCQnsK/Imwy43CoCQTBu8m4ia5Hwb50GcFoTRAxdkNyvsE4kXj6yJKITgwTbdWUa0+ +ryQ== X-Gm-Message-State: AOPr4FWAKTQUWZJNZodBkjLk8ER1DKicKVR502UvkgVGzk1d5QxfjnGswVmkKqG1nPkicA== X-Received: by 10.66.122.100 with SMTP id lr4mr6269266pab.99.1463765149278; Fri, 20 May 2016 10:25:49 -0700 (PDT) Received: from [10.0.0.7] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id b27sm28559184pfc.74.2016.05.20.10.25.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 May 2016 10:25:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FA0A9486-E5F1-4BCD-958E-37AFBAF99F5F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Fri, 20 May 2016 10:25:46 -0700 Message-Id: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A7B5@MBX210.d.ethz.ch> To: Ravi Subramaniam X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 17:26:00 -0000 --Apple-Mail=_FA0A9486-E5F1-4BCD-958E-37AFBAF99F5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 Michael PS we may be able to define some sort of link structure and "rel" value = to register links that describe the endpoints along with the resources, = as was mentioned earlier. It could be a supplementary feature to the = internally stored registration parameters that are set using query = parameters. This could be another way to filter endpoint parameters in = addition to the ep lookup function. > On May 20, 2016, at 10:12 AM, Subramaniam, Ravi = wrote: >=20 > Right - Ravi > =20 > <>From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]=20 > Sent: Friday, May 20, 2016 10:10 AM > To: Subramaniam, Ravi ; Michael Koster = > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory > =20 > Hi Ravi > =20 > I think I got you now: > =20 > There is a look-up interface in RD (probably the ep lookup to finally = make it more useful :P) that will return a list of two or more URIs, = where one has the UUID in the authority field and the remaining carry = the transport-layer specific addresses (and usually there are two URIs = only in this list=E2=80=A6). > =20 > Best wishes > Matthias > =20 > =20 > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ]=20 > Sent: Freitag, 20. Mai 2016 19:06 > To: Kovatsch Matthias >; Michael Koster = > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > =20 > Hi Matthias, > =20 > Maybe I was not clear =E2=80=93 the RD does not have to =E2=80=9Cresolve= =E2=80=9D the UUID =E2=80=93 it would not be possible when there are = multiple endpoints. Also to allow the demuxing with Authority for a = single endpoint, the UUID has to be in the URI =E2=80=93 which means the = endpoint info has to be separated and will be used in the messaging = layer. > =20 > The difference is that instead of =E2=80=9Clooking up UUID as a = hostname=E2=80=9D in DNS, the ideas is to make a request to a well-known = =E2=80=9Cendpoint=E2=80=9D lookup resource on the RD using UUID as a = filter (well =E2=80=A6 there are a few ways to do this here). > =20 > In either case of DNS or RD, it is a two-step process. But if one uses = RD there are opportunities to optimize which will not be possible with = an external system like DNS. (I guess I got into the optimization before = I was clear with the base model J ) > =20 > Makes sense? > =20 > Ravi > =20 > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 > Sent: Friday, May 20, 2016 9:54 AM > To: Subramaniam, Ravi >; Michael Koster = > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > =20 > I understood it is about resolving the authority name/UUID/=E2=80=A6 = in a URI to the socket address. When this is handled by the RD and not = an external service (e.g., DNS), the RD has a problem to encode this in = its responses, the link lists. The latter are URI based, so either the = URI has the name/UUID/=E2=80=A6 which has the information for vhosts = (e.g., fill the Uri-Host option), but not the transport layer address or = the URI has the transport layer address in the authority field, but then = lacks the name/UUID/=E2=80=A6 for multiplexing virtual endpoints behind = the same transport layer address. > =20 > Maybe you just need the resolve feature from RD, but not the vhost = support. There are use cases for both behaviors of the RD, so we should = look into a way to accommodate both explicitly, so there will not be = issues depending on which RD implementation on picks=E2=80=A6 > =20 > Ciao > Matthias > =20 > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ]=20 > Sent: Freitag, 20. Mai 2016 18:45 > To: Kovatsch Matthias >; Michael Koster = > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > =20 > Matthias, > =20 > Yes, IMO, there are 3 approaches: > =20 > 1. Link attribute in the same link > 2. Separate links (endpoints as resources) > 3. Wellknown endpoint resource on RD for ep lookups. > =20 > 2 is more flexible but requires additional setup interactions. > =20 > Basically try to use the available CoRE paradigms for endpoint = discovery (and optimize discovery). DNS has been around and useful but = technically it is a different system and something that has to be = deployed/available along with CoRE implementations. > =20 > Ravi > =20 > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 > Sent: Friday, May 20, 2016 9:21 AM > To: Subramaniam, Ravi >; Michael Koster = > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > =20 > When only relying on the RD for such a resolution, there might be a = problem with expressing both the authority name and the socket address: = The RD basically returns URIs, which can only carry either. The = additional information would need to go into a link attribute=E2=80=A6 > =20 > Ciao > Matthias > =20 > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ]=20 > Sent: Freitag, 20. Mai 2016 18:17 > To: Kovatsch Matthias >; Michael Koster = > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > =20 > Hi Matthias, > =20 > Thanks yes, that would be great. (Actually the =E2=80=9CDNS-like=E2=80=9D= service can be similar to Resource discovery and so a separate service = is not necessary). > =20 > BTW: end point information can also be returned as part of Resource = retrieval =E2=80=93 so the resolution can be =E2=80=9Cpiggybacked=E2=80=9D= even though endpoint information is distinct. This depends on how the = endpoint information is represented. Need to read the draft to make sure = that this method is also possible. > =20 > Ravi > =20 > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 > Sent: Friday, May 20, 2016 12:41 AM > To: Subramaniam, Ravi >; Michael Koster = > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > =20 > There shouldn't be any implication for RD in this. The registering = entity simply needs to provide this UUID as context and the RD serves = that in its lookup results. The virtual and logical cases here should = also work. > =20 > You then need a DNS-like service to resolve the UUIDs / OCF URIs to = the preferred "socket address" (which depends on the communications). > =20 > Do I read you correctly that you want to ensure that the RD draft = reflects this explicitly? :) > =20 > Ciao > Matthias=20 > =20 > =20 > =20 > -------- Original message -------- > From: "Subramaniam, Ravi" > > Date: 5/19/16 19:34 (GMT+01:00)=20 > To: Kovatsch Matthias >, Michael Koster = > > Cc: "core@ietf.org WG " > > Subject: RE: [core] draft-ietf-core-resource-directory=20 > =20 > Hi Matthias, >=20 > Please see inline ... >=20 > Ravi >=20 > -----Original Message----- > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 > Sent: Thursday, May 19, 2016 10:22 AM > To: Subramaniam, Ravi >; Michael Koster = > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory >=20 > Yes, these are exactly the two cases to which I was referring: >=20 > virtual endpoints: The server on a single socket address uses the = Uri-Host to multiplex incoming requests (similar to Apache vhosts) = logical endpoints: The server uses the Uri-Path prefixes to multiplex, = like a gateway that translates to another technology and maps different = devices into its resource structure. >=20 > As Michael said, the RD will manage each list of links under a = different "endpoint name", but from the outside (on the lookup = interface) one will see just links that all point to the same socket = address. Using the "context", a server with virtual endpoints could = provide different authorities/Uri-Host names ("sub-domains") that would = also be visible in the list of links from the lookup interface. > [Ravi : ] One option is as you mention - where the RD does the = "resolution" and serves up resolved URIs (i.e. "resolved" URI-Hosts). = Another options is to have more stable URIs - i.e. URI-Host is something = like a UUID (that is context independent) or a hostname (that is unique = in context/domain) and then the Client retrieve the end point mappings = (either separately or together on the look up Resource) and then uses = that information to "resolve" the URIs on the Client. I am discussing = both approaches in OCF, since the latter will allow client to choose a = different comms technology if required while the former is useful for = homogeneous comms. Also the latter allows for separate resolution = schemes. >=20 > Best regards > Matthias >=20 > > -----Original Message----- > > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ] > > Sent: Donnerstag, 19. Mai 2016 17:05 > > To: Michael Koster >; Kovatsch Matthias=20 > > > > > Cc: core@ietf.org WG > > > Subject: RE: [core] draft-ietf-core-resource-directory > >=20 > > Hi Michael/Matthias, > >=20 > > Apologies if I am missing the point... > >=20 > > There are a couple of ways to interpret the use case that Matthias = indicates " > > The use case is a device/service with multiple virtual endpoints or = a=20 > > gateway that provides multiple logical endpoints." > >=20 > > 1. One is using the "authority" - in which case different=20 > > "authorities" map to the same endpoint - using multiple unique=20 > > endpoint ID (as authority) that maps to the same (socket) address. = In=20 > > this case the device/server would need to register the Resource URIs = and then endpoint information for each unique endpoint ID. > > 2. The other is to use the "path" - in this case only one endpoint=20= > > needs to be registered with RD. The server demuxes on info that the=20= > > server has embedded into the path. > >=20 > > Both these should be possible, right? > >=20 > > Ravi > >=20 > >=20 > > -----Original Message----- > > From: core [mailto:core-bounces@ietf.org = ] On Behalf Of Michael Koster > > Sent: Thursday, May 19, 2016 6:01 AM > > To: Kovatsch Matthias > > > Cc: core@ietf.org WG > > > Subject: Re: [core] draft-ietf-core-resource-directory > >=20 > > Hi Matthias > >=20 > > Yes, I believe this should be expected to work, though I have not=20 > > tested it with any implementation. > >=20 > > The RD should maintain a database by unique endpoint ID with=20 > > associated scheme/host/port addressing information that it = determines=20 > > from the request, or has been set explicitly with con=3D on = registration. > >=20 > > Of course, if the device registers the same resource in both=20 > > registrations, RD would return the same link value. > >=20 > > I will make a note to state this explicitly in the RD draft and=20 > > provide an example. > >=20 > > Best regards, > >=20 > > Michael > >=20 > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias=20 > > > > > > wrote: > > > > > > Hi Michael > > > > > > I got a question whether it is possible to register multiple=20 > > > endpoints (ep) from > > the same (socket) address. The use case is a device/service with=20 > > multiple virtual endpoints or a gateway that provides multiple = logical endpoints. > > > > > > I did not have the time to test this in my implementation, but = this=20 > > > should be > > possible out of the box: The same socket address registers each=20 > > virtual/logical endpoint with different endpoint names and receives=20= > > different handles > > (Location-Paths) from the RD. > > > > > > I propose to include an example in the document. > > > > > > Best regards > > > Matthias > >=20 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_FA0A9486-E5F1-4BCD-958E-37AFBAF99F5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

Michael

PS we may be able to define some sort of link structure and = "rel" value to register links that describe the endpoints along with the = resources, as was mentioned earlier. It could be a supplementary feature = to the internally stored registration parameters that are set using = query parameters. This could be another way to filter endpoint = parameters in addition to the ep lookup function.
On = May 20, 2016, at 10:12 AM, Subramaniam, Ravi <ravi.subramaniam@intel.com> wrote:

Right - Ravi
 
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 10:10 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Hi Ravi
 
I = think I got you now:
 
There is a look-up interface in RD = (probably the ep lookup to finally make it more useful :P) that will = return a list of two or more URIs, where one has the UUID in the = authority field and the remaining carry the transport-layer specific = addresses (and usually there are two URIs only in this list=E2=80=A6).
 
Best wishes
Matthias
 
 
From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] 
Sent: Freitag, 20. Mai 2016 = 19:06
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; = Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Hi = Matthias,
 
Maybe I was not clear =E2=80=93= the RD does not have to =E2=80=9Cresolve=E2=80=9D the UUID =E2=80=93 it = would not be possible when there are multiple endpoints. Also to allow = the demuxing with Authority for a single endpoint, the UUID has to be in = the URI =E2=80=93 which means the endpoint info has to be separated and = will be used in the messaging layer.
 
The difference is that instead of = =E2=80=9Clooking up UUID as a hostname=E2=80=9D in DNS, the ideas is to = make a request to a well-known =E2=80=9Cendpoint=E2=80=9D lookup = resource on the RD using UUID as a filter (well =E2=80=A6 there are a = few ways to do this here).
 
In either case of DNS or RD, it is a two-step = process. But if one uses RD there are opportunities to optimize which = will not be possible with an external system like DNS. (I guess I got = into the optimization before I was clear with the base model J )
 
Makes sense?
 
Ravi
 
From: Kovatsch = Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 9:54 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
I understood it is = about resolving the authority name/UUID/=E2=80=A6 in a URI to the socket = address. When this is handled by the RD and not an external service = (e.g., DNS), the RD has a problem to encode this in its responses, the = link lists. The latter are URI based, so either the URI has the = name/UUID/=E2=80=A6 which has the information for vhosts (e.g., fill the = Uri-Host option), but not the transport layer address or the URI has the = transport layer address in the authority field, but then lacks the = name/UUID/=E2=80=A6 for multiplexing virtual endpoints behind the same = transport layer address.
 
Maybe you just need the resolve feature = from RD, but not the vhost support. There are use cases for both = behaviors of the RD, so we should look into a way to accommodate both = explicitly, so there will not be issues depending on which RD = implementation on picks=E2=80=A6
 
Ciao
Matthias
 
From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] 
Sent: Freitag, 20. Mai 2016 = 18:45
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; = Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Matthias,
 
Yes, IMO, there are 3 approaches:
 
1.     Link attribute in the same link
2.    Separate links (endpoints as resources)
3.    Wellknown endpoint resource on RD for ep = lookups.
 
2 is = more flexible but requires additional setup interactions.
 
Basically try to use the available = CoRE paradigms for endpoint discovery (and optimize discovery). DNS has = been around and useful but technically it is a different system and = something that has to be deployed/available along with CoRE = implementations.
 
Ravi
 
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 9:21 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
When only relying on = the RD for such a resolution, there might be a problem with expressing = both the authority name and the socket address: The RD basically returns = URIs, which can only carry either. The additional information would need = to go into a link attribute=E2=80=A6
 
Ciao
Matthias
 
From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] 
Sent: Freitag, 20. Mai 2016 = 18:17
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; = Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Hi = Matthias,
 
Thanks = yes, that would be great. (Actually the =E2=80=9CDNS-like=E2=80=9D = service can be similar to Resource discovery and so a separate service = is not necessary).
 
BTW: = end point information can also be returned as part of Resource retrieval = =E2=80=93 so the resolution can be =E2=80=9Cpiggybacked=E2=80=9D even = though endpoint information is distinct. This depends on how the = endpoint information is represented. Need to read the draft to make sure = that this method is also possible.
 
Ravi
 
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 12:41 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
There shouldn't be any implication for RD = in this. The registering entity simply needs to provide this UUID as = context and the RD serves that in its lookup results. The virtual and = logical cases here should also work.
 
You then need a DNS-like service to resolve the UUIDs = / OCF URIs to the preferred "socket address" (which depends on the = communications).
 
Do I read you correctly that you want to ensure that = the RD draft reflects this explicitly? :)
 
Ciao
Matthias 
 
 
 
-------- Original = message --------
From: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>
Date: 5/19/16 19:34 (GMT+01:00) 
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, = Michael Koster <michaeljohnkoster@gmail.com>
Subject: RE: [core] draft-ietf-core-resource-directory 
 
Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: = Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: = Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi = <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: = [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was = referring:

virtual endpoints: The server on = a single socket address uses the Uri-Host to multiplex incoming requests = (similar to Apache vhosts) logical endpoints: The server uses the = Uri-Path prefixes to multiplex, like a gateway that translates to = another technology and maps different devices into its resource = structure.

As Michael said, the RD will = manage each list of links under a different "endpoint name", but from = the outside (on the lookup interface) one will see just links that all = point to the same socket address. Using the "context", a server with = virtual endpoints could provide different authorities/Uri-Host names = ("sub-domains") that would also be visible in the list of links from the = lookup interface.
[Ravi : ] One option is as you mention - = where the RD does the "resolution" and serves up resolved URIs (i.e. = "resolved" URI-Hosts). Another options is to have more stable URIs - = i.e. URI-Host is something like a UUID (that is context independent) or = a hostname (that is unique in context/domain) and then the Client = retrieve the end point mappings (either separately or together on the = look up Resource) and then uses that information to "resolve" the URIs = on the Client. I am discussing both approaches in OCF, since the latter = will allow client to choose a different comms technology if required = while the former is useful for homogeneous comms. Also the latter allows = for separate resolution schemes.

Best = regards
Matthias

> = -----Original Message-----
> From: Subramaniam, Ravi = [mailto:ravi.subramaniam@intel.com]
> = Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael = Koster <michaeljohnkoster@gmail.com>; Kovatsch Matthias 
> <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: = RE: [core] draft-ietf-core-resource-directory
> 
> Hi = Michael/Matthias,
> 
> = Apologies if I am missing the point...
> 
> There = are a couple of ways to interpret the use case that Matthias indicates = "
> The use case is a device/service with multiple = virtual endpoints or a 
> gateway = that provides multiple logical endpoints."
> 
> 1. One = is using the "authority" - in which case different 
> = "authorities" map to the same endpoint - using multiple unique 
> = endpoint ID (as authority) that maps to the same (socket) address. = In 
> = this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID.
> = 2. The other is to use the "path" - in this case only one endpoint 
> needs = to be registered with RD. The server demuxes on info that the 
> server = has embedded into the path.
> 
> Both = these should be possible, right?
> 
> Ravi
> 
> 
> -----Original Message-----
> From: core = [mailto:core-bounces@ietf.org] = On Behalf Of Michael Koster
> Sent: Thursday, May 19, = 2016 6:01 AM
> To: Kovatsch Matthias <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: = Re: [core] draft-ietf-core-resource-directory
> 
> Hi = Matthias
> 
> Yes, I = believe this should be expected to work, though I have not 
> tested = it with any implementation.
> 
> The RD = should maintain a database by unique endpoint ID with 
> = associated scheme/host/port addressing information that it = determines 
> from the request, or has been set explicitly with con=3D = on registration.
> 
> Of = course, if the device registers the same resource in both 
> = registrations, RD would return the same link value.
> 
> I will make a note to state this explicitly in the RD = draft and 
> provide an example.
> 
> Best = regards,
> 
> = Michael
> 
> > On = May 19, 2016, at 4:03 AM, Kovatsch Matthias 
> > = <kovatsch@inf.ethz.ch>
> wrote:
> >
> > = Hi Michael
> >
> > I got a = question whether it is possible to register multiple 
> > = endpoints (ep) from
> the same (socket) address. The = use case is a device/service with 
> = multiple virtual endpoints or a gateway that provides multiple logical = endpoints.
> >
> > I did not = have the time to test this in my implementation, but this 
> > = should be
> possible out of the box: The same socket = address registers each 
> = virtual/logical endpoint with different endpoint names and receives 
> = different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an = example in the document.
> >
> > = Best regards
> > Matthias
> 
> = _______________________________________________
> core = mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_FA0A9486-E5F1-4BCD-958E-37AFBAF99F5F-- From nobody Fri May 20 10:39:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1636C12DA93 for ; Fri, 20 May 2016 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C7L5lpUJ0u1 for ; Fri, 20 May 2016 10:39:37 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6512D1E4 for ; Fri, 20 May 2016 10:39:36 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 20 May 2016 10:39:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,340,1459839600"; d="scan'208,217";a="959017368" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by orsmga001.jf.intel.com with ESMTP; 20 May 2016 10:39:36 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX109.amr.corp.intel.com ([169.254.11.210]) with mapi id 14.03.0248.002; Fri, 20 May 2016 10:39:35 -0700 From: "Subramaniam, Ravi" To: Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WD///DvgIAAc5awgAB8iwD//+c0oIAAqgGAgABxBxD//5giAIAAdQSQ//+PoIAADpxLEAAOEJAAACpQueg= Date: Fri, 20 May 2016 17:39:34 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A7B5@MBX210.d.ethz.ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E020BB0745D34B6E8E76CBEBD6D5AE2Cintelcom_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 17:39:40 -0000 --_000_E020BB0745D34B6E8E76CBEBD6D5AE2Cintelcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Michael, I have used that approach as an option for OCF - if you guys are working on= endpoint link attributes and rel name (I used "ep" which may be lame), we = could compare notes so that our proposals are sync'd out of the gate. Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 On May 20, 2016, at 10:25 AM, Michael Koster > wrote: +1 Michael PS we may be able to define some sort of link structure and "rel" value to = register links that describe the endpoints along with the resources, as was= mentioned earlier. It could be a supplementary feature to the internally s= tored registration parameters that are set using query parameters. This cou= ld be another way to filter endpoint parameters in addition to the ep looku= p function. On May 20, 2016, at 10:12 AM, Subramaniam, Ravi > wrote: Right - Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 10:10 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Ravi I think I got you now: There is a look-up interface in RD (probably the ep lookup to finally make = it more useful :P) that will return a list of two or more URIs, where one h= as the UUID in the authority field and the remaining carry the transport-la= yer specific addresses (and usually there are two URIs only in this list=85= ). Best wishes Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 19:06 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Maybe I was not clear =96 the RD does not have to =93resolve=94 the UUID = =96 it would not be possible when there are multiple endpoints. Also to all= ow the demuxing with Authority for a single endpoint, the UUID has to be in= the URI =96 which means the endpoint info has to be separated and will be = used in the messaging layer. The difference is that instead of =93looking up UUID as a hostname=94 in DN= S, the ideas is to make a request to a well-known =93endpoint=94 lookup res= ource on the RD using UUID as a filter (well =85 there are a few ways to do= this here). In either case of DNS or RD, it is a two-step process. But if one uses RD t= here are opportunities to optimize which will not be possible with an exter= nal system like DNS. (I guess I got into the optimization before I was clea= r with the base model :) ) Makes sense? Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:54 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory I understood it is about resolving the authority name/UUID/=85 in a URI to = the socket address. When this is handled by the RD and not an external serv= ice (e.g., DNS), the RD has a problem to encode this in its responses, the = link lists. The latter are URI based, so either the URI has the name/UUID/= =85 which has the information for vhosts (e.g., fill the Uri-Host option), = but not the transport layer address or the URI has the transport layer addr= ess in the authority field, but then lacks the name/UUID/=85 for multiplexi= ng virtual endpoints behind the same transport layer address. Maybe you just need the resolve feature from RD, but not the vhost support.= There are use cases for both behaviors of the RD, so we should look into a= way to accommodate both explicitly, so there will not be issues depending = on which RD implementation on picks=85 Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:45 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Matthias, Yes, IMO, there are 3 approaches: 1. Link attribute in the same link 2. Separate links (endpoints as resources) 3. Wellknown endpoint resource on RD for ep lookups. 2 is more flexible but requires additional setup interactions. Basically try to use the available CoRE paradigms for endpoint discovery (a= nd optimize discovery). DNS has been around and useful but technically it i= s a different system and something that has to be deployed/available along = with CoRE implementations. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:21 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute=85 Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the =93DNS-like=94 service can b= e similar to Resource discovery and so a separate service is not necessary)= . BTW: end point information can also be returned as part of Resource retriev= al =96 so the resolution can be =93piggybacked=94 even though endpoint info= rmation is distinct. This depends on how the endpoint information is repres= ented. Need to read the draft to make sure that this method is also possibl= e. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_E020BB0745D34B6E8E76CBEBD6D5AE2Cintelcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Michael,

I have used that approach as an option for O= CF - if you guys are working on endpoint link attributes and rel name (I us= ed "ep" which may be lame), we could compare notes so that our pr= oposals are sync'd out of the gate.

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On May 20, 2016, at 10:25 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

+1

Michael

PS we may be able to define some sort of link structure and= "rel" value to register links that describe the endpoints along = with the resources, as was mentioned earlier. It could be a supplementary f= eature to the internally stored registration parameters that are set using query parameters. This could be another way = to filter endpoint parameters in addition to the ep lookup function.

On May 20, 2016, at 10:12 AM, Subramaniam, Ravi <ravi.subramaniam@intel.co= m> wrote:

Right - Ravi
 
From: Kovatsch Matthias [mailto:kovats= ch@inf.ethz.ch] 
Sent: F= riday, May 20, 2016 10:10 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com><= br class=3D""> Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Hi Ravi
 
I think I got you now:
 
There is a look-up interface in RD (probably th= e ep lookup to finally make it more useful :P) that will return a list of t= wo or more URIs, where one has the UUID in the authority field and the remaining carry the transport-layer specifi= c addresses (and usually there are two URIs only in this list=85).
 
Best wishes
Matthias
 
 
From:&= nbsp;Subramaniam, Ravi [mailto:ra= vi.subramaniam@intel.com] 
Sent: F= reitag, 20. Mai 2016 19:06
To: Kov= atsch Matthias <kovatsch@inf.ethz.ch>= ;; Michael Koster <michaeljohnkoste= r@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Hi Matthias,
 
Maybe I was not clear =96 the RD does not have to =93r= esolve=94 the UUID =96 it would not be possible when there are multiple end= points. Also to allow the demuxing with Authority for a single endpoint, the UUID has to be in the URI =96 which means the e= ndpoint info has to be separated and will be used in the messaging layer.
 
The difference is that instead of =93looking up UUID a= s a hostname=94 in DNS, the ideas is to make a request to a well-known =93e= ndpoint=94 lookup resource on the RD using UUID as a filter (well =85 there are a few ways to do this here).
 
In either case of DNS or RD, it is a two-step process.= But if one uses RD there are opportunities to optimize which will not be p= ossible with an external system like DNS. (I guess I got into the optimization before I was clear with the base= model J&n= bsp;)
 
Makes sense?
 
Ravi
 
From:&= nbsp;Kovatsch Matthias [mailto:kovatsch= @inf.ethz.ch] 
Sent: F= riday, May 20, 2016 9:54 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@inte= l.com>; Michael Koster <micha= eljohnkoster@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
I understood it is about resolving the authorit= y name/UUID/=85 in a URI to the socket address. When this is handled by the= RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the link lists= . The latter are URI based, so either the URI has the name/UUID/=85 which h= as the information for vhosts (e.g., fill the Uri-Host option), but not the= transport layer address or the URI has the transport layer address in the authority field, but then lacks the= name/UUID/=85 for multiplexing virtual endpoints behind the same transport= layer address.
 
Maybe you just need the resolve feature from RD= , but not the vhost support. There are use cases for both behaviors of the = RD, so we should look into a way to accommodate both explicitly, so there will not be issues depending on whic= h RD implementation on picks=85
 
Ciao
Matthias
 
From:&= nbsp;Subramaniam, Ravi [mailto:ra= vi.subramaniam@intel.com] 
Sent: F= reitag, 20. Mai 2016 18:45
To: Kov= atsch Matthias <kovatsch@inf.ethz.ch>= ;; Michael Koster <michaeljohnkoste= r@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Matthias,
 
Yes, IMO, there are 3 approaches:<= /o:p>
 
1.   &nbs= p; <= span style=3D"font-size: 11pt; font-family: 'Comic Sans MS'; color: rgb(153= , 51, 102);" class=3D"">Link attribute in the same link
2.    Separate links (endpoints as resources)
3.    Wellknown endpoint resource on RD for ep lookups.
 
2 is more flexible but requires additional setup i= nteractions.
 
Basically try to use the available CoRE paradigms = for endpoint discovery (and optimize discovery). DNS has been around and us= eful but technically it is a different system and something that has to be deployed/available along with CoRE imp= lementations.
 
Ravi
 
From:&= nbsp;Kovatsch Matthias [mailto:kovatsch= @inf.ethz.ch] 
Sent: F= riday, May 20, 2016 9:21 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@inte= l.com>; Michael Koster <micha= eljohnkoster@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
When only relying on the RD for such a resoluti= on, there might be a problem with expressing both the authority name and th= e socket address: The RD basically returns URIs, which can only carry either. The additional information would need t= o go into a link attribute=85
 
Ciao
Matthias
 
From:&= nbsp;Subramaniam, Ravi [mailto:ra= vi.subramaniam@intel.com] 
Sent: F= reitag, 20. Mai 2016 18:17
To: Kov= atsch Matthias <kovatsch@inf.ethz.ch>= ;; Michael Koster <michaeljohnkoste= r@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Hi Matthias,
 
Thanks yes, that would be great. (Actually the =93D= NS-like=94 service can be similar to Resource discovery and so a separate s= ervice is not necessary).
 
BTW: end point information can also be returned as = part of Resource retrieval =96 so the resolution can be =93piggybacked=94 e= ven though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read = the draft to make sure that this method is also possible.
 
Ravi
 
From:&= nbsp;Kovatsch Matthias [mailto:kovatsch= @inf.ethz.ch] 
Sent: F= riday, May 20, 2016 12:41 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@inte= l.com>; Michael Koster <micha= eljohnkoster@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work.
 
You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications).
 
Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :)
 
Ciao
Matthias 
 
 
 
-------- Original message --------
From: "Subramaniam, Ravi" <= ravi.subramaniam@intel.com>
Date: 5/19/16 19:34 (GMT+01:00)&n= bsp;
To: Kovatsch Matthias <kovatsch@inf.ethz.ch= >, Michael Koster <michaeljoh= nkoster@gmail.com>
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory 
 
Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kovatsch@inf.e= thz.ch] 
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <ravi.subramani= am@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <= ;core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:rav= i.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <michaeljohn= koster@gmail.com>; Kovatsch Matthias 
> <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org W= G <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
> 
> Hi Michael/Matthias,
> 
> Apologies if I am missing the point...
> 
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a<= span class=3D"Apple-converted-space"> 
> gateway that provides multiple logical endpoints."
> 
> 1. One is using the "authority" - in which case different 
> "authorities" map to the same endpoint - using multiple uniq= ue 
> endpoint ID (as authority) that maps to the same (socket) address. In<= span class=3D"Apple-converted-space"> 
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint 
> needs to be registered with RD. The server demuxes on info that the 
> server has embedded into the path.
> 
> Both these should be possible, right?
> 
> Ravi
> 
> 
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org= ] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kovatsch@inf.et= hz.ch>
> Cc: core@ietf.org W= G <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
> 
> Hi Matthias
> 
> Yes, I believe this should be expected to work, though I have not 
> tested it with any implementation.
> 
> The RD should maintain a database by unique endpoint ID with 
> associated scheme/host/port addressing information that it determines<= span class=3D"Apple-converted-space"> 
> from the request, or has been set explicitly with con=3D on registrati= on.
> 
> Of course, if the device registers the same resource in both 
> registrations, RD would return the same link value.
> 
> I will make a note to state this explicitly in the RD draft and 
> provide an example.
> 
> Best regards,
> 
> Michael
> 
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias 
> > <kovatsch@inf.ethz.ch>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple 
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with 
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is 
> > should be
> possible out of the box: The same socket address registers each 
> virtual/logical endpoint with different endpoint names and receives 
> different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--_000_E020BB0745D34B6E8E76CBEBD6D5AE2Cintelcom_-- From nobody Fri May 20 10:58:29 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375FF12DABC for ; Fri, 20 May 2016 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytJ6qrjeAWCA for ; Fri, 20 May 2016 10:58:23 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EBB12DAAD for ; Fri, 20 May 2016 10:58:22 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id qo8so42024860pab.1 for ; Fri, 20 May 2016 10:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=uG5F3NgJMBCBTj9mdxIqJPfWwUnqYRm29SEiWvG8Yvo=; b=TpF5vd8WBM3H44HzE7Km/O5cM+ULDLEA72Uxn8iIpmstZLUkWVQxN6OL4XvZTvd9BP w3lkoMXNY8WycFJ5Oe1Ec38fYPMHK4YBEh0rKCRNo1E8sQjS0V29hmf/Fdsptg8QxFc6 xOwaKfUqAqMkbYrVCq74HTUF4UMpmhTidn0+WhqkkU3ANSgJfVnM2Tqo032mf/JSYx0l zfqRymskSaTv38QA8bzc6AJsQCNcIP4GoJrBnZQ7SQh8lH3xygcQZyeI7s32xfd1iXKS zEkiOsI2PObuaGGvaGAs/8nHF8AJblyZriAH0jbUfV6WFs1buRlCEZ07gcUlla9qOQ+2 BR4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uG5F3NgJMBCBTj9mdxIqJPfWwUnqYRm29SEiWvG8Yvo=; b=aOvK0KBLMeSQKFRO0XssSfEO1r0UX7DjovYQCSFitrCYEF8D1ZHNi+4bVHmAiU4Fvh 9t00VqEqnLOiZmtCE5HOfISUIvBKkOEU354xJOp1xP3/T0BgSfz5HL2imuytpfcZrhPY 4oxcXhte8pDEPlSDlLrQl1EGZZRtES6LnwiOpIqvOvIRzdW92HQDM1x7l3OeqU+S1gv2 XDhrgdpssKuBMyy0Wlgi9JtpxOOw+VfPCOV5yzSdvlk4qw7DqeZ5l86MB1TP3fAuujte RwIQLABnOVs89fivT7jPR0mi5qMsM9IbttJCMzWrOu0Uaub3gq4a2onPyNPQLM8OOoAP 9y1g== X-Gm-Message-State: AOPr4FWzfPZH5DV39DOhawCURP1RvXaV+QKPu3Ljml+4rT2wZVfy0ZoQvvDpPFakwGU6zA== X-Received: by 10.66.248.6 with SMTP id yi6mr6761626pac.86.1463767101923; Fri, 20 May 2016 10:58:21 -0700 (PDT) Received: from [10.0.0.7] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id r86sm28700017pfb.21.2016.05.20.10.58.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 May 2016 10:58:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DAE88301-CC79-41CA-A8BF-D2E5FFAD3AFF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Fri, 20 May 2016 10:58:18 -0700 Message-Id: <285D4E98-A3CE-46CA-9AC3-0D6840F94314@gmail.com> References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A7B5@MBX210.d.ethz.ch> To: Ravi Subramaniam X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 17:58:27 -0000 --Apple-Mail=_DAE88301-CC79-41CA-A8BF-D2E5FFAD3AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ravi, I just went over the endpoint stuff I could find and it looks like the = use case could be described as late binding of transfer protocols. = Resolution of the protocol URL amounts to dereferencing a binding. It = seems like each endpoint will contain the same resources, and only = differ by transfer scheme and layers below that. Is this accurate? In CoRE RD, that binding of OCF UUID based URL to bound protocol URL = could be done in more than one way.=20 1. You could register an "RD endpoint" for each transfer layer scheme = available (with associated transport, network, etc.) and give them all a = common endpoint type ID, maybe using the UUID, but unique endpoint = names. All resource links would need to be registered under each = endpoint. Then you could lookup endpoints by using the UUID as endpoint = type, and this could return endpoint URIs, which you could then use to = lookup resources. You could also use this registration scheme to do = resource lookup by UUID, which will return a list full URLs to resources = in all endpoints that matches the lookup, including the endpoint scheme, = authority, and port. The client can then select the appropriate link by = scheme. 2. Another way is to register the resources using the UUID as endpoint = name, and register a link describing each protocol binding. The lookup = would need to be done separately for bindings and resources, but the = client could remember it's favorite protocol URI for each endpoint and = not need to look it up each time. I imagine there are other ways; what do you think? Michael > On May 20, 2016, at 10:39 AM, Subramaniam, Ravi = wrote: >=20 > Hi Michael, >=20 > I have used that approach as an option for OCF - if you guys are = working on endpoint link attributes and rel name (I used "ep" which may = be lame), we could compare notes so that our proposals are sync'd out of = the gate. >=20 > Ravi Subramaniam > Principal Engineer > Intel - (408) 765-3566 >=20 > On May 20, 2016, at 10:25 AM, Michael Koster = > = wrote: >=20 >> +1 >>=20 >> Michael >>=20 >> PS we may be able to define some sort of link structure and "rel" = value to register links that describe the endpoints along with the = resources, as was mentioned earlier. It could be a supplementary feature = to the internally stored registration parameters that are set using = query parameters. This could be another way to filter endpoint = parameters in addition to the ep lookup function. >>=20 >>> On May 20, 2016, at 10:12 AM, Subramaniam, Ravi = > wrote: >>>=20 >>> Right - Ravi >>> =20 >>> <>From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 >>> Sent: Friday, May 20, 2016 10:10 AM >>> To: Subramaniam, Ravi >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>> =20 >>> Hi Ravi >>> =20 >>> I think I got you now: >>> =20 >>> There is a look-up interface in RD (probably the ep lookup to = finally make it more useful :P) that will return a list of two or more = URIs, where one has the UUID in the authority field and the remaining = carry the transport-layer specific addresses (and usually there are two = URIs only in this list=85). >>> =20 >>> Best wishes >>> Matthias >>> =20 >>> =20 >>> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ]=20 >>> Sent: Freitag, 20. Mai 2016 19:06 >>> To: Kovatsch Matthias >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>> =20 >>> Hi Matthias, >>> =20 >>> Maybe I was not clear =96 the RD does not have to =93resolve=94 the = UUID =96 it would not be possible when there are multiple endpoints. = Also to allow the demuxing with Authority for a single endpoint, the = UUID has to be in the URI =96 which means the endpoint info has to be = separated and will be used in the messaging layer. >>> =20 >>> The difference is that instead of =93looking up UUID as a hostname=94 = in DNS, the ideas is to make a request to a well-known =93endpoint=94 = lookup resource on the RD using UUID as a filter (well =85 there are a = few ways to do this here). >>> =20 >>> In either case of DNS or RD, it is a two-step process. But if one = uses RD there are opportunities to optimize which will not be possible = with an external system like DNS. (I guess I got into the optimization = before I was clear with the base model J ) >>> =20 >>> Makes sense? >>> =20 >>> Ravi >>> =20 >>> From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 >>> Sent: Friday, May 20, 2016 9:54 AM >>> To: Subramaniam, Ravi >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>> =20 >>> I understood it is about resolving the authority name/UUID/=85 in a = URI to the socket address. When this is handled by the RD and not an = external service (e.g., DNS), the RD has a problem to encode this in its = responses, the link lists. The latter are URI based, so either the URI = has the name/UUID/=85 which has the information for vhosts (e.g., fill = the Uri-Host option), but not the transport layer address or the URI has = the transport layer address in the authority field, but then lacks the = name/UUID/=85 for multiplexing virtual endpoints behind the same = transport layer address. >>> =20 >>> Maybe you just need the resolve feature from RD, but not the vhost = support. There are use cases for both behaviors of the RD, so we should = look into a way to accommodate both explicitly, so there will not be = issues depending on which RD implementation on picks=85 >>> =20 >>> Ciao >>> Matthias >>> =20 >>> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ]=20 >>> Sent: Freitag, 20. Mai 2016 18:45 >>> To: Kovatsch Matthias >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>> =20 >>> Matthias, >>> =20 >>> Yes, IMO, there are 3 approaches: >>> =20 >>> 1. Link attribute in the same link >>> 2. Separate links (endpoints as resources) >>> 3. Wellknown endpoint resource on RD for ep lookups. >>> =20 >>> 2 is more flexible but requires additional setup interactions. >>> =20 >>> Basically try to use the available CoRE paradigms for endpoint = discovery (and optimize discovery). DNS has been around and useful but = technically it is a different system and something that has to be = deployed/available along with CoRE implementations. >>> =20 >>> Ravi >>> =20 >>> From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 >>> Sent: Friday, May 20, 2016 9:21 AM >>> To: Subramaniam, Ravi >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>> =20 >>> When only relying on the RD for such a resolution, there might be a = problem with expressing both the authority name and the socket address: = The RD basically returns URIs, which can only carry either. The = additional information would need to go into a link attribute=85 >>> =20 >>> Ciao >>> Matthias >>> =20 >>> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ]=20 >>> Sent: Freitag, 20. Mai 2016 18:17 >>> To: Kovatsch Matthias >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>> =20 >>> Hi Matthias, >>> =20 >>> Thanks yes, that would be great. (Actually the =93DNS-like=94 = service can be similar to Resource discovery and so a separate service = is not necessary). >>> =20 >>> BTW: end point information can also be returned as part of Resource = retrieval =96 so the resolution can be =93piggybacked=94 even though = endpoint information is distinct. This depends on how the endpoint = information is represented. Need to read the draft to make sure that = this method is also possible. >>> =20 >>> Ravi >>> =20 >>> From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 >>> Sent: Friday, May 20, 2016 12:41 AM >>> To: Subramaniam, Ravi >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>> =20 >>> There shouldn't be any implication for RD in this. The registering = entity simply needs to provide this UUID as context and the RD serves = that in its lookup results. The virtual and logical cases here should = also work. >>> =20 >>> You then need a DNS-like service to resolve the UUIDs / OCF URIs to = the preferred "socket address" (which depends on the communications). >>> =20 >>> Do I read you correctly that you want to ensure that the RD draft = reflects this explicitly? :) >>> =20 >>> Ciao >>> Matthias=20 >>> =20 >>> =20 >>> =20 >>> -------- Original message -------- >>> From: "Subramaniam, Ravi" > >>> Date: 5/19/16 19:34 (GMT+01:00)=20 >>> To: Kovatsch Matthias >, Michael Koster = > >>> Cc: "core@ietf.org WG " > >>> Subject: RE: [core] draft-ietf-core-resource-directory=20 >>> =20 >>> Hi Matthias, >>>=20 >>> Please see inline ... >>>=20 >>> Ravi >>>=20 >>> -----Original Message----- >>> From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch = ]=20 >>> Sent: Thursday, May 19, 2016 10:22 AM >>> To: Subramaniam, Ravi >; Michael Koster = > >>> Cc: core@ietf.org WG > >>> Subject: RE: [core] draft-ietf-core-resource-directory >>>=20 >>> Yes, these are exactly the two cases to which I was referring: >>>=20 >>> virtual endpoints: The server on a single socket address uses the = Uri-Host to multiplex incoming requests (similar to Apache vhosts) = logical endpoints: The server uses the Uri-Path prefixes to multiplex, = like a gateway that translates to another technology and maps different = devices into its resource structure. >>>=20 >>> As Michael said, the RD will manage each list of links under a = different "endpoint name", but from the outside (on the lookup = interface) one will see just links that all point to the same socket = address. Using the "context", a server with virtual endpoints could = provide different authorities/Uri-Host names ("sub-domains") that would = also be visible in the list of links from the lookup interface. >>> [Ravi : ] One option is as you mention - where the RD does the = "resolution" and serves up resolved URIs (i.e. "resolved" URI-Hosts). = Another options is to have more stable URIs - i.e. URI-Host is something = like a UUID (that is context independent) or a hostname (that is unique = in context/domain) and then the Client retrieve the end point mappings = (either separately or together on the look up Resource) and then uses = that information to "resolve" the URIs on the Client. I am discussing = both approaches in OCF, since the latter will allow client to choose a = different comms technology if required while the former is useful for = homogeneous comms. Also the latter allows for separate resolution = schemes. >>>=20 >>> Best regards >>> Matthias >>>=20 >>> > -----Original Message----- >>> > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com = ] >>> > Sent: Donnerstag, 19. Mai 2016 17:05 >>> > To: Michael Koster >; Kovatsch Matthias=20 >>> > > >>> > Cc: core@ietf.org WG > >>> > Subject: RE: [core] draft-ietf-core-resource-directory >>> >=20 >>> > Hi Michael/Matthias, >>> >=20 >>> > Apologies if I am missing the point... >>> >=20 >>> > There are a couple of ways to interpret the use case that Matthias = indicates " >>> > The use case is a device/service with multiple virtual endpoints = or a=20 >>> > gateway that provides multiple logical endpoints." >>> >=20 >>> > 1. One is using the "authority" - in which case different=20 >>> > "authorities" map to the same endpoint - using multiple unique=20 >>> > endpoint ID (as authority) that maps to the same (socket) address. = In=20 >>> > this case the device/server would need to register the Resource = URIs and then endpoint information for each unique endpoint ID. >>> > 2. The other is to use the "path" - in this case only one endpoint=20= >>> > needs to be registered with RD. The server demuxes on info that = the=20 >>> > server has embedded into the path. >>> >=20 >>> > Both these should be possible, right? >>> >=20 >>> > Ravi >>> >=20 >>> >=20 >>> > -----Original Message----- >>> > From: core [mailto:core-bounces@ietf.org = ] On Behalf Of Michael Koster >>> > Sent: Thursday, May 19, 2016 6:01 AM >>> > To: Kovatsch Matthias > >>> > Cc: core@ietf.org WG > >>> > Subject: Re: [core] draft-ietf-core-resource-directory >>> >=20 >>> > Hi Matthias >>> >=20 >>> > Yes, I believe this should be expected to work, though I have not=20= >>> > tested it with any implementation. >>> >=20 >>> > The RD should maintain a database by unique endpoint ID with=20 >>> > associated scheme/host/port addressing information that it = determines=20 >>> > from the request, or has been set explicitly with con=3D on = registration. >>> >=20 >>> > Of course, if the device registers the same resource in both=20 >>> > registrations, RD would return the same link value. >>> >=20 >>> > I will make a note to state this explicitly in the RD draft and=20 >>> > provide an example. >>> >=20 >>> > Best regards, >>> >=20 >>> > Michael >>> >=20 >>> > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias=20 >>> > > > >>> > wrote: >>> > > >>> > > Hi Michael >>> > > >>> > > I got a question whether it is possible to register multiple=20 >>> > > endpoints (ep) from >>> > the same (socket) address. The use case is a device/service with=20= >>> > multiple virtual endpoints or a gateway that provides multiple = logical endpoints. >>> > > >>> > > I did not have the time to test this in my implementation, but = this=20 >>> > > should be >>> > possible out of the box: The same socket address registers each=20 >>> > virtual/logical endpoint with different endpoint names and = receives=20 >>> > different handles >>> > (Location-Paths) from the RD. >>> > > >>> > > I propose to include an example in the document. >>> > > >>> > > Best regards >>> > > Matthias >>> >=20 >>> > _______________________________________________ >>> > core mailing list >>> > core@ietf.org >>> > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_DAE88301-CC79-41CA-A8BF-D2E5FFAD3AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Ravi,

I = just went over the endpoint stuff I could find and it looks like the use = case could be described as late binding of transfer protocols. = Resolution of the protocol URL amounts to dereferencing a binding. It = seems like each endpoint will contain the same resources, and only = differ by transfer scheme and layers below that. Is this accurate?

In CoRE RD, that binding = of OCF UUID based URL to bound protocol URL could be done in more than = one way. 

1. You could register an "RD endpoint" for each transfer = layer scheme available (with associated transport, network, etc.) and = give them all a common endpoint type ID, maybe using the UUID, but = unique endpoint names. All resource links would need to be registered = under each endpoint. Then you could lookup endpoints by using the UUID = as endpoint type, and this could return endpoint URIs, which you could = then use to lookup resources. You could also use this registration = scheme to do resource lookup by UUID, which will return a list full URLs = to resources in all endpoints that matches the lookup, including the = endpoint scheme, authority, and port. The client can then select the = appropriate link by scheme.

2. Another way is to register the resources using the UUID = as endpoint name, and register a link describing each protocol binding. = The lookup would need to be done separately for bindings and resources, = but the client could remember it's favorite protocol URI for each = endpoint and not need to look it up each time.

I imagine there are other ways; what do = you think?

Michael


On May 20, 2016, at 10:39 AM, Subramaniam, Ravi <ravi.subramaniam@intel.com> wrote:

Hi Michael,

I have used that approach as an option for OCF - if you = guys are working on endpoint link attributes and rel name (I used "ep" = which may be lame), we could compare notes so that our proposals are = sync'd out of the gate.

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On May 20, 2016, at 10:25 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

+1

Michael

PS we may be able to define some sort of link structure = and "rel" value to register links that describe the endpoints along with = the resources, as was mentioned earlier. It could be a supplementary = feature to the internally stored registration parameters that are set using query parameters. This could be another = way to filter endpoint parameters in addition to the ep lookup = function.

On May 20, 2016, at 10:12 AM, Subramaniam, Ravi <ravi.subramaniam@intel.com> wrote:

Right - Ravi
 
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 10:10 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Hi Ravi
 
I think I got you now:
 
There is a look-up interface in RD = (probably the ep lookup to finally make it more useful :P) that will = return a list of two or more URIs, where one has the UUID in the authority field and the remaining carry the transport-layer = specific addresses (and usually there are two URIs only in this = list=85).
 
Best wishes
Matthias
 
 
From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] 
Sent: Freitag, 20. Mai 2016 = 19:06
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; = Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Hi Matthias,
=
 
Maybe I was not clear =96 the RD does not = have to =93resolve=94 the UUID =96 it would not be possible when there = are multiple endpoints. Also to allow the demuxing with Authority for a single endpoint, the UUID has to be in the URI =96 which means = the endpoint info has to be separated and will be used in the messaging = layer.
 
The difference is that instead of =93looking = up UUID as a hostname=94 in DNS, the ideas is to make a request to a = well-known =93endpoint=94 lookup resource on the RD using UUID as a filter (well =85 there are a few ways to do this here).
 
In either case of DNS or RD, it is a two-step = process. But if one uses RD there are opportunities to optimize which = will not be possible with an external system like DNS. (I guess I got into the optimization before I was clear with the = base model J )
 
Makes sense?
=
 
Ravi
 
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 9:54 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
I understood it is about resolving the = authority name/UUID/=85 in a URI to the socket address. When this is = handled by the RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the link = lists. The latter are URI based, so either the URI has the name/UUID/=85 = which has the information for vhosts (e.g., fill the Uri-Host option), = but not the transport layer address or the URI has the transport layer address in the authority field, but then lacks = the name/UUID/=85 for multiplexing virtual endpoints behind the same = transport layer address.
 
Maybe you just need the resolve feature = from RD, but not the vhost support. There are use cases for both = behaviors of the RD, so we should look into a way to accommodate both explicitly, so there will not be issues depending on = which RD implementation on picks=85
 
Ciao
Matthias
 
From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] 
Sent: Freitag, 20. Mai 2016 = 18:45
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; = Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Matthias,
 
Yes, IMO, there are 3 approaches:
 
1.     Link attribute in the same link
2.    Separate links (endpoints as resources)
3.    Wellknown endpoint resource on RD for ep lookups.
 
2 is more flexible but requires = additional setup interactions.
 
Basically try to use the available CoRE = paradigms for endpoint discovery (and optimize discovery). DNS has been = around and useful but technically it is a different system and something that has to be deployed/available along with CoRE = implementations.
 
Ravi
 
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 9:21 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
When only relying on the RD for such a = resolution, there might be a problem with expressing both the authority = name and the socket address: The RD basically returns URIs, which can only carry either. The additional information would = need to go into a link attribute=85
 
Ciao
Matthias
 
From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] 
Sent: Freitag, 20. Mai 2016 = 18:17
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; = Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
Hi Matthias,
 
Thanks yes, that would be great. (Actually = the =93DNS-like=94 service can be similar to Resource discovery and so a = separate service is not necessary).
 
BTW: end point information can also be = returned as part of Resource retrieval =96 so the resolution can be = =93piggybacked=94 even though endpoint information is distinct. This depends on how the endpoint information is represented. Need to = read the draft to make sure that this method is also possible.
 
Ravi
 
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Friday, May 20, 2016 12:41 = AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] = draft-ietf-core-resource-directory
 
There shouldn't be any implication for RD in this. The registering = entity simply needs to provide this UUID as context and the RD serves = that in its lookup results. The virtual and logical cases here should = also work.
 
You then need a DNS-like service to resolve the UUIDs / OCF URIs to the = preferred "socket address" (which depends on the communications).
 
Do I read you correctly that you want to ensure that the RD draft = reflects this explicitly? :)
 
Ciao
Matthias 
 
 
 
-------- Original message --------
From: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>
Date: 5/19/16 19:34 (GMT+01:00) 
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Michael Koster <michaeljohnkoster@gmail.com>
=
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory 
 
Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] 
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the = Uri-Host to multiplex incoming requests (similar to Apache vhosts) = logical endpoints: The server uses the Uri-Path prefixes to multiplex, = like a gateway that translates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different = "endpoint name", but from the outside (on the lookup interface) one will = see just links that all point to the same socket address. Using the = "context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains") that = would also be visible in the list of links from the lookup interface.
[Ravi : ] One option is as you mention - where the RD does the = "resolution" and serves up resolved URIs (i.e. "resolved" URI-Hosts). = Another options is to have more stable URIs - i.e. URI-Host is something = like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end = point mappings (either separately or together on the look up Resource) = and then uses that information to "resolve" the URIs on the Client. I am = discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if = required while the former is useful for homogeneous comms. Also the = latter allows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <michaeljohnkoster@gmail.com>; Kovatsch Matthias 
> <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
= > 
> Hi Michael/Matthias,
> 
> Apologies if I am missing the point...
> 
> There are a couple of ways to interpret the use case that Matthias = indicates "
> The use case is a device/service with multiple virtual endpoints or = a 
> gateway that provides multiple logical endpoints."
> 
> 1. One is using the "authority" - in which case different 
> "authorities" map to the same endpoint - using multiple unique 
> endpoint ID (as authority) that maps to the same (socket) address. = In 
> this case the device/server would need to register the Resource = URIs and then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one = endpoint 
= > needs to be registered with RD. The server demuxes on info that = the 
> server has embedded into the path.
> 
> Both these should be possible, right?
> 
> Ravi
> 
> 
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael = Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
= > 
> Hi Matthias
> 
> Yes, I believe this should be expected to work, though I have = not 
> tested it with any implementation.
> 
> The RD should maintain a database by unique endpoint ID with 
> associated scheme/host/port addressing information that it = determines 
> from the request, or has been set explicitly with con=3D on = registration.
> 
> Of course, if the device registers the same resource in both 
> registrations, RD would return the same link value.
> 
> I will make a note to state this explicitly in the RD draft = and 
> provide an example.
> 
> Best regards,
> 
> Michael
> 
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias 
> > <kovatsch@inf.ethz.ch>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register = multiple 
= > > endpoints (ep) from
> the same (socket) address. The use case is a device/service = with 
> multiple virtual endpoints or a gateway that provides multiple = logical endpoints.
> >
> > I did not have the time to test this in my implementation, but = this 
> > should be
> possible out of the box: The same socket address registers = each 
> virtual/logical endpoint with different endpoint names and = receives 
= > different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


= --Apple-Mail=_DAE88301-CC79-41CA-A8BF-D2E5FFAD3AFF-- From nobody Fri May 20 11:51:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739FC12D565 for ; Fri, 20 May 2016 11:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyml2mrU6qec for ; Fri, 20 May 2016 11:51:37 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82E12D5EF for ; Fri, 20 May 2016 11:51:27 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 20 May 2016 11:51:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,340,1459839600"; d="scan'208,217";a="985498864" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga002.fm.intel.com with ESMTP; 20 May 2016 11:51:27 -0700 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 20 May 2016 11:51:26 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.175]) by ORSMSX155.amr.corp.intel.com ([169.254.7.253]) with mapi id 14.03.0248.002; Fri, 20 May 2016 11:51:26 -0700 From: "Subramaniam, Ravi" To: Michael Koster Thread-Topic: [core] draft-ietf-core-resource-directory Thread-Index: AdGxvLDm6cXxN0zVQiundecfOtrvNwATHDIAAAr96WD///DvgIAAc5awgAB8iwD//+c0oIAAqgGAgABxBxD//5giAIAAdQSQ//+PoIAADpxLEAAOEJAAACpQuegARU76AACXbgqa Date: Fri, 20 May 2016 18:51:25 +0000 Message-ID: <465032FA-03FB-4A49-B6AD-DDF1D2763C79@intel.com> References: <55877B3AFB359744BA0F2140E36F52B551D498B5@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D49BEB@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A6DD@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A75B@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B551D4A7B5@MBX210.d.ethz.ch> , <285D4E98-A3CE-46CA-9AC3-0D6840F94314@gmail.com> In-Reply-To: <285D4E98-A3CE-46CA-9AC3-0D6840F94314@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_465032FA03FB4A49B6ADDDF1D2763C79intelcom_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 May 2016 18:51:40 -0000 --_000_465032FA03FB4A49B6ADDDF1D2763C79intelcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Michael, Please see inline ... Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 On May 20, 2016, at 10:58 AM, Michael Koster > wrote: Hi Ravi, I just went over the endpoint stuff I could find and it looks like the use = case could be described as late binding of transfer protocols. Resolution o= f the protocol URL amounts to dereferencing a binding. It seems like each e= ndpoint will contain the same resources, and only differ by transfer scheme= and layers below that. Is this accurate? [Ravi : ] Yes for the most part - the difference may be from how each of us= view "endpoint". In my view each endpoint may contain different resources = but a set of resources may share same set of endpoints. In CoRE RD, that binding of OCF UUID based URL to bound protocol URL could = be done in more than one way. 1. You could register an "RD endpoint" for each transfer layer scheme avail= able (with associated transport, network, etc.) and give them all a common = endpoint type ID, maybe using the UUID, but unique endpoint names. All reso= urce links would need to be registered under each endpoint. Then you could = lookup endpoints by using the UUID as endpoint type, and this could return = endpoint URIs, which you could then use to lookup resources. You could also= use this registration scheme to do resource lookup by UUID, which will ret= urn a list full URLs to resources in all endpoints that matches the lookup,= including the endpoint scheme, authority, and port. The client can then se= lect the appropriate link by scheme. [Ravi :] this is similar to the server resolution scheme I mentioned in pas= sing. As I see it, the are issues with this approach since endpoint informa= tion can change over the lifetime of a resource the book keeping is harder = and there is storage implication. Also the servers view may not be a client= view (eg firewall) 2. Another way is to register the resources using the UUID as endpoint name= , and register a link describing each protocol binding. The lookup would ne= ed to be done separately for bindings and resources, but the client could r= emember it's favorite protocol URI for each endpoint and not need to look i= t up each time. [Ravi : ] This is the option being used because not only does it allow the = URI to be stable but also allows a use of different endpoint dynamically. T= his allows endpoint info to be provided separately and possibly different s= ources while server only provides the stable URI. There may be issues here = too and it may be that I am too biased to see :-) I imagine there are other ways; what do you think? The RD could be a hybrid too Michael On May 20, 2016, at 10:39 AM, Subramaniam, Ravi > wrote: Hi Michael, I have used that approach as an option for OCF - if you guys are working on= endpoint link attributes and rel name (I used "ep" which may be lame), we = could compare notes so that our proposals are sync'd out of the gate. Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 On May 20, 2016, at 10:25 AM, Michael Koster > wrote: +1 Michael PS we may be able to define some sort of link structure and "rel" value to = register links that describe the endpoints along with the resources, as was= mentioned earlier. It could be a supplementary feature to the internally s= tored registration parameters that are set using query parameters. This cou= ld be another way to filter endpoint parameters in addition to the ep looku= p function. On May 20, 2016, at 10:12 AM, Subramaniam, Ravi > wrote: Right - Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 10:10 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Ravi I think I got you now: There is a look-up interface in RD (probably the ep lookup to finally make = it more useful :P) that will return a list of two or more URIs, where one h= as the UUID in the authority field and the remaining carry the transport-la= yer specific addresses (and usually there are two URIs only in this list=85= ). Best wishes Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 19:06 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Maybe I was not clear =96 the RD does not have to =93resolve=94 the UUID = =96 it would not be possible when there are multiple endpoints. Also to all= ow the demuxing with Authority for a single endpoint, the UUID has to be in= the URI =96 which means the endpoint info has to be separated and will be = used in the messaging layer. The difference is that instead of =93looking up UUID as a hostname=94 in DN= S, the ideas is to make a request to a well-known =93endpoint=94 lookup res= ource on the RD using UUID as a filter (well =85 there are a few ways to do= this here). In either case of DNS or RD, it is a two-step process. But if one uses RD t= here are opportunities to optimize which will not be possible with an exter= nal system like DNS. (I guess I got into the optimization before I was clea= r with the base model :) ) Makes sense? Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:54 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory I understood it is about resolving the authority name/UUID/=85 in a URI to = the socket address. When this is handled by the RD and not an external serv= ice (e.g., DNS), the RD has a problem to encode this in its responses, the = link lists. The latter are URI based, so either the URI has the name/UUID/= =85 which has the information for vhosts (e.g., fill the Uri-Host option), = but not the transport layer address or the URI has the transport layer addr= ess in the authority field, but then lacks the name/UUID/=85 for multiplexi= ng virtual endpoints behind the same transport layer address. Maybe you just need the resolve feature from RD, but not the vhost support.= There are use cases for both behaviors of the RD, so we should look into a= way to accommodate both explicitly, so there will not be issues depending = on which RD implementation on picks=85 Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:45 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Matthias, Yes, IMO, there are 3 approaches: 1. Link attribute in the same link 2. Separate links (endpoints as resources) 3. Wellknown endpoint resource on RD for ep lookups. 2 is more flexible but requires additional setup interactions. Basically try to use the available CoRE paradigms for endpoint discovery (a= nd optimize discovery). DNS has been around and useful but technically it i= s a different system and something that has to be deployed/available along = with CoRE implementations. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 9:21 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory When only relying on the RD for such a resolution, there might be a problem= with expressing both the authority name and the socket address: The RD bas= ically returns URIs, which can only carry either. The additional informatio= n would need to go into a link attribute=85 Ciao Matthias From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] Sent: Freitag, 20. Mai 2016 18:17 To: Kovatsch Matthias >; = Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Thanks yes, that would be great. (Actually the =93DNS-like=94 service can b= e similar to Resource discovery and so a separate service is not necessary)= . BTW: end point information can also be returned as part of Resource retriev= al =96 so the resolution can be =93piggybacked=94 even though endpoint info= rmation is distinct. This depends on how the endpoint information is repres= ented. Need to read the draft to make sure that this method is also possibl= e. Ravi From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, May 20, 2016 12:41 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work. You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications). Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :) Ciao Matthias -------- Original message -------- From: "Subramaniam, Ravi" > Date: 5/19/16 19:34 (GMT+01:00) To: Kovatsch Matthias >, = Michael Koster > Cc: "core@ietf.org WG" > Subject: RE: [core] draft-ietf-core-resource-directory Hi Matthias, Please see inline ... Ravi -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Thursday, May 19, 2016 10:22 AM To: Subramaniam, Ravi >; Michael Koster > Cc: core@ietf.org WG > Subject: RE: [core] draft-ietf-core-resource-directory Yes, these are exactly the two cases to which I was referring: virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resourc= e structure. As Michael said, the RD will manage each list of links under a different "e= ndpoint name", but from the outside (on the lookup interface) one will see = just links that all point to the same socket address. Using the "context", = a server with virtual endpoints could provide different authorities/Uri-Hos= t names ("sub-domains") that would also be visible in the list of links fro= m the lookup interface. [Ravi : ] One option is as you mention - where the RD does the "resolution"= and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options i= s to have more stable URIs - i.e. URI-Host is something like a UUID (that i= s context independent) or a hostname (that is unique in context/domain) and= then the Client retrieve the end point mappings (either separately or toge= ther on the look up Resource) and then uses that information to "resolve" t= he URIs on the Client. I am discussing both approaches in OCF, since the la= tter will allow client to choose a different comms technology if required w= hile the former is useful for homogeneous comms. Also the latter allows for= separate resolution schemes. Best regards Matthias > -----Original Message----- > From: Subramaniam, Ravi [mailto:ravi.subramaniam@intel.com] > Sent: Donnerstag, 19. Mai 2016 17:05 > To: Michael Koster >; Kovatsch Matthias > > > Cc: core@ietf.org WG > > Subject: RE: [core] draft-ietf-core-resource-directory > > Hi Michael/Matthias, > > Apologies if I am missing the point... > > There are a couple of ways to interpret the use case that Matthias indica= tes " > The use case is a device/service with multiple virtual endpoints or a > gateway that provides multiple logical endpoints." > > 1. One is using the "authority" - in which case different > "authorities" map to the same endpoint - using multiple unique > endpoint ID (as authority) that maps to the same (socket) address. In > this case the device/server would need to register the Resource URIs and = then endpoint information for each unique endpoint ID. > 2. The other is to use the "path" - in this case only one endpoint > needs to be registered with RD. The server demuxes on info that the > server has embedded into the path. > > Both these should be possible, right? > > Ravi > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Michael Koster > Sent: Thursday, May 19, 2016 6:01 AM > To: Kovatsch Matthias > > Cc: core@ietf.org WG > > Subject: Re: [core] draft-ietf-core-resource-directory > > Hi Matthias > > Yes, I believe this should be expected to work, though I have not > tested it with any implementation. > > The RD should maintain a database by unique endpoint ID with > associated scheme/host/port addressing information that it determines > from the request, or has been set explicitly with con=3D on registration. > > Of course, if the device registers the same resource in both > registrations, RD would return the same link value. > > I will make a note to state this explicitly in the RD draft and > provide an example. > > Best regards, > > Michael > > > On May 19, 2016, at 4:03 AM, Kovatsch Matthias > > > > wrote: > > > > Hi Michael > > > > I got a question whether it is possible to register multiple > > endpoints (ep) from > the same (socket) address. The use case is a device/service with > multiple virtual endpoints or a gateway that provides multiple logical en= dpoints. > > > > I did not have the time to test this in my implementation, but this > > should be > possible out of the box: The same socket address registers each > virtual/logical endpoint with different endpoint names and receives > different handles > (Location-Paths) from the RD. > > > > I propose to include an example in the document. > > > > Best regards > > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_465032FA03FB4A49B6ADDDF1D2763C79intelcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Michael,

Please see inline ...

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On May 20, 2016, at 10:58 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi Ravi,

I just went over the endpoint stuff I could find and it loo= ks like the use case could be described as late binding of transfer protoco= ls. Resolution of the protocol URL amounts to dereferencing a binding. It s= eems like each endpoint will contain the same resources, and only differ by transfer scheme and layers below th= at. Is this accurate?
[Ravi : ] Yes for the most part - the difference may be from how each of us= view "endpoint". In my view each endpoint may contain different = resources but a set of resources may share same set of endpoints. 

In CoRE RD, that binding of OCF UUID based URL to bound pro= tocol URL could be done in more than one way. 

1. You could register an "RD endpoint" for each t= ransfer layer scheme available (with associated transport, network, etc.) a= nd give them all a common endpoint type ID, maybe using the UUID, but uniqu= e endpoint names. All resource links would need to be registered under each endpoint. Then you could lookup endpoints by u= sing the UUID as endpoint type, and this could return endpoint URIs, which = you could then use to lookup resources. You could also use this registratio= n scheme to do resource lookup by UUID, which will return a list full URLs to resources in all endpoints tha= t matches the lookup, including the endpoint scheme, authority, and port. T= he client can then select the appropriate link by scheme.
[Ravi :] this is similar to the server resolution scheme I mentioned in pas= sing. As I see it, the are issues with this approach since endpoint informa= tion can change over the lifetime of a resource the book keeping is harder = and there is storage implication. Also the servers view may not be a client view (eg firewall)

2. Another way is to register the resources using the UUID = as endpoint name, and register a link describing each protocol binding. The= lookup would need to be done separately for bindings and resources, but th= e client could remember it's favorite protocol URI for each endpoint and not need to look it up each time.
[Ravi : ] This is the option being used because not only does it allow= the URI to be stable but also allows a use of different endpoint dynamical= ly. This allows endpoint info to be provided separately and possibly differ= ent sources while server only provides the stable URI. There may be issues here too and it may be that I am too b= iased to see :-)

I imagine there are other ways; what do you think?
The RD could be a hybrid too

Michael


On May 20, 2016, at 10:39 AM, Subramaniam, Ravi <ravi.subramaniam@intel.co= m> wrote:

Hi Michael,

I have used that approach as an option for OCF - if you guy= s are working on endpoint link attributes and rel name (I used "ep&quo= t; which may be lame), we could compare notes so that our proposals are syn= c'd out of the gate.

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On May 20, 2016, at 10:25 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:<= br class=3D"">
+1

Michael

PS we may be able to define some sort of link structure and= "rel" value to register links that describe the endpoints along = with the resources, as was mentioned earlier. It could be a supplementary f= eature to the internally stored registration parameters that are set using query parameters. This could be another way = to filter endpoint parameters in addition to the ep lookup function.

On May 20, 2016, at 10:12 AM, Subramaniam, Ravi <ravi.subramaniam@intel.co= m> wrote:

Right - Ravi
 
From: Kovatsch Matthias [mailto:kovats= ch@inf.ethz.ch] 
Sent: F= riday, May 20, 2016 10:10 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@intel.com>; Michael Koster <michaeljohnkoster@gmail.com><= br class=3D""> Cc: core@ietf.org WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Hi Ravi
 
I think I got you now:
 
There is a look-up interface in RD (probably th= e ep lookup to finally make it more useful :P) that will return a list of t= wo or more URIs, where one has the UUID in the authority field and the remaining carry the transport-layer specifi= c addresses (and usually there are two URIs only in this list=85).
 
Best wishes
Matthias
 
 
From:&= nbsp;Subramaniam, Ravi [mailto:ra= vi.subramaniam@intel.com] 
Sent: F= reitag, 20. Mai 2016 19:06
To: Kov= atsch Matthias <kovatsch@inf.ethz.ch>= ;; Michael Koster <michaeljohnkoste= r@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Hi Matthias,
 
Maybe I was not clear =96 the RD does not have to =93r= esolve=94 the UUID =96 it would not be possible when there are multiple end= points. Also to allow the demuxing with Authority for a single endpoint, the UUID has to be in the URI =96 which means the e= ndpoint info has to be separated and will be used in the messaging layer.
 
The difference is that instead of =93looking up UUID a= s a hostname=94 in DNS, the ideas is to make a request to a well-known =93e= ndpoint=94 lookup resource on the RD using UUID as a filter (well =85 there are a few ways to do this here).
 
In either case of DNS or RD, it is a two-step process.= But if one uses RD there are opportunities to optimize which will not be p= ossible with an external system like DNS. (I guess I got into the optimization before I was clear with the base= model J&n= bsp;)
 
Makes sense?
 
Ravi
 
From:&= nbsp;Kovatsch Matthias [mailto:kovatsch= @inf.ethz.ch] 
Sent: F= riday, May 20, 2016 9:54 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@inte= l.com>; Michael Koster <micha= eljohnkoster@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
I understood it is about resolving the authorit= y name/UUID/=85 in a URI to the socket address. When this is handled by the= RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the link lists= . The latter are URI based, so either the URI has the name/UUID/=85 which h= as the information for vhosts (e.g., fill the Uri-Host option), but not the= transport layer address or the URI has the transport layer address in the authority field, but then lacks the= name/UUID/=85 for multiplexing virtual endpoints behind the same transport= layer address.
 
Maybe you just need the resolve feature from RD= , but not the vhost support. There are use cases for both behaviors of the = RD, so we should look into a way to accommodate both explicitly, so there will not be issues depending on whic= h RD implementation on picks=85
 
Ciao
Matthias
 
From:&= nbsp;Subramaniam, Ravi [mailto:ra= vi.subramaniam@intel.com] 
Sent: F= reitag, 20. Mai 2016 18:45
To: Kov= atsch Matthias <kovatsch@inf.ethz.ch>= ;; Michael Koster <michaeljohnkoste= r@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Matthias,
 
Yes, IMO, there are 3 approaches:<= /o:p>
 
1.   &nbs= p; <= span style=3D"font-size: 11pt; font-family: 'Comic Sans MS'; color: rgb(153= , 51, 102);" class=3D"">Link attribute in the same link
2.    Separate links (endpoints as resources)
3.    Wellknown endpoint resource on RD for ep lookups.
 
2 is more flexible but requires additional setup i= nteractions.
 
Basically try to use the available CoRE paradigms = for endpoint discovery (and optimize discovery). DNS has been around and us= eful but technically it is a different system and something that has to be deployed/available along with CoRE imp= lementations.
 
Ravi
 
From:&= nbsp;Kovatsch Matthias [mailto:kovatsch= @inf.ethz.ch] 
Sent: F= riday, May 20, 2016 9:21 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@inte= l.com>; Michael Koster <micha= eljohnkoster@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
When only relying on the RD for such a resoluti= on, there might be a problem with expressing both the authority name and th= e socket address: The RD basically returns URIs, which can only carry either. The additional information would need t= o go into a link attribute=85
 
Ciao
Matthias
 
From:&= nbsp;Subramaniam, Ravi [mailto:ra= vi.subramaniam@intel.com] 
Sent: F= reitag, 20. Mai 2016 18:17
To: Kov= atsch Matthias <kovatsch@inf.ethz.ch>= ;; Michael Koster <michaeljohnkoste= r@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
Hi Matthias,
 
Thanks yes, that would be great. (Actually the =93D= NS-like=94 service can be similar to Resource discovery and so a separate s= ervice is not necessary).
 
BTW: end point information can also be returned as = part of Resource retrieval =96 so the resolution can be =93piggybacked=94 e= ven though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read = the draft to make sure that this method is also possible.
 
Ravi
 
From:&= nbsp;Kovatsch Matthias [mailto:kovatsch= @inf.ethz.ch] 
Sent: F= riday, May 20, 2016 12:41 AM
To: Sub= ramaniam, Ravi <ravi.subramaniam@inte= l.com>; Michael Koster <micha= eljohnkoster@gmail.com>
Cc: core@ietf.org&= nbsp;WG <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory
 
There shouldn't be any implication for RD in this. The registering entity s= imply needs to provide this UUID as context and the RD serves that in its l= ookup results. The virtual and logical cases here should also work.
 
You then need a DNS-like service to resolve the UUIDs / OCF URIs to the pre= ferred "socket address" (which depends on the communications).
 
Do I read you correctly that you want to ensure that the RD draft reflects = this explicitly? :)
 
Ciao
Matthias 
 
 
 
-------- Original message --------
From: "Subramaniam, Ravi" <= ravi.subramaniam@intel.com>
Date: 5/19/16 19:34 (GMT+01:00)&n= bsp;
To: Kovatsch Matthias <kovatsch@inf.ethz.ch= >, Michael Koster <michaeljoh= nkoster@gmail.com>
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory 
 
Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:kovatsch@inf.e= thz.ch] 
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <ravi.subramani= am@intel.com>; Michael Koster <michaeljohnkoster@gmail.com>
Cc: core@ietf.org WG <= ;core@ietf.org>
Subject: RE: [core] draft-ietf-core-resource-directory

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host = to multiplex incoming requests (similar to Apache vhosts) logical endpoints= : The server uses the Uri-Path prefixes to multiplex, like a gateway that t= ranslates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different &q= uot;endpoint name", but from the outside (on the lookup interface) one= will see just links that all point to the same socket address. Using the &= quot;context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains"= ;) that would also be visible in the list of links from the lookup interfac= e.
[Ravi : ] One option is as you mention - where the RD does the "resolu= tion" and serves up resolved URIs (i.e. "resolved" URI-Hosts= ). Another options is to have more stable URIs - i.e. URI-Host is something= like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end po= int mappings (either separately or together on the look up Resource) and th= en uses that information to "resolve" the URIs on the Client. I a= m discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if req= uired while the former is useful for homogeneous comms. Also the latter all= ows for separate resolution schemes.

Best regards
Matthias

> -----Original Message-----
> From: Subramaniam, Ravi [mailto:rav= i.subramaniam@intel.com]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <michaeljohn= koster@gmail.com>; Kovatsch Matthias 
> <kovatsch@inf.ethz.ch>
> Cc: core@ietf.org W= G <core@ietf.org>
> Subject: RE: [core] draft-ietf-core-resource-directory
> 
> Hi Michael/Matthias,
> 
> Apologies if I am missing the point...
> 
> There are a couple of ways to interpret the use case that Matthias ind= icates "
> The use case is a device/service with multiple virtual endpoints or a<= span class=3D"Apple-converted-space"> 
> gateway that provides multiple logical endpoints."
> 
> 1. One is using the "authority" - in which case different 
> "authorities" map to the same endpoint - using multiple uniq= ue 
> endpoint ID (as authority) that maps to the same (socket) address. In<= span class=3D"Apple-converted-space"> 
> this case the device/server would need to register the Resource URIs a= nd then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one en= dpoint 
> needs to be registered with RD. The server demuxes on info that the 
> server has embedded into the path.
> 
> Both these should be possible, right?
> 
> Ravi
> 
> 
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org= ] On Behalf Of Michael Koster
> Sent: Thursday, May 19, 2016 6:01 AM
> To: Kovatsch Matthias <kovatsch@inf.et= hz.ch>
> Cc: core@ietf.org W= G <core@ietf.org>
> Subject: Re: [core] draft-ietf-core-resource-directory
> 
> Hi Matthias
> 
> Yes, I believe this should be expected to work, though I have not 
> tested it with any implementation.
> 
> The RD should maintain a database by unique endpoint ID with 
> associated scheme/host/port addressing information that it determines<= span class=3D"Apple-converted-space"> 
> from the request, or has been set explicitly with con=3D on registrati= on.
> 
> Of course, if the device registers the same resource in both 
> registrations, RD would return the same link value.
> 
> I will make a note to state this explicitly in the RD draft and 
> provide an example.
> 
> Best regards,
> 
> Michael
> 
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias 
> > <kovatsch@inf.ethz.ch>
> wrote:
> >
> > Hi Michael
> >
> > I got a question whether it is possible to register multiple 
> > endpoints (ep) from
> the same (socket) address. The use case is a device/service with 
> multiple virtual endpoints or a gateway that provides multiple logical= endpoints.
> >
> > I did not have the time to test this in my implementation, but th= is 
> > should be
> possible out of the box: The same socket address registers each 
> virtual/logical endpoint with different endpoint names and receives 
> different handles
> (Location-Paths) from the RD.
> >
> > I propose to include an example in the document.
> >
> > Best regards
> > Matthias
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


--_000_465032FA03FB4A49B6ADDDF1D2763C79intelcom_-- From nobody Sat May 21 00:45:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362B212B035 for ; Sat, 21 May 2016 00:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm4Bb8bZk0DS for ; Sat, 21 May 2016 00:44:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6BD12B01D for ; Sat, 21 May 2016 00:44:57 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 3C1451CC030D; Sat, 21 May 2016 09:44:56 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Core In-Reply-To: References: User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Sat, 21 May 2016 09:44:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 May 2016 07:45:00 -0000 Andy Bierman writes: > > 5.12. The "union" Type > > Leafs of type union MUST be encoded using the rules associated with > one of the types listed. > > C10) This does not really work because so many YANG types use > the same CBOR major encoding The receiving side will resolve the union type by the first union member type that matches the CBOR-encoded value. It's the same as in JSON encoding. > > type union { > type int32; > type enumeration { > enum A { value -5; } > enum B { value 3; } > } > type bits { > bit X { position 1; } > bit Y { position 3; } > } > type decimal64 { > fraction-digits 2; > } > } > > How do I know if '3' is for int32, enum B or bit Y? If it's major type 0 or 1, it will be int32 in this case because int32 is the first applicable member type. > How do I know 103 is really decimal64 "1.03" and not > an int32 "103"? If it's major type 0 or 1, then it will be again int32. However, 2147483648 would become 21474836.48 because that integer doesn't fit the int32 range. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat May 21 01:31:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601A212D534 for ; Sat, 21 May 2016 01:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsJn7MhWo8-l for ; Sat, 21 May 2016 01:31:04 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FC012B00F for ; Sat, 21 May 2016 01:31:04 -0700 (PDT) Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 0FF0DA80DF; Sat, 21 May 2016 10:31:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ubhW2ayaZW6W; Sat, 21 May 2016 10:31:01 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7A8D1A80D2; Sat, 21 May 2016 10:31:00 +0200 (CEST) Message-ID: <57401CC2.2040002@tzi.org> Date: Sat, 21 May 2016 10:30:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ladislav Lhotka References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 May 2016 08:31:06 -0000 Ladislav Lhotka wrote: > The receiving side will resolve the union type by the first union member > type that matches the CBOR-encoded value. It's the same as in JSON encoding. Or, at least, similar -- we are not always making the same serialization decisions. The weird aspect of this part of YANG is that the actual validity (and specific semantics and thus usefulness) of a union in the YANG module depends on the specifics of the serialization below. More frankly: Tying the semantics of a modeling language to one specific serialization mechanism is an utterly broken design. I'm not sure that it can be fixed, though, so we'll likely have to work around this breakage. What we were trying to figure out was the extent of the situations where a YANG module specifier might rely on the XML-specific way of resolving unions. Examples that seem painful: 1) type union { type enumeration { enum one; /* value 0 */ enum two; /* value 1 */ } type uint32; } Here, the XML will have the string "one" or "two", or a decimal string, which is unambiguous. The JSON encoding also has the string for enumerations, which we obviously want to replace by the numeric value in a compact encoding. We were thinking about possibly adding CBOR tags to disambiguate this. This becomes more insidious if this is an evolution from an earlier version that just said: type enumeration { ... } (We wouldn't want to sprinkle in tags just in case a type might possibly evolve into a union later.) 2) Also, just having a tag saying "this is an enumeration value" does not work for this case: type union { type enumeration { enum one; /* value 0 */ enum two; /* value 1 */ } type enumeration { enum alpha; /* value 0 */ enum beta; /* value 1 */ } } We haven't found a way yet to tag this case that is robust against further evolution of the YANG module. Clearly, YANG module specifiers will not rely on this when they are cognizant of concise encodings. However, relying on specification writers not doing this would mean that YANG modules have to be vetted for mistakes of this kind before they can be used in a CBOR environment after an exclusively XML/JSON life. (Maybe that actually *is* the answer -- if we could get pyang to detect this case and issue a warning, that might be enough.) Grüße, Carsten From nobody Sat May 21 01:36:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCFC12B074 for ; Sat, 21 May 2016 01:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mfnM8M9HnN2 for ; Sat, 21 May 2016 01:36:23 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C9112B025 for ; Sat, 21 May 2016 01:36:23 -0700 (PDT) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 02539FB8A7; Sat, 21 May 2016 10:36:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id JThdvnJXB6sx; Sat, 21 May 2016 10:36:20 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 57A71FB881; Sat, 21 May 2016 10:36:19 +0200 (CEST) Message-ID: <57401E02.6000409@tzi.org> Date: Sat, 21 May 2016 10:36:18 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ladislav Lhotka References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 May 2016 08:36:25 -0000 Ladislav Lhotka wrote: > The receiving side will resolve the union type by the first union member > type that matches the CBOR-encoded value. It's the same as in JSON encoding. Oh, and I also have a problem with requiring YANG-CBOR decoders to do this kind of "matching", which is: -- complex (you need a full constraint evaluator) -- not necessarily well-defined (prove that it is!) -- not necessarily even possible at the time of decoding (!) The example in Section 9.12.4 of draft-ietf-netmod-rfc6020bis-12.txt of a union data item retroactively (i.e., after decoding!?) turning into a string when the leaf that it was originally referencing was deleted is hilarious. Grüße, Carsten From nobody Sat May 21 04:29:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CD412D15A for ; Sat, 21 May 2016 04:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxW8gV6QDVBN for ; Sat, 21 May 2016 04:29:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671F012B02E for ; Sat, 21 May 2016 04:29:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 922DBAA9; Sat, 21 May 2016 13:29:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id eNT4rBwWk2D7; Sat, 21 May 2016 13:28:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 21 May 2016 13:29:00 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D195820050; Sat, 21 May 2016 13:29:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Tpp7CDY71KjM; Sat, 21 May 2016 13:28:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5195F2004E; Sat, 21 May 2016 13:28:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 697CA3AEA729; Sat, 21 May 2016 13:28:58 +0200 (CEST) Date: Sat, 21 May 2016 13:28:57 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20160521112857.GA4437@elstar.local> Mail-Followup-To: Carsten Bormann , Ladislav Lhotka , Core References: <57401CC2.2040002@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57401CC2.2040002@tzi.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 11:29:05 -0000 On Sat, May 21, 2016 at 10:30:58AM +0200, Carsten Bormann wrote: > Ladislav Lhotka wrote: > > The receiving side will resolve the union type by the first union member > > type that matches the CBOR-encoded value. It's the same as in JSON encoding. > > Or, at least, similar -- we are not always making the same serialization > decisions. > > The weird aspect of this part of YANG is that the actual validity (and > specific semantics and thus usefulness) of a union in the YANG module > depends on the specifics of the serialization below. YANG's native serialization of values are untyped strings. > More frankly: Tying the semantics of a modeling language to one specific > serialization mechanism is an utterly broken design. Not necessarily. It may start to look broken once you have serializations that are typed and for some reasons people think the type information should impact how YANG works (that assumes values serialized as untyped strings). Note that type rules differ for different serializations so you actually have no chance to get away without any weird corner cases. > I'm not sure that it can be fixed, though, so we'll likely have to work > around this breakage. I disagree that YANG is broken. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat May 21 06:15:30 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BED512D572 for ; Sat, 21 May 2016 06:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noPT0XSyXZbc for ; Sat, 21 May 2016 06:15:26 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B019212D0F4 for ; Sat, 21 May 2016 06:08:44 -0700 (PDT) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 26817FB8A9; Sat, 21 May 2016 15:08:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id VDJ7qGGugjSG; Sat, 21 May 2016 15:08:41 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 172A5FB883; Sat, 21 May 2016 15:08:40 +0200 (CEST) Message-ID: <57405DD6.2020109@tzi.org> Date: Sat, 21 May 2016 15:08:38 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Carsten Bormann , Ladislav Lhotka , Core References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> In-Reply-To: <20160521112857.GA4437@elstar.local> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 May 2016 13:15:28 -0000 Hi Jürgen, "broken" is indeed a strong word -- I deliberately used it as a way to provoke reactions, and that seems to have worked :-). > YANG's native serialization of values are untyped strings. Hmm. YANG is increasingly being positioned as a data modeling language. Unless my entire world revolves around TCL :-), my data models need a richer set of types than just strings. Having serialization details invade the (information and data) modeling levels is exactly what brought down XML, and finding that YANG inherits (a mild form of) these problems is very worrisome. > Not necessarily. It may start to look broken once you have > serializations that are typed and for some reasons people think the > type information should impact how YANG works (that assumes values > serialized as untyped strings). Note that type rules differ for > different serializations so you actually have no chance to get away > without any weird corner cases. Separation of concern between the data model level and the serialization level is an important aspect of a data modeling language -- processing rules should operate on the data model, not on the serialization (again, the related XML problem is rearing its head). >> I'm not sure that it can be fixed, though, so we'll likely have to work >> around this breakage. > > I disagree that YANG is broken. Well, I take that word back, but I do think this is one place where YANG as a data modeling language has a serious shortcoming, and it does not look likely that the YANG-CBOR mapping can work around that shortcoming in a particularly clean way. As a way of coping, we probably should develop some "best practices" (read: describe problematic cases) around the use of YANG unions that then at least can be considered by the YANG doctors for IETF modules. Grüße, Carsten From nobody Sat May 21 07:23:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A612D1E8 for ; Sat, 21 May 2016 07:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOJl0bxTMOlT for ; Sat, 21 May 2016 07:23:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE3112D0F8 for ; Sat, 21 May 2016 07:23:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1A72D1347; Sat, 21 May 2016 16:23:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 50MpPQQADpkQ; Sat, 21 May 2016 16:22:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 21 May 2016 16:23:26 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 176EA20051; Sat, 21 May 2016 16:23:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id frWN9TKcSdZS; Sat, 21 May 2016 16:23:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7160220050; Sat, 21 May 2016 16:23:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4A30B3AEA9FB; Sat, 21 May 2016 16:23:24 +0200 (CEST) Date: Sat, 21 May 2016 16:23:23 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20160521142323.GA4744@elstar.local> Mail-Followup-To: Carsten Bormann , Ladislav Lhotka , Core References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> <57405DD6.2020109@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <57405DD6.2020109@tzi.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 14:23:30 -0000 On Sat, May 21, 2016 at 03:08:38PM +0200, Carsten Bormann wrote: > Hi Jrgen, > > "broken" is indeed a strong word -- I deliberately used it as a way to > provoke reactions, and that seems to have worked :-). > > > YANG's native serialization of values are untyped strings. > > Hmm. YANG is increasingly being positioned as a data modeling language. > Unless my entire world revolves around TCL :-), my data models need a > richer set of types than just strings. YANG has a rich set of types. The native serialization is a textual format. > Having serialization details invade the (information and data) modeling > levels is exactly what brought down XML, and finding that YANG inherits > (a mild form of) these problems is very worrisome. > > > Not necessarily. It may start to look broken once you have > > serializations that are typed and for some reasons people think the > > type information should impact how YANG works (that assumes values > > serialized as untyped strings). Note that type rules differ for > > different serializations so you actually have no chance to get away > > without any weird corner cases. > > Separation of concern between the data model level and the serialization > level is an important aspect of a data modeling language -- processing > rules should operate on the data model, not on the serialization (again, > the related XML problem is rearing its head). I claim YANG itself is fine; the JSON encoding (the first encoding that has some (and please also not incompatible) typed encoding ended up needing YANG type information to do things right; this was not my favourite choice but I lost this debate. > >> I'm not sure that it can be fixed, though, so we'll likely have to work > >> around this breakage. > > > > I disagree that YANG is broken. > > Well, I take that word back, but I do think this is one place where YANG > as a data modeling language has a serious shortcoming, and it does not > look likely that the YANG-CBOR mapping can work around that shortcoming > in a particularly clean way. CBOR either does that same as JSON (which I agree leeds to some ugly cases) or CBOR hands at the end a string value over to the YANG type system (in particular in cases where it matters to get a string value). > As a way of coping, we probably should develop some "best practices" > (read: describe problematic cases) around the use of YANG unions that > then at least can be considered by the YANG doctors for IETF modules. If this can't be avoided, it is better to rely on tools rather than on YANG doctors. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat May 21 08:29:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EF712D173 for ; Sat, 21 May 2016 08:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCeSubc9ZpyU for ; Sat, 21 May 2016 08:29:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9472712D0C2 for ; Sat, 21 May 2016 08:29:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id x189so135191483ywe.3 for ; Sat, 21 May 2016 08:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=VabFiuOonX3ghd/TJKN0iaEReU4lwPqQ64Qk7/2m2Cg=; b=cbNMPJ+AFdp2jQ5m7GxzVtfnS/9SEb+C9Mu8c8vAj4Pqzdr058kHbuzYG6EDZUkGlS pI7RWLLHcnNZZXSSi/x4YudFmN/vgHkjNPWvKQOVIRVkUt6H9FXmTij3GKyScOw8sRxt KpvHwDO0WsngDp7oke2xmdd1X/+zm42eIJIW7ugJ5Iv0X+ZsjiZS3mVZBblHKivTOPSi xziwtQ/4ZMC7LCA7x3PbJnMkrLTz2RbyQpDB4iBA8xwcbIMqMtPGBdaRnTn1r2rMAQXC 0RxA6TXjoWXAjzIeRQkMiOazVb7EczqP6VeQ2tEZWzwAlDxJFY9TZGM0wMHrPkgPeSno SbYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=VabFiuOonX3ghd/TJKN0iaEReU4lwPqQ64Qk7/2m2Cg=; b=Xsjs+7cky472ybM9U/GpLN0G+UwJWo4t56cFomWCQhm1KrOGoipde0JcfadEx4S8Ph fndhlpV54QXnzQAN1BxGY8Uooe8a9QGN2116R2sawCaZH+y0y2YMssrjnU91ofU0kZvp qlnX2wujAjkdQJbu57ESwcSQlwMzWpDNNfSuskqV+xTlWIBv+iomJbD+QxOJcbnoyqTn KuEh8H2vP7NR8ftLSNAAkM9LQtyOvwIwFOOAqpc8Vh/fKPr+em/DEnXmggmWnFbHXeoq 1n+Az5wDvfmZsmsV4lqMOpM4FBQyxZsbJCNN6u+xOAo04Idwj/VlNIWrgPJO4FAntBNv eI3g== X-Gm-Message-State: AOPr4FWUX0Q0cnrR0HjLUHGJD5FxlNRoV47U+EUK3v9/iLVitHUaSt1eRPJ3JvdtId85QBAOpkVySZ/gn1OHsg== MIME-Version: 1.0 X-Received: by 10.129.137.129 with SMTP id z123mr5382214ywf.101.1463844573579; Sat, 21 May 2016 08:29:33 -0700 (PDT) Received: by 10.37.44.130 with HTTP; Sat, 21 May 2016 08:29:33 -0700 (PDT) In-Reply-To: <57401CC2.2040002@tzi.org> References: <57401CC2.2040002@tzi.org> Date: Sat, 21 May 2016 08:29:33 -0700 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: multipart/alternative; boundary=94eb2c06bf38d0beed05335bdf3b Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 May 2016 15:29:36 -0000 --94eb2c06bf38d0beed05335bdf3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, May 21, 2016 at 1:30 AM, Carsten Bormann wrote: > Ladislav Lhotka wrote: > > The receiving side will resolve the union type by the first union membe= r > > type that matches the CBOR-encoded value. It's the same as in JSON > encoding. > > Or, at least, similar -- we are not always making the same serialization > decisions. > > The weird aspect of this part of YANG is that the actual validity (and > specific semantics and thus usefulness) of a union in the YANG module > depends on the specifics of the serialization below. > More frankly: Tying the semantics of a modeling language to one specific > serialization mechanism is an utterly broken design. > I'm not sure that it can be fixed, though, so we'll likely have to work > around this breakage. > > What we were trying to figure out was the extent of the situations where > a YANG module specifier might rely on the XML-specific way of resolving > unions. > > I agree YANG is broken is the sense that the union type was not designed to work if the protocol encoding is not XML. Since every value node in XML is a string, the sender and receiver cannot get out of sync wrt/ which member type matches. This is a legal union type even though in XML type 'int32' would never be used because 'string' would match everything. leaf foo { type union { type string; type int32; } } This is a problem for config nodes: JSON/CBOR client sets { "foo" : 42 } XML client reads back 42 JSON (and CBOR) will send { "foo":42 }, not { "foo":"42" } if they intend t= o send the number, but XML cannot do the same. There is no problem unless XML is being used in addition to JSON or CBOR. Some solution choices: 1 - do nothing and let XML and JSON/CBOR be broken together (solution is do not use XML and JSON/CBOR together in the same server) 2 - force receiver to convert JSON/CBOR to a string for union type matching 3 - tag the data somehow so the receiver knows which union member type is being sent 4 - write YANG guidelines on how to design union types that will produce the same match with all encoding schemes IMO CBOR has to solve the enumeration and bits issues with (3) but for the problem in general, just do (4) Andy Examples that seem painful: > > 1) > > type union { > type enumeration { > enum one; /* value 0 */ > enum two; /* value 1 */ > } > type uint32; > } > > Here, the XML will have the string "one" or "two", or a decimal string, > which is unambiguous. The JSON encoding also has the string for > enumerations, which we obviously want to replace by the numeric value in > a compact encoding. > > We were thinking about possibly adding CBOR tags to disambiguate this. > This becomes more insidious if this is an evolution from an earlier > version that just said: > > type enumeration { > ... > } > > (We wouldn't want to sprinkle in tags just in case a type might possibly > evolve into a union later.) > > 2) > > Also, just having a tag saying "this is an enumeration value" does not > work for this case: > > type union { > type enumeration { > enum one; /* value 0 */ > enum two; /* value 1 */ > } > type enumeration { > enum alpha; /* value 0 */ > enum beta; /* value 1 */ > } > } > > We haven't found a way yet to tag this case that is robust against > further evolution of the YANG module. > > Clearly, YANG module specifiers will not rely on this when they are > cognizant of concise encodings. However, relying on specification > writers not doing this would mean that YANG modules have to be vetted > for mistakes of this kind before they can be used in a CBOR environment > after an exclusively XML/JSON life. (Maybe that actually *is* the > answer -- if we could get pyang to detect this case and issue a warning, > that might be enough.) > > Gr=C3=BC=C3=9Fe, Carsten > > --94eb2c06bf38d0beed05335bdf3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, May 21, 2016 at 1:30 AM, Carsten Bormann <= cabo@tzi.org> wrote:
Ladislav Lhotka wrote:
> The receiving side will resolve the union type by the first union memb= er
> type that matches the CBOR-encoded value. It's the same as in JSON= encoding.

Or, at least, similar -- we are not always making the same serialization decisions.

The weird aspect of this part of YANG is that the actual validity (and
specific semantics and thus usefulness) of a union in the YANG module
depends on the specifics of the serialization below.
More frankly: Tying the semantics of a modeling language to one specific serialization mechanism is an utterly broken design.
I'm not sure that it can be fixed, though, so we'll likely have to = work
around this breakage.

What we were trying to figure out was the extent of the situations where a YANG module specifier might rely on the XML-specific way of resolving
unions.



I agree YANG is broken = is the sense that the union type was not
designed to work if the = protocol encoding is not XML.
Since every value node in XML is a = string, the sender and
receiver cannot get out of sync wrt/ which= member type matches.


This is = a legal union type even though in XML type 'int32' would never be u= sed
because 'string' would match everything.
<= div>
=C2=A0leaf foo {
=C2=A0 =C2=A0type union {
=C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 typ= e int32;
=C2=A0 =C2=A0}
=C2=A0}

This is a problem for config nodes:
=C2=A0 =C2=A0JSON/CBOR= client sets { "foo" : 42 }
=C2=A0 =C2=A0XML client rea= ds back <foo>42</foo>

JSON (and = CBOR) will send { "foo":42 }, not { "foo":"42"= ; } if they intend to
send the number, but XML cannot do the same= .=C2=A0 There is no problem
unless XML is being used in addition = to JSON or CBOR.=C2=A0

Some solution choices:

=C2=A0 1 - do nothing and let XML and JSON/CBOR be bro= ken together
=C2=A0 =C2=A0 =C2=A0(solution is do not use XML and = JSON/CBOR together in the same server)
=C2=A0 2 - force receiver = to convert JSON/CBOR to a string for union type matching
=C2=A0 3= - tag the data somehow so the receiver knows which union member type is be= ing sent
=C2=A0 4 - write YANG guidelines on how to design union = types that will produce the same
=C2=A0 =C2=A0 =C2=A0match with a= ll encoding schemes

IMO CBOR has to solve the enum= eration and bits issues with (3) but
for the problem in general, = just do (4)


=C2=A0Andy

Examples that seem painful:

1)

=C2=A0type union {
=C2=A0 =C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum one; /* value 0 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum two; /* value 1 */
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 type uint32;
=C2=A0}

Here, the XML will have the string "one" or "two", or a= decimal string,
which is unambiguous.=C2=A0 The JSON encoding also has the string for
enumerations, which we obviously want to replace by the numeric value in a compact encoding.

We were thinking about possibly adding CBOR tags to disambiguate this.
This becomes more insidious if this is an evolution from an earlier
version that just said:

=C2=A0type enumeration {
=C2=A0 =C2=A0...
=C2=A0}

(We wouldn't want to sprinkle in tags just in case a type might possibl= y
evolve into a union later.)

2)

Also, just having a tag saying "this is an enumeration value" doe= s not
work for this case:

=C2=A0type union {
=C2=A0 =C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum one; /* value 0 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum two; /* value 1 */
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum alpha; /* value 0 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum beta; /* value 1 */
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0}

We haven't found a way yet to tag this case that is robust against
further evolution of the YANG module.

Clearly, YANG module specifiers will not rely on this when they are
cognizant of concise encodings.=C2=A0 However, relying on specification
writers not doing this would mean that YANG modules have to be vetted
for mistakes of this kind before they can be used in a CBOR environment
after an exclusively XML/JSON life.=C2=A0 (Maybe that actually *is* the
answer -- if we could get pyang to detect this case and issue a warning, that might be enough.)

Gr=C3=BC=C3=9Fe, Carsten


--94eb2c06bf38d0beed05335bdf3b-- From nobody Sun May 22 21:58:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5012D1EB; Sun, 22 May 2016 21:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGrl2hEajMcn; Sun, 22 May 2016 21:58:38 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7A912B054; Sun, 22 May 2016 21:58:38 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-e6-57428dfc4af2 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.DD.12926.CFD82475; Mon, 23 May 2016 06:58:36 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.153]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Mon, 23 May 2016 06:58:36 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-hartke-core-e2e-security-reqs@ietf.org" Thread-Topic: comments on draft-hartke-core-e2e-security-reqs Thread-Index: AdGf4rAvCqw3akY7QXOaQ6AVk7FT8AUzRKOA Date: Mon, 23 May 2016 04:58:35 +0000 Message-ID: References: <069a01d19fe7$c5f1e080$51d5a180$@augustcellars.com> In-Reply-To: <069a01d19fe7$c5f1e080$51d5a180$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <6CF066C56D11014AB1C5B24FDF8C182F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7ou6fXqdwg2tLlS32vV3PbLH/9jkm i9XTv7M5MHtsnDOdzWPJkp9MAUxRXDYpqTmZZalF+nYJXBmNc2ayFqwzrnjXvpSxgbHFqIuR k0NCwETi15qNLBC2mMSFe+vZuhi5OIQEjjBKLF00gRXCWcIo8aK/nRGkik3AReJBwyMmEFtE oItR4svkWhCbWUBZ4vjsw6wgtrCArcTt29uYIWrsJJomLYCqN5LYsaEfLM4ioCrx/PFtsM28 AhYSM3r2gtUICdhLbDm1lx3E5hRwkDjV/xmsnhHouu+n1jBB7BKXuPVkPhPE1QISS/acZ4aw RSVePv4HdoOogJ7EvhfnGSHiShIrtl8CsjmAejUl1u/S72JkBzKtJfYnQwxUlJjS/ZAd4hhB iZMzn7BMYJSYhWTXLITeWXC9s5D0zkLSu4CRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZG YBwe3PJbdQfj5TeOhxgFOBiVeHgfaDuFC7EmlhVX5h5ilOBgVhLhXVcNFOJNSaysSi3Kjy8q zUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cCYfzQrI+Og5+dFMiKha6e9C2dQ FN3QHMQru3yDeNmyXYLJ3yfwXL3oNsnb4hFXRJJY84z3P5WrtddLua19fspBrGDuuZz8qKBu 5Q0TNyhlv+vo2ep37uS0Q7FRLit+XVi8P3XTIkOmY9MdT06MKTubOe3N2ecf5zB4fLy97/G+ FyJhG3k9VsrOVGIpzkg01GIuKk4EABB3sXC/AgAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] comments on draft-hartke-core-e2e-security-reqs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 04:58:40 -0000 SmltDQoNClRoYW5rcyBmb3Igc3BlbmRpbmcgdGhlIHRpbWUgKGFuZCB0aGUgd2luZSkuDQoNClNv cnJ5IGZvciB0aGUgZGVsYXksIHdlIHdhbnRlZCB0byByZXNwb25kIGRpcmVjdGx5IHRvIHlvdXIg Y29tbWVudHMgd2l0aA0KYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCwgYnV0IHNpbmNl IGl0IHN0aWxsIGlzIG5vdCBxdWl0ZSByZWFkeSBJDQpqdXN0IHdhbnQgdG8gYWNrbm93bGVkZ2Ug eW91ciBtYWlsLiBXZSB3ZXJlIGFscmVhZHkgaW4gdGhlIHByb2Nlc3Mgb2YNCm1ha2luZyBhbiB1 cGRhdGUgdHJ5aW5nIHRvIGZpeCB0aGUgcmVwZXRpdGl2ZW5lc3Mgb2YgdGhlIC0wMCB2ZXJzaW9u LCBhbmQNCmluc3RlYWQgYnVpbGQgb24gZ2VuZXJpYyBpc3N1ZXMsIGZvY3VzIG9uIHRoZSBlbmRw b2ludHMgcmF0aGVyIHRoYW4gdGhlDQptaWRkbGUgZW50aXRpZXMgZXRjLiBzbyB0aG9zZSBhbmQg cmVsYXRlZCBjb21tZW50cyBtYWtlcyB2ZXJ5IG11Y2ggc2Vuc2UuDQoNClRoZW4gdGhlcmUgYXJl IG90aGVyIHBhcnRzIHRoYXQgd2UgbWF5IG5vdCBiZSBhYmxlIHRvIGRpc2N1c3Mgd2l0aGluIHRo ZQ0KZHJhZnQsIGxpa2UgZS5nLiB2YXJpb3VzIGNvbWJpbmF0aW9ucyBvZiBkaWZmZXJlbnQgdHlw ZSBvZiBwcm94aWVzICh0aG91Z2gNCnNob3VsZCBiZSBwb3NzaWJsZSB0byBpbmZlciBmcm9tIHRo ZSBkcmFmdCksIGFuZCBzb21lIHR5cGVzIG9mDQrigJxjb252ZXJzYXRpb25z4oCdIHdoaWNoIGFy ZSBub3QgeWV0IGRlZmluZWQgZm9yIENvQVAgKGxpa2UgbXVsdGljYXN0IHdpdGgNCm11bHRpY2Fz dCByZXBseSkuDQoNClN0YXkgdHVuZWQuDQoNCg0KR8O2cmFuDQoNCg0KT24gMjAxNi0wNC0yNiAy MDoxNiwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KPkFm dGVyIHRoZSBtZWV0aW5nIEkgdHJpZWQgdG8gZG8gYSBmcm9udCB0byBiYWNrIHJlYWRpbmcgb2Yg dGhpcyBkb2N1bWVudA0KPnNldmVyYWwgdGltZXMuICBJIHJlZ3JldCB0byBub3RlIHRoYXQgSSBv bmx5IHN1Y2NlZWRlZCBvbmNlIChhZnRlciBhYm91dCA0DQo+Z2xhc3NlcyBvZiB3aW5lKSwgYnV0 IHdpbGwgbm90ZSB0aGF0IEkgd2FzIHJlYWRpbmcgdGhpcyBvbiBhIEtpbmRsZSBhbmQNCj50aGVy ZWZvcmUgaXQgc3VmZmVyZWQgYm90aCBmcm9tIGEgc21hbGxlciBzY3JlZW4gYW5kIHNvbWUgZm9y bWF0dGluZw0KPmVycm9ycy4NCj4NCj5JIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCBzb21lIG1ham9y IGRvY3VtZW50IG92ZXJoYXVscyB0aGF0IEkgdGhpbmsgd291bGQNCj5ib3RoIGltcHJvdmUgdGhl IGFiaWxpdHkgdG8gcmVhZCB0aGUgZG9jdW1lbnQgYW5kIG1pZ2h0IChidXQgcHJvYmFibHkgd2ls bA0KPm5vdCkgYWRkcmVzcyBzb21lIG9mIHRoZSBjb25jZXJucyB0aGF0IEhhbm5lcyByYWlzZWQg YXQgdGhlIEYyRiBtZWV0aW5nLg0KPg0KPlRoZSBkb2N1bWVudCBpcyB2ZXJ5IHJlcGV0aXRpdmUu ICBUaGlzIG1ha2VzIHRoZSBkb2N1bWVudCBoYXJkZXIgdG8gcmVhZA0KPmFzDQo+b25lIGdldCBj b25mdXNlZCBhbmQgYm9yZWQgYnkgZGVhbGluZyB3aXRoIHRoZSBzYW1lIHN0YXRlbWVudHMgb3Zl ciBhbmQNCj5vdmVyDQo+YWdhaW4uICBUbyBkZWFsIHdpdGggdGhpcywgSSB3b3VsZCBzdWdnZXN0 IHRoYXQgdGhpbmdzIGJlIGJ1aWx0IG9uIHJhdGhlcg0KPnRoYW4gcmVwZWF0ZWQuIFRoaXMgbWVh bnMgdGhhdCBvbmUgY2FuIHN0YXJ0IHdpdGggYSBnZW5lcmljIHByb3h5IGluIHRoZQ0KPmZpcnN0 IHNlY3Rpb24gYW5kIGRlYWwgd2l0aCB0aGUgaXNzdWVzIG9mIHRoYXQgY2FzZSBhbmQgdGhlbiB0 aGUgcmVzdCBvZg0KPnRoZQ0KPnRpbWUgb25lIGNhbiBqdXN0IHNheSAtIHRob3NlIHRoaW5ncyBw bHVzIHRoZSBmb2xsb3dpbmcgd2l0aG91dA0KPnJlcGV0aXRpb24uIA0KPg0KPkkgZG9uJ3QgbGlr ZSB0aGUgc2NlbmFyaW8gYmFzZWQgc3RydWN0dXJlIG9mIHRoZSBkb2N1bWVudC4gIE9uZSBvZiB0 aGUNCj5wcm9ibGVtcyB0aGF0IEkgaGF2ZSBpcyB0aGF0IHRoZSBsaXN0IG9mIHNjZW5hcmlvcyBp cyBnb2luZyB0byBiZSBlbmRsZXNzDQo+YW5kIGRpZmZpY3VsdCB0byB0aGluayBhYm91dCBpbiBh biBleGhhdXN0aXZlIG1hbm5lci4gIE9uZSBzdGFydHMgd2l0aCB0aGUNCj5xdWVzdGlvbnMgb2Yg d2hhdCBoYXBwZW5zIHdoZW4geW91IGhhdmUgYSBzaXR1YXRpb24gb2YgZGVhbGluZyB3aXRoDQo+ c2NlbmFyaW8NCj4jMSBhbmQgdGhlbiAjMiBhbmQgdGhlbiB3aGF0IGhhcHBlbnMgd2hlbiB5b3Ug Y29tcG9zZSAjMSBhbmQgIzIgKG9yICMyIGFuZA0KPiMxKS4gIEkgdGhpbmsgdGhhdCBpdCB3b3Vs ZCBiZSBiZXR0ZXIgdG8gZm9jdXMgb24gdGhlIGRpZmZlcmVudCB0eXBlcyBvZg0KPnByb3hpZXMg dGhhdCBjYW4gYmUgaWRlbnRpZmllZCBhbmQgdGhlbiBnbyBvbiBmcm9tIHRoZXJlLiAgVGhpcyBt YWtlcyBpdA0KPmVhc2llciB0byB0aGluayBhYm91dCB3aGF0IG5lZWRzIHRvIGJlIHBsYWNlZCBp biBhIG5ldyBkb2N1bWVudCB0aGF0DQo+ZGVmaW5lcw0KPmEgbmV3IHByb3h5IHR5cGUgYXMgd2Vs bC4NCj4NCj5Gb3IgZWFjaCBkaWZmZXJlbnQgcHJveHkgdHlwZSBJIHdvdWxkIGxvb2sgYXQgY292 ZXJpbmcgdGhlIGZvbGxvd2luZzoNCj4qKiBHZW5lcmljIERlc2NyaXB0aW9uIG9mIHdoYXQgdGhl IHByb3h5IHR5cGUgZG9lcw0KPioqIFdoYXQgaXQgbWVhbnMgZm9yIHRoZSBwcm94eSB0byBiZSAx KSB1bnRydXN0ZWQsIDIpIHNlbWktdHJ1c3RlZCBhbmQgMykNCj5mdWxseSB0cnVzdGVkLiAgTm90 ZSB0aGF0IG5vdCBhbGwgb2YgdGhlc2UgYXJlIGFwcGxpY2FibGUgdG8gYW55IGdpdmVuDQo+cHJv eHkNCj50eXBlLiAgKEZvciBleGFtcGxlLCBpZiBvbmUgbG9va3MgYXQgYSBOQVQgcHJveHkgdGhl biBvbmx5IHVudHJ1c3RlZCBtYWtlcw0KPnNlbnNlLikNCj4qKiBBbiBleGFtcGxlIHNjZW5hcmlv IGZvciBlYWNoIG9mIHRoZSBkaWZmZXJlbnQgdHJ1c3QgbGV2ZWxzIGZvciB0aGUNCj5wcm94eS4N Cj5UaGlzIGlzIHdoZXJlIHRoZXJlIGlzIHRoZSBncmVhdGVzdCBwcm9ibGVtIGluIHRyeWluZyB0 byBjb21lIHVwIHdpdGggcmVhbA0KPndvcmxkIHJhdGhlciB0aGFuIGFjYWRlbWljIGV4YW1wbGVz IG1pZ2h0IGJlIHRoZSBoYXJkZXN0IHRoaW5nIHRvIGRvLg0KPioqIExvb2sgYXQgdGhlIHRocmVh dHMgYW5kIHJlcXVpcmVtZW50cyBmb3IgZWFjaCB0cnVzdCBsZXZlbCBidWlsZGluZyBvbiBhDQo+ YmFzZS4gIEkuZS4gc3RhcnQgdGhlIGxpc3Qgd2l0aCBhIHNpbmdsZSByZXF1aXJlbWVudCBvZiAi SW5jb3Jwb3JhdGUgdGhlDQo+Zm9sbG93aW5nIHJlcXVpcmVtZW50cyBieSByZWZlcmVuY2UgQTEs IEEyLCBBMywgQTQiLg0KPg0KPlN0YXJ0IHRoZSBkb2N1bWVudCB3aXRoIHNvbWUgdHlwZSBvZiBn ZW5lcmljIHByb3h5LiAgSSB3b3VsZCBzdWdnZXN0IGEgTkFUDQo+cHJveHkgYXMgdGhpcyBpcyBz b21ldGhpbmcgdGhhdCBpcyBzaW1wbGUgYW5kIGVhc3kgdG8gdGFsayBhYm91dCBhcyBpdA0KPmRv ZXMNCj5ub3QgZG8gYW55IGNoYW5nZXMgdG8gdGhlIENvQVAgbWVzc2FnZSBhbmQgdGh1cyBpcyB0 cml2aWFsIHRvIHVuZGVyc3RhbmQuDQo+DQo+SW5jbHVkZSBhIGRlc2NyaXB0aW9uIG9mIHRoZSBh Ym92ZSBzZWN1cml0eSBsZXZlbHMgYW5kIHdoYXQgdGhleSBpbXBseSBpbg0KPnRlcm1zIG9mIGtl eSBzaGFyaW5nIGFuZCB0cnVzdCBzaGFyaW5nLg0KPg0KPkluY2x1ZGUgYSBkZXNjcmlwdGlvbiBv ZiBob3cgb25lIHNob3VsZCB0aGluayBhYm91dCBjb21wb3NpbmcgcHJveGllcw0KPnRvZ2V0aGVy IGludG8gYSBzaW5nbGUgdW5pdC4gIERlcGVuZGluZyBvbiBob3cgb25lIGRvZXMgdGhlIGFuYWx5 c2lzLCBJDQo+dGhpbmsgdGhhdCB0aGlzIGNhbiBiZSB0cmVhdGVkIGFzIGRlYWxpbmcgd2l0aCB0 aGUgY2FwYWJpbGl0aWVzIG9mIGVhY2gNCj5wcm94eSBzZXBhcmF0ZWx5IGlmIHRoZXkgYXJlIGNv bWJpbmVkIGludG8gYSBzaW5nbGUgdW5pdCBhbmQgY2FuIGVhc2lseSBiZQ0KPnRyZWF0ZWQgYXMg c2VwYXJhdGUgdGhpbmdzIHdoZW4gdGhleSBhcmUgbm90IHRyZWF0ZWQgYXMgYSBzaW5nbGUgdW5p dC4NCj5QYXJ0DQo+b2YgdGhlIHF1ZXN0aW9uIGlzIHdoYXQgb25lIHdhbnRzIHRvIHNheSBhYm91 dCBwcm94aWVzIHRoYXQgY29sbHVkZQ0KPnRvZ2V0aGVyDQo+YXMgb3Bwb3NlIHRvIGJlIHRoZSBz YW1lIHByb3h5Lg0KPg0KPihkYXkgIzIpDQo+DQo+SSBjYW4gdW5kZXJzdGFuZCB0aGVyZSBtaWdo dCBiZSBhIGRlc2lyZSB0byB0YWxrIGFib3V0IGNvbnZlcnNhdGlvbnMNCj5iZXR3ZWVuDQo+ZW50 aXRpZXMuICBIb3dldmVyLCB0aGVzZSBzaG91bGQgZm9jdXMgb24gdGhlIGNvbnZlcnNhdGlvbiBh bmQgaWdub3JlIHRoZQ0KPm1pZGRsZSBlbnRpdGllcy4gIFRoYXQgaXMgdGhlcmUgYXJlIGdvaW5n IHRvIGJlIGdlbmVyaWMgaXNzdWVzIHRoYXQgZGVhbA0KPndpdGggdGhlIGZvbGxvd2luZyBzaXR1 YXRpb25zOg0KPg0KPjEpIFNlbmQgbWVzc2FnZSBmcm9tIEEgdG8gQi4NCj4yKSBNdWx0aWNhc3Qg bWVzc2FnZSBmcm9tIEEgdG8gR3JvdXAgQg0KPjMpIFJvdW5kIHRyaXAgZnJvbSBBIHRvIEIuDQo+ NCkgTXVsdGljYXN0IG1lc3NhZ2UgZnJvbSBBIHRvIEdyb3VwIEIgdy8gc2luZ2xlIGNhc3QgcmVw bHkNCj41KSBNdWx0aWNhc3QgbWVzc2FnZSBmcm9tIEEgdG8gR3JvdXAgQiB3LyBtdWx0aS1jYXN0 IHJlcGx5IHRvIGdyb3VwIEINCj4oYXNzdW1pbmcgdGhhdCBBIGlzIGluIEdyb3VwIEIpDQo+DQo+ SmltDQo+DQo+DQoNCg== From nobody Mon May 23 04:07:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC14712D670 for ; Mon, 23 May 2016 04:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10Kqy9JZbUd4 for ; Mon, 23 May 2016 04:07:20 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAE112D66C for ; Mon, 23 May 2016 04:07:17 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 636DC1CC02AA; Mon, 23 May 2016 13:07:16 +0200 (CEST) From: Ladislav Lhotka To: Carsten Bormann In-Reply-To: <57401CC2.2040002@tzi.org> References: <57401CC2.2040002@tzi.org> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 23 May 2016 13:07:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:07:27 -0000 Carsten Bormann writes: > Ladislav Lhotka wrote: >> The receiving side will resolve the union type by the first union member >> type that matches the CBOR-encoded value. It's the same as in JSON encod= ing. > > Or, at least, similar -- we are not always making the same serialization > decisions. I meant that the rule in section 9.12 of rfc6020bis still applies: a value representing a union data type is validated consecutively against each member type, in the order they are specified in the "type" statement, until a match is found. However, deciding about validity of a value involves not only YANG type (or data model info in general) but also rules of the given serialization format. I don't think it's a big practical problem though. The sending side should know the "real" type of a value being and the serialization format, so it should be able to do the right thing.=20 > > The weird aspect of this part of YANG is that the actual validity (and > specific semantics and thus usefulness) of a union in the YANG module > depends on the specifics of the serialization below. This is not specific to unions: e.g., if a YANG leaf "foo" has a numeric type, then a JSON value "foo": "42" will be rejected, and so will be a CBOR value with major type 3. > More frankly: Tying the semantics of a modeling language to one specific > serialization mechanism is an utterly broken design. > I'm not sure that it can be fixed, though, so we'll likely have to work > around this breakage. > > What we were trying to figure out was the extent of the situations where > a YANG module specifier might rely on the XML-specific way of resolving > unions. > > Examples that seem painful: > > 1) > > type union { > type enumeration { > enum one; /* value 0 */ > enum two; /* value 1 */ > } > type uint32; > } > > Here, the XML will have the string "one" or "two", or a decimal string, > which is unambiguous. The JSON encoding also has the string for > enumerations, which we obviously want to replace by the numeric value in > a compact encoding. Right, so the problem is not only due to "everything is string in XML". > > We were thinking about possibly adding CBOR tags to disambiguate this. This might be a good idea anyway because resolving a union type may involve, e.g., (repeated) regular expression matching. Lada > This becomes more insidious if this is an evolution from an earlier > version that just said: > > type enumeration { > ... > } > > (We wouldn't want to sprinkle in tags just in case a type might possibly > evolve into a union later.) > > 2) > > Also, just having a tag saying "this is an enumeration value" does not > work for this case: > > type union { > type enumeration { > enum one; /* value 0 */ > enum two; /* value 1 */ > } > type enumeration { > enum alpha; /* value 0 */ > enum beta; /* value 1 */ > } > } > > We haven't found a way yet to tag this case that is robust against > further evolution of the YANG module. > > Clearly, YANG module specifiers will not rely on this when they are > cognizant of concise encodings. However, relying on specification > writers not doing this would mean that YANG modules have to be vetted > for mistakes of this kind before they can be used in a CBOR environment > after an exclusively XML/JSON life. (Maybe that actually *is* the > answer -- if we could get pyang to detect this case and issue a warning, > that might be enough.) > > Gr=C3=BC=C3=9Fe, Carsten > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon May 23 04:14:17 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479D312D67B for ; Mon, 23 May 2016 04:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nom1jthLGBVO for ; Mon, 23 May 2016 04:14:14 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B00012D678 for ; Mon, 23 May 2016 04:14:14 -0700 (PDT) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id CEB49FB8C9; Mon, 23 May 2016 13:14:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id YHwNDao1afJX; Mon, 23 May 2016 13:14:11 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id AC76BFB8CC; Mon, 23 May 2016 13:14:10 +0200 (CEST) Message-ID: <5742E600.1010503@tzi.org> Date: Mon, 23 May 2016 13:14:08 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ladislav Lhotka References: <57401CC2.2040002@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:14:16 -0000 Ladislav Lhotka wrote: >> We were thinking about possibly adding CBOR tags to disambiguate this. > > This might be a good idea anyway because resolving a union type may > involve, e.g., (repeated) regular expression matching. Right, minimizing the complexity of the matcher is a good objective. Now, how do we use tags to identify the alternatives in the union? As far as I understand, these can be moved around when the module is updated. How do people handle this in their software? Grüße, Carsten From nobody Mon May 23 04:23:00 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E612D69A for ; Mon, 23 May 2016 04:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI6RqhhKy_UG for ; Mon, 23 May 2016 04:22:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 24B1D12D681 for ; Mon, 23 May 2016 04:22:58 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E8A4F1CC02AA; Mon, 23 May 2016 13:22:58 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Carsten Bormann In-Reply-To: <20160521112857.GA4437@elstar.local> References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 23 May 2016 13:22:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:22:59 -0000 Juergen Schoenwaelder writes: > On Sat, May 21, 2016 at 10:30:58AM +0200, Carsten Bormann wrote: >> Ladislav Lhotka wrote: >> > The receiving side will resolve the union type by the first union member >> > type that matches the CBOR-encoded value. It's the same as in JSON encoding. >> >> Or, at least, similar -- we are not always making the same serialization >> decisions. >> >> The weird aspect of this part of YANG is that the actual validity (and >> specific semantics and thus usefulness) of a union in the YANG module >> depends on the specifics of the serialization below. > > YANG's native serialization of values are untyped strings. To my knowledge, this hasn't been stated as a design feature for YANG, it's just a side effect of XML being the only serialization that was considered when YANG was being designed. > >> More frankly: Tying the semantics of a modeling language to one specific >> serialization mechanism is an utterly broken design. > > Not necessarily. It may start to look broken once you have > serializations that are typed and for some reasons people think the > type information should impact how YANG works (that assumes values > serialized as untyped strings). Note that type rules differ for > different serializations so you actually have no chance to get away > without any weird corner cases. > >> I'm not sure that it can be fixed, though, so we'll likely have to work >> around this breakage. > > I disagree that YANG is broken. +1, although I think it would be useful to have a general mechanism for signaling the actual type of a value - one option is to use a metadata annotation. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon May 23 04:27:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3556E12D6A6 for ; Mon, 23 May 2016 04:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0okCOhkVyYK for ; Mon, 23 May 2016 04:27:18 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF6A12D687 for ; Mon, 23 May 2016 04:27:18 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 08CC31CC02AA; Mon, 23 May 2016 13:27:19 +0200 (CEST) From: Ladislav Lhotka To: Carsten Bormann In-Reply-To: <57401E02.6000409@tzi.org> References: <57401E02.6000409@tzi.org> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 23 May 2016 13:27:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:27:20 -0000 Carsten Bormann writes: > Ladislav Lhotka wrote: >> The receiving side will resolve the union type by the first union member >> type that matches the CBOR-encoded value. It's the same as in JSON encod= ing. > > Oh, and I also have a problem with requiring YANG-CBOR decoders to do > this kind of "matching", which is: > > -- complex (you need a full constraint evaluator) > -- not necessarily well-defined (prove that it is!) > -- not necessarily even possible at the time of decoding (!) Right, tagging the values is a better option. > > The example in Section 9.12.4 of draft-ietf-netmod-rfc6020bis-12.txt of > a union data item retroactively (i.e., after decoding!?) turning into a > string when the leaf that it was originally referencing was deleted is > hilarious. Agreed. Lada > > Gr=C3=BC=C3=9Fe, Carsten --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon May 23 05:06:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C234112D703 for ; Mon, 23 May 2016 05:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhsd4sORO3KQ for ; Mon, 23 May 2016 05:06:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1805A12D76F for ; Mon, 23 May 2016 05:06:27 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba] (unknown [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba]) by mail.nic.cz (Postfix) with ESMTPSA id 0A7876099D; Mon, 23 May 2016 14:06:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464005185; bh=tEkl6l7OXRJRBbvh7X6pdduIQ02J5B6PXDz7NI/qDEE=; h=From:Date:To; b=JOcI6gL1T/EIXqjEevlhw5TNOJ8kIqS9+kFXSLOoUyd97LuSOv2/7DK+vjjMxT4ui ihDqqDTQxvGeokf90S9TXLUb6cg8eRao7gzi/mXbL1F2/ke1CtCkqcZlIqTTnMXkD7 kSkoi5j2iQOW9PGi7q3f1V9lQx/L0LapF0BdvkHk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <5742E600.1010503@tzi.org> Date: Mon, 23 May 2016 14:06:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57401CC2.2040002@tzi.org> <5742E600.1010503@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 12:06:34 -0000 > On 23 May 2016, at 13:14, Carsten Bormann wrote: >=20 > Ladislav Lhotka wrote: >>> We were thinking about possibly adding CBOR tags to disambiguate = this. >>=20 >> This might be a good idea anyway because resolving a union type may >> involve, e.g., (repeated) regular expression matching. >=20 > Right, minimizing the complexity of the matcher is a good objective. >=20 > Now, how do we use tags to identify the alternatives in the union? > As far as I understand, these can be moved around when the module is > updated. > How do people handle this in their software? I think they mostly follow the procedure as specified in 6020. Unions = are usually not defined to make this really hard. For unions like = "inet:host" or "inet:ip-address" it often needn't be done at all because = many library functions directly accept all member types. Lada >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon May 23 06:59:37 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B17D812D8FC for ; Mon, 23 May 2016 06:59:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523135935.10723.43671.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 06:59:35 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 13:59:36 -0000 Deleted milestone "HOLD (date TBD) Constrained security bootstrapping specification submitted to IESG". URL: https://datatracker.ietf.org/wg/core/charter/ From nobody Mon May 23 21:25:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637F012D12D for ; Mon, 23 May 2016 21:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE8GXOIbTO9A for ; Mon, 23 May 2016 21:25:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5894512D0A0 for ; Mon, 23 May 2016 21:25:50 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 1F375EB21BB29; Tue, 24 May 2016 04:25:47 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4O4Plau009822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2016 04:25:48 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4O4OdRv010412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 May 2016 06:25:47 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 24 May 2016 06:24:54 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "Rahman, Akbar" , "cabo@tzi.org" , "jaime.jimenez@ericsson.com" Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-10.txt Thread-Index: AQHRrR0XDnun1d32uU6p23FN0Xk555+2wU0AgAfc8QCACN8xgA== Date: Tue, 24 May 2016 04:24:53 +0000 Message-ID: References: <20160513134033.10520.69223.idtracker@ietfa.amsl.com> <36F5869FE31AB24485E5E3222C288E1F5BAB947B@NABESITE.InterDigital.com> <36F5869FE31AB24485E5E3222C288E1F5BABBC1B@NABESITE.InterDigital.com> In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BABBC1B@NABESITE.InterDigital.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <65C633E421808446A2E5C479B9B62BDB@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 04:25:52 -0000 Hi Carsten & Jaime, A gentle prod to our chairs for restarting WGLC on the HTTP-CoAP mapping I-D ;-) Thanks, cheers, t On 18/05/2016 14:55, "core on behalf of Rahman, Akbar" wrote: >Hi Carsten/Jamie, > > >Just resending this email as I believe the first time it did not get >correctly to Carsten due to some problem with my mail server. I've been >told by me IST department that the problem has now been fixed so I am >resending this request to re-start the WGLC. > > >Thanks, > > >Akbar > >-----Original Message----- >From: core [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar >Sent: Friday, May 13, 2016 9:51 AM >To: cabo@tzi.org; jaime.jimenez@ericsson.com >Cc: core@ietf.org >Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt > >Hi Carsten/Jaime, > > >We have updated the draft to cover the following: > > > Changes from ietf-09 to ietf-10: > > o Addressed Ticket #401 - Clarified that draft covers not only > Reverse HC Proxy but that many parts also apply to Forward and > Interception Proxies. > > o Clarified that draft concentrates on the HTTP-to-CoAP mapping > direction (i.e. the HC proxy is a HTTP server and a CoAP client). > > o Clarified the "null mapping" case where no CoAP URI information is > embedded in the HTTP request URI. > > o Moved multicast related security text to the "Security > Considerations" to consolidate all security information in one > location. > > o Removed references to "placement" of proxy (e.g. server-side vs > client-side) as is confusing and provides little added value. > > o Fixed version numbers on references that were corrupted in last > revision due to outdated xml2rfc conversion tool local cache. > > o Various editorial improvements. > > >Can you please review, and start the 2nd WGLC if you think that >everything looks in order. > > >Best Regards, > > >Akbar > >-----Original Message----- >From: core [mailto:core-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Friday, May 13, 2016 9:41 AM >To: i-d-announce@ietf.org >Cc: core@ietf.org >Subject: [core] I-D Action: draft-ietf-core-http-mapping-10.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Constrained RESTful Environments of the >IETF. > > Title : Guidelines for HTTP-to-CoAP Mapping >Implementations > Authors : Angelo P. Castellani > Salvatore Loreto > Akbar Rahman > Thomas Fossati > Esko Dijk > Filename : draft-ietf-core-http-mapping-10.txt > Pages : 36 > Date : 2016-05-13 > >Abstract: > This document provides reference information for implementing a > cross-protocol network proxy that performs translation from the HTTP > protocol to the CoAP protocol. This will enable a HTTP client to > access resources on a CoAP server through the proxy. This document > describes how a HTTP request is mapped to a CoAP request, and then > how a CoAP response is mapped back to a HTTP response. This includes > guidelines for URI mapping, media type mapping and additional proxy > implementation issues. This document covers the Reverse, Forward and > Interception cross-protocol proxy cases. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-core-http-mapping-10 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-10 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core > >_______________________________________________ >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 nobody Mon May 23 23:05:50 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B5512D632 for ; Mon, 23 May 2016 23:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsVHBKGrekBd for ; Mon, 23 May 2016 23:05:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6E212D642 for ; Mon, 23 May 2016 23:05:47 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-7f-5743ef395969 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.EC.18043.93FE3475; Tue, 24 May 2016 08:05:45 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.28]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0294.000; Tue, 24 May 2016 08:05:00 +0200 From: =?iso-8859-1?Q?Jaime_Jim=E9nez?= To: "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-10.txt Thread-Index: AQHRrR0fQVa/GkdC30auXjtGthbfFp+2wU0AgAfc8QCACM5wgIAAG/cA Date: Tue, 24 May 2016 06:05:00 +0000 Message-ID: <845BC0CD-48D2-4080-976D-967E6E9763D2@ericsson.com> References: <20160513134033.10520.69223.idtracker@ietfa.amsl.com> <36F5869FE31AB24485E5E3222C288E1F5BAB947B@NABESITE.InterDigital.com> <36F5869FE31AB24485E5E3222C288E1F5BABBC1B@NABESITE.InterDigital.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0F17D9EFE41CBF46B8C2518A691B98C7@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7hK7le+dwg8mXJSx+TWhisjgy5S6r xb6365ktWj5/YnNg8Viy5CeTx9Lrbawed29dYvKYtigzgCWKyyYlNSezLLVI3y6BK+Ng10f2 gksaFX/OvmNsYFyk0MXIySEhYCKx8HY7K4QtJnHh3nq2LkYuDiGBI4wSa07vhnIWM0rs2H6G DaSKTcBZ4tvnWUwgtoiArcSmhm1g3cwCpRKbmz6xgNjCQDWb+5ewQtS4SGx+/xbKdpOYMfst I4jNIqAqMfHvG7A5vAL2Eu/fz2eEWNbCJDFx0lJ2kAQnUOLrsxNgQxmBzvt+ag0TxDJxiVtP 5jNBnC0gsWTPeWYIW1Ti5eN/UO8oSTQueQJ1nJ7EjalT2CBsa4kdryezQNjaEssWvmaGOEJQ 4uTMJywTGMVnIVkxC0n7LCTts5C0z0LSvoCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZG YGQe3PLbagfjweeOhxgFOBiVeHgTap3DhVgTy4orcw8xSnAwK4nwLr8OFOJNSaysSi3Kjy8q zUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cDo+mKLrI7p5QzHD++0wt/82S7L 1G/bvG3i+o2f131dc6NmFt9l+2+M+f83PopYKbPq0O7TIYIeelwi02Yaai8NTSyXmn9x1bc8 Xc6KMkmlm/eevpq/iGcl95QdvzmKb/4+Xm2jV9I5L7fm8ufP+Ta31V77S16Vl3FTNbqz98xj s/BCa6mT9ZkFSizFGYmGWsxFxYkAqBTnMcgCAAA= Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 06:05:49 -0000 Hi, Sorry for the delay. Carsten and I already met and discussed the HTTP-CoAP = mapping draft. We just need a little bit of time this week to go through th= e changes. We will call the second WGLC shortly.=20 Ciao! - - Jaime Jimenez > On 24 May 2016, at 07:24, Fossati, Thomas (Nokia - GB) wrote: >=20 > Hi Carsten & Jaime, >=20 > A gentle prod to our chairs for restarting WGLC on the HTTP-CoAP mapping > I-D ;-) >=20 > Thanks, cheers, > t >=20 > On 18/05/2016 14:55, "core on behalf of Rahman, Akbar" > wrote: >> Hi Carsten/Jamie, >>=20 >>=20 >> Just resending this email as I believe the first time it did not get >> correctly to Carsten due to some problem with my mail server. I've been >> told by me IST department that the problem has now been fixed so I am >> resending this request to re-start the WGLC. >>=20 >>=20 >> Thanks, >>=20 >>=20 >> Akbar >>=20 >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar >> Sent: Friday, May 13, 2016 9:51 AM >> To: cabo@tzi.org; jaime.jimenez@ericsson.com >> Cc: core@ietf.org >> Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt >>=20 >> Hi Carsten/Jaime, >>=20 >>=20 >> We have updated the draft to cover the following: >>=20 >>=20 >> Changes from ietf-09 to ietf-10: >>=20 >> o Addressed Ticket #401 - Clarified that draft covers not only >> Reverse HC Proxy but that many parts also apply to Forward and >> Interception Proxies. >>=20 >> o Clarified that draft concentrates on the HTTP-to-CoAP mapping >> direction (i.e. the HC proxy is a HTTP server and a CoAP client). >>=20 >> o Clarified the "null mapping" case where no CoAP URI information is >> embedded in the HTTP request URI. >>=20 >> o Moved multicast related security text to the "Security >> Considerations" to consolidate all security information in one >> location. >>=20 >> o Removed references to "placement" of proxy (e.g. server-side vs >> client-side) as is confusing and provides little added value. >>=20 >> o Fixed version numbers on references that were corrupted in last >> revision due to outdated xml2rfc conversion tool local cache. >>=20 >> o Various editorial improvements. >>=20 >>=20 >> Can you please review, and start the 2nd WGLC if you think that >> everything looks in order. >>=20 >>=20 >> Best Regards, >>=20 >>=20 >> Akbar >>=20 >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, May 13, 2016 9:41 AM >> To: i-d-announce@ietf.org >> Cc: core@ietf.org >> Subject: [core] I-D Action: draft-ietf-core-http-mapping-10.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Constrained RESTful Environments of the >> IETF. >>=20 >> Title : Guidelines for HTTP-to-CoAP Mapping >> Implementations >> Authors : Angelo P. Castellani >> Salvatore Loreto >> Akbar Rahman >> Thomas Fossati >> Esko Dijk >> Filename : draft-ietf-core-http-mapping-10.txt >> Pages : 36 >> Date : 2016-05-13 >>=20 >> Abstract: >> This document provides reference information for implementing a >> cross-protocol network proxy that performs translation from the HTTP >> protocol to the CoAP protocol. This will enable a HTTP client to >> access resources on a CoAP server through the proxy. This document >> describes how a HTTP request is mapped to a CoAP request, and then >> how a CoAP response is mapped back to a HTTP response. This includes >> guidelines for URI mapping, media type mapping and additional proxy >> implementation issues. This document covers the Reverse, Forward and >> Interception cross-protocol proxy cases. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-core-http-mapping-10 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-10 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 >=20 From nobody Tue May 24 02:10:22 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEA112D5AD for ; Tue, 24 May 2016 02:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti79q2Br2dAZ for ; Tue, 24 May 2016 02:10:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C9D12D1EB for ; Tue, 24 May 2016 02:10:18 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 6FFDED7D6A381; Tue, 24 May 2016 09:10:14 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4O9AElW024514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2016 09:10:16 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4O9ABX1016411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 May 2016 11:10:13 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 24 May 2016 11:10:11 +0200 From: "Fossati, Thomas (Nokia - GB)" To: =?iso-8859-1?Q?Jaime_Jim=E9nez?= Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-10.txt Thread-Index: AQHRrR0XDnun1d32uU6p23FN0Xk555+2wU0AgAfc8QCACN8xgIAACzgAgABEfIA= Date: Tue, 24 May 2016 09:10:11 +0000 Message-ID: References: <20160513134033.10520.69223.idtracker@ietfa.amsl.com> <36F5869FE31AB24485E5E3222C288E1F5BAB947B@NABESITE.InterDigital.com> <36F5869FE31AB24485E5E3222C288E1F5BABBC1B@NABESITE.InterDigital.com> <845BC0CD-48D2-4080-976D-967E6E9763D2@ericsson.com> In-Reply-To: <845BC0CD-48D2-4080-976D-967E6E9763D2@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7EA80F6645B00C4BBCC15324A6CA0FBB@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 09:10:20 -0000 Hi Jaime, On 24/05/2016 07:05, "Jaime Jim=E9nez" wrote: >Sorry for the delay. Carsten and I already met and discussed the >HTTP-CoAP mapping draft. We just need a little bit of time this week to >go through the changes. We will call the second WGLC shortly. Thanks very much! Cheers, t From nobody Tue May 24 05:36:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13C12D117 for ; Tue, 24 May 2016 05:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l94agCjua2e5 for ; Tue, 24 May 2016 05:36:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154A512D68F for ; Tue, 24 May 2016 05:36:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D7CC7AC2; Tue, 24 May 2016 14:36:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vEv86hLWKttZ; Tue, 24 May 2016 14:36:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 May 2016 14:36:17 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 244802005C; Tue, 24 May 2016 14:36:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LVSSi1zSkoL6; Tue, 24 May 2016 14:36:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FB1020051; Tue, 24 May 2016 14:36:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9A81E3AF0715; Tue, 24 May 2016 14:36:14 +0200 (CEST) Date: Tue, 24 May 2016 14:36:13 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160524123613.GB9897@elstar.local> Mail-Followup-To: Ladislav Lhotka , Carsten Bormann , Core References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder 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 2016 12:36:26 -0000 On Mon, May 23, 2016 at 01:22:59PM +0200, Ladislav Lhotka wrote: > > YANG's native serialization of values are untyped strings. > > To my knowledge, this hasn't been stated as a design feature for YANG, > it's just a side effect of XML being the only serialization that was > considered when YANG was being designed. We use string representations of values in other contexts, e.g., when writing pattern restrictions or when evaluating xpath expressions. We also do define canonical string formats for our types. Note, this does not mean an implementation has store internally all values as strings but when it matters, the string representation of values defines the behavior. Except for unions in JSON... My take has been that non-XML encodings may take advantage of being able to present data mode 'efficiently' (CBOR) or to make it easier for applications / libraries (JSON). For me, encodings that change how we interpret types at the YANG level are somewhat surprising. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 24 05:40:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F7212D69E for ; Tue, 24 May 2016 05:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTyKgdVEWCEz for ; Tue, 24 May 2016 05:40:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA4D12D593 for ; Tue, 24 May 2016 05:40:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C0BF6A85; Tue, 24 May 2016 14:40:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7E74qjiNrWL9; Tue, 24 May 2016 14:40:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 May 2016 14:40:41 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBB9B2005C; Tue, 24 May 2016 14:40:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YZ2N6Thf6udT; Tue, 24 May 2016 14:40:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88A0020051; Tue, 24 May 2016 14:40:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7CB813AF079E; Tue, 24 May 2016 14:40:39 +0200 (CEST) Date: Tue, 24 May 2016 14:40:39 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160524124039.GC9897@elstar.local> Mail-Followup-To: Andy Bierman , Carsten Bormann , Core References: <57401CC2.2040002@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder 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 2016 12:40:45 -0000 On Sat, May 21, 2016 at 08:29:33AM -0700, Andy Bierman wrote: > > This is a legal union type even though in XML type 'int32' would never be > used > because 'string' would match everything. > > leaf foo { > type union { > type string; > type int32; > } > } > > This is a problem for config nodes: > JSON/CBOR client sets { "foo" : 42 } > XML client reads back 42 > > JSON (and CBOR) will send { "foo":42 }, not { "foo":"42" } if they intend to > send the number, but XML cannot do the same. There is no problem > unless XML is being used in addition to JSON or CBOR. > > Some solution choices: > > 1 - do nothing and let XML and JSON/CBOR be broken together > (solution is do not use XML and JSON/CBOR together in the same server) > 2 - force receiver to convert JSON/CBOR to a string for union type > matching > 3 - tag the data somehow so the receiver knows which union member type is > being sent > 4 - write YANG guidelines on how to design union types that will produce > the same > match with all encoding schemes I think 2 is the right short-term approach. It does not mean an implementation has always to convert to a string but an implementation needs to behave as if it has converted to a string. > IMO CBOR has to solve the enumeration and bits issues with (3) but > for the problem in general, just do (4) Option 3 may be a long-term solution but this is non-trivial to work out and to introduce with a backwards compability perspective in mind. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 24 07:25:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A2D12D0B2 for ; Tue, 24 May 2016 07:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjQ1emFfAg2x for ; Tue, 24 May 2016 07:25:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA56512D805 for ; Tue, 24 May 2016 07:25:09 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869] (unknown [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869]) by mail.nic.cz (Postfix) with ESMTPSA id 782206169A; Tue, 24 May 2016 16:25:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464099908; bh=h8kPVm1b+aFw3qGw36Edr/rFcgh3+NSXj0tjz8sRw2Q=; h=From:Date:To; b=Pvlbw2Hji72BD0RkuW8+BUIoJBxKMlI7XIVAiwtDBrXDngWPqFM7bDTQRJssj4Vfa hCMtKd5gTikKnUsTX3nWvJwz8msXk4l4hKs2lx8z1o9+9X0TxeJjZMZWi3bP0G+Y89 te84bmwDoSoe4NcCCF20CBaSRBu025ELIsaUsxQI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160524123613.GB9897@elstar.local> Date: Tue, 24 May 2016 16:25:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> <20160524123613.GB9897@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 14:25:13 -0000 > On 24 May 2016, at 14:36, Juergen Schoenwaelder = wrote: >=20 > On Mon, May 23, 2016 at 01:22:59PM +0200, Ladislav Lhotka wrote: >=20 >>> YANG's native serialization of values are untyped strings. >>=20 >> To my knowledge, this hasn't been stated as a design feature for = YANG, >> it's just a side effect of XML being the only serialization that was >> considered when YANG was being designed. >=20 > We use string representations of values in other contexts, e.g., when > writing pattern restrictions or when evaluating xpath expressions. We Actually, pattern restrictions are only possible for the "string" type. And XPath is not limited to strings, we can write, e.g., must ". mod 2 =3D 0"; > also do define canonical string formats for our types. >=20 > Note, this does not mean an implementation has store internally all > values as strings but when it matters, the string representation of > values defines the behavior. Except for unions in JSON... >=20 > My take has been that non-XML encodings may take advantage of being > able to present data mode 'efficiently' (CBOR) or to make it easier > for applications / libraries (JSON). For me, encodings that change how > we interpret types at the YANG level are somewhat surprising. The problem is that XML, JSON and CBOR are not just different encodings = (as in Unicode) but rather different ways for representing structured = data, and each has different priorities and semantics. I don't think = that "gleichgeschaltetes" JSON or CBOR, where everything is a string, is = an attractive option. Lada=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue May 24 07:29:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4A112D838 for ; Tue, 24 May 2016 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRaizUuTQ4zH for ; Tue, 24 May 2016 07:29:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B946812D82B for ; Tue, 24 May 2016 07:29:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4059489D; Tue, 24 May 2016 16:29:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tPmrTy-FqLtE; Tue, 24 May 2016 16:29:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 May 2016 16:29:26 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62AF42005C; Tue, 24 May 2016 16:29:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r9QugDIwB8pg; Tue, 24 May 2016 16:29:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCAFF20058; Tue, 24 May 2016 16:29:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 98B703AF0B92; Tue, 24 May 2016 16:29:24 +0200 (CEST) Date: Tue, 24 May 2016 16:29:24 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160524142924.GB10130@elstar.local> Mail-Followup-To: Ladislav Lhotka , Carsten Bormann , Core References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> <20160524123613.GB9897@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder 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 2016 14:29:31 -0000 On Tue, May 24, 2016 at 04:25:13PM +0200, Ladislav Lhotka wrote: > > > On 24 May 2016, at 14:36, Juergen Schoenwaelder wrote: > > > > On Mon, May 23, 2016 at 01:22:59PM +0200, Ladislav Lhotka wrote: > > > >>> YANG's native serialization of values are untyped strings. > >> > >> To my knowledge, this hasn't been stated as a design feature for YANG, > >> it's just a side effect of XML being the only serialization that was > >> considered when YANG was being designed. > > > > We use string representations of values in other contexts, e.g., when > > writing pattern restrictions or when evaluating xpath expressions. We > > Actually, pattern restrictions are only possible for the "string" type. > > And XPath is not limited to strings, we can write, e.g., > > must ". mod 2 = 0"; But the expression is at least conceptually evaluated on a string representation of what is being interpreted as a number. > > also do define canonical string formats for our types. > > > > Note, this does not mean an implementation has store internally all > > values as strings but when it matters, the string representation of > > values defines the behavior. Except for unions in JSON... > > > > My take has been that non-XML encodings may take advantage of being > > able to present data mode 'efficiently' (CBOR) or to make it easier > > for applications / libraries (JSON). For me, encodings that change how > > we interpret types at the YANG level are somewhat surprising. > > The problem is that XML, JSON and CBOR are not just different encodings (as in Unicode) but rather different ways for representing structured data, and each has different priorities and semantics. I don't think that "gleichgeschaltetes" JSON or CBOR, where everything is a string, is an attractive option. And I did not suggest that. All I said is that encodings should not change how the YANG type system works. I continue to find that broken. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 24 08:08:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703B612D858 for ; Tue, 24 May 2016 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjcVM-4U7hxb for ; Tue, 24 May 2016 08:08:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBB112D853 for ; Tue, 24 May 2016 08:08:54 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869] (unknown [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869]) by mail.nic.cz (Postfix) with ESMTPSA id 8DA5F617DD; Tue, 24 May 2016 17:08:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464102533; bh=jg1NY7rZQ4qQVbbrC3lHnwUXIN0BNYHfUWmwqS0Xsy0=; h=From:Date:To; b=pAdgzlIpwwe6EiEIrhVbk8REcM8Ok8e4xeeIInJTlgdXsMDeIyvJj3l564LzSdtTc 1Bm5ou00jqsGJ7v1gxCcm+kwEktuocQpK9nHStZ6DdR9YZpshdQdq1+kmqCvu/3U5U TmIl6TUosVXsijV+eWHAnHVgYNVZkWdybKkbXdus= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160524142924.GB10130@elstar.local> Date: Tue, 24 May 2016 17:08:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> <20160524123613.GB9897@elstar.local> <20160524142924.GB10130@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 15:08:57 -0000 > On 24 May 2016, at 16:29, Juergen Schoenwaelder = wrote: >=20 > On Tue, May 24, 2016 at 04:25:13PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 24 May 2016, at 14:36, Juergen Schoenwaelder = wrote: >>>=20 >>> On Mon, May 23, 2016 at 01:22:59PM +0200, Ladislav Lhotka wrote: >>>=20 >>>>> YANG's native serialization of values are untyped strings. >>>>=20 >>>> To my knowledge, this hasn't been stated as a design feature for = YANG, >>>> it's just a side effect of XML being the only serialization that = was >>>> considered when YANG was being designed. >>>=20 >>> We use string representations of values in other contexts, e.g., = when >>> writing pattern restrictions or when evaluating xpath expressions. = We >>=20 >> Actually, pattern restrictions are only possible for the "string" = type. >>=20 >> And XPath is not limited to strings, we can write, e.g., >>=20 >> must ". mod 2 =3D 0"; >=20 > But the expression is at least conceptually evaluated on a string > representation of what is being interpreted as a number. Hmm, I would say it's just the other way around: for example, XPath = expression "foo =3D 0" evaluates to true even if "foo" happens to have = YANG "string" type and value of "00". >=20 >>> also do define canonical string formats for our types. >>>=20 >>> Note, this does not mean an implementation has store internally all >>> values as strings but when it matters, the string representation of >>> values defines the behavior. Except for unions in JSON... >>>=20 >>> My take has been that non-XML encodings may take advantage of being >>> able to present data mode 'efficiently' (CBOR) or to make it easier >>> for applications / libraries (JSON). For me, encodings that change = how >>> we interpret types at the YANG level are somewhat surprising. >>=20 >> The problem is that XML, JSON and CBOR are not just different = encodings (as in Unicode) but rather different ways for representing = structured data, and each has different priorities and semantics. I = don't think that "gleichgeschaltetes" JSON or CBOR, where everything is = a string, is an attractive option. >=20 > And I did not suggest that. All I said is that encodings should not > change how the YANG type system works. I continue to find that broken. I don't think CBOR or JSON really change how YANG type system works. = They just provide some extra information that (unfortunately) isn't = available in XML serialization. Rather than blaming non-XML = serializations, we should think about a generic way for signalling the = actual member type that can be used whenever the chosen serialization = falls short. If we have, e.g. leaf foo { type union { type string; type uint8; } } then it should IMO be possible to pass a number, no matter what the = encoding is. So nothing extra needs to be done in JSON and CBOR, but in = XML encoding the data could be sent as 42 Lada =20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue May 24 08:55:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4612B02A for ; Tue, 24 May 2016 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTf2X07rAhzK for ; Tue, 24 May 2016 08:55:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2965612D0DB for ; Tue, 24 May 2016 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u4OFtddm016892; Tue, 24 May 2016 17:55:39 +0200 (CEST) Received: from nar-3.local.mail (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3rDg3v4s3GzDN4n; Tue, 24 May 2016 17:55:39 +0200 (CEST) Date: Tue, 24 May 2016 17:55:33 +0200 From: Carsten Bormann To: Ladislav Lhotka , =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= Message-ID: In-Reply-To: References: <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local> <20160524123613.GB9897@elstar.local> <20160524142924.GB10130@elstar.local> X-Mailer: Airmail (367) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5744797a_2553deeb_169de" Archived-At: Cc: Core Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 15:55:45 -0000 --5744797a_2553deeb_169de Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 24 May 2016 at 17:09:01, Ladislav Lhotka (lhotka=40nic.cz) wrote: 42=C2=A0 That brings up a question: Are there any rules about the evolution of unions=3F Can a YANG implementation rely on the relative position of union members = staying the same over the evolution of modules=3F Can a YANG implementation rely on a specific position in a union for what= used to be the only permissible type in a previous version of a module=3F= Gr=C3=BC=C3=9Fe, Carsten --5744797a_2553deeb_169de Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi,

 

I am trying = to do an experiment with one client communicating with multiple CoAP = servers for some real scenarios.

Does = anyone have experience or can figure out how can a client can make = multiple websocket connections to multiple CoAP servers at the same = time?

 

 

Hope to have = your support!

 

Many thanks,

William

 

Smart = Furniture IoT Research

 

------=_NextPart_000_001F_01D1BB89.740D08E0-- From nobody Tue May 31 15:07:33 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0312B078 for ; Tue, 31 May 2016 15:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYPo3Kd66bAv for ; Tue, 31 May 2016 15:07:29 -0700 (PDT) Received: from mail-gw-out2.cc.tut.fi (mail-gw-out2.cc.tut.fi [130.230.160.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F5312B01B for ; Tue, 31 May 2016 15:07:27 -0700 (PDT) X-AuditID: 82e6a021-8b3ff70000000921-09-574e0b17e2f9 Received: from mail2.tut.fi (mail2.tut.fi [130.230.162.20]) by (Symantec Messaging Gateway) with SMTP id B5.ED.02337.71B0E475; Wed, 1 Jun 2016 01:07:22 +0300 (EEST) Received: from Bilhanans-MBP.mshome.net (85-76-103-185-nat.elisa-mobile.fi [85.76.103.185]) by mail2.tut.fi (Postfix) with ESMTPSA id 6C815210A4; Wed, 1 Jun 2016 01:07:19 +0300 (EEST) To: William , core@ietf.org References: <001e01d1bb3e$04249d90$0c6dd8b0$@gmail.com> From: Bill Silverajan Message-ID: Date: Wed, 1 Jun 2016 01:07:17 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <001e01d1bb3e$04249d90$0c6dd8b0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsXS9GyRiK4Ut1+4wdbFlhb73q5ntvg6+RiL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXRfWkqU8FZzoqPr36wNjBeZO9i5OSQEDCR uPN1B1sXIxeHkMAKRol17yewQjh7GCV+Lv8HVMXBISxgKnFwazxIgwiQOeXFFTYQW0jAXGLe hIPMIDabgJHEgW+bWEBsXgFLiTOHr7OC2CwCKhIb2yaxgowRFUiTePEoEKJEUOLkzCcsIGFO AQuJ94f9QcLMArYSd+buZoaw5SW2v53DPIGRbxaSjllIymYhKVvAyLyKUSw3MTNHN71cN7+0 xEgvOVmvpLRELy1zEyM4yBYo7mA8NUP/EKMAB6MSD2/FZd9wIdbEsuLK3EOMkhxMSqK88Y+B QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4L7L6hQvxpiRWVqUW5cOkpDlYlMR5S/01Q4QE0hNL UrNTUwtSi2CyMhwcShK8xziBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGa3OBDC8uSMwtzkyHyJ9i VJQS530L0iwAksgozYPrBSWBUJ/0na8YxYFeEeY9BVLFA0wgcN2vgAYzAQ2Oz/ABGVySiJCS amDMM9tS+G9yW8OTvwJLeQ22JBh8uSST+PkVr7SJnIN1W/3bnyLau75N//U38U1mXhe//ddZ JT8Wlj5bMa2P4wzX5Ru80x9UJ3afF4u5GCLnz+Xbrxy4innC0noRk4/9XM33GKVPPD/jeKAn dY6ltTPH1Fr2/rnF0zPKX0ZPueGsXqVyo1kjR02JpTgj0VCLuag4EQBOcTUO3QIAAA== Archived-At: Subject: Re: [core] Asking about CoAP over WebSockets X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 22:07:31 -0000 Hi William, If you meant a CoAP+WS client making multiple, independent connections to several CoAP+WS servers simultaneously with a 1:1 relationship, I'm not particularly aware of any client-side limitations that would impede such an implementation from being realised. CoAP itself does not impose any such constraints, and the CoAP over WebSockets draft does not cover connection multiplexing in a single WebSocket session. Perhaps it might help if you could provide a more concrete example of how or where the actual challenge lies? Regards, Bill On 31/05/16 16:11, William wrote: > Hi, > > > > I am trying to do an experiment with one client communicating with > multiple CoAP servers for some real scenarios. > > Does anyone have experience or can figure out how can a client can make > multiple websocket connections to multiple CoAP servers at the same time? > > > > > > Hope to have your support! > > > > Many thanks, > > William > > > > Smart Furniture IoT Research > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue May 31 21:15:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D187512D162 for ; Tue, 31 May 2016 21:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwjGbeS6DVRA for ; Tue, 31 May 2016 21:15:47 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 078C112D128 for ; Tue, 31 May 2016 21:15:45 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id D866A19F3DD for ; Wed, 1 Jun 2016 12:15:43 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id F165219F3FE; Wed, 1 Jun 2016 12:15:42 +0800 (HKT) Message-ID: <0DF1BAAA2CD94BBB9F093788BC5307A5@WeiGengyuPC> From: "weigengyu" To: "William" , , "Bill Silverajan" References: <001e01d1bb3e$04249d90$0c6dd8b0$@gmail.com> In-Reply-To: Date: Wed, 1 Jun 2016 12:15:43 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] Asking about CoAP over WebSockets X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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 2016 04:15:50 -0000 Hi Bill and William, > If you meant a CoAP+WS client making multiple, independent connections to > several CoAP+WS servers simultaneously with a 1:1 relationship, I'm not > particularly aware of any client-side limitations that would impede such > an implementation from being realised. Right! >> I am trying to do an experiment with one client communicating with >> multiple CoAP servers for some real scenarios. Assume that it is not a group communications. So you actually have multiple logic CoAP clients to communicate with CoAP severs each by each. > CoAP itself does not impose any such constraints, and the CoAP over > WebSockets draft does not cover connection multiplexing in a single > WebSocket session. The draft needs little works. When a Websockect Client at ( the CoAP) Client side setup a session with Websocket server side at a proxy, One CoAP message can be sent in one Websocket frame along the same Websocket session. The proxy does not need special awareness. We are doing works of CoAP over Websocket by extending Californium. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Bill Silverajan Sent: Wednesday, June 01, 2016 6:07 AM To: William ; core@ietf.org Subject: Re: [core] Asking about CoAP over WebSockets Hi William, If you meant a CoAP+WS client making multiple, independent connections to several CoAP+WS servers simultaneously with a 1:1 relationship, I'm not particularly aware of any client-side limitations that would impede such an implementation from being realised. CoAP itself does not impose any such constraints, and the CoAP over WebSockets draft does not cover connection multiplexing in a single WebSocket session. Perhaps it might help if you could provide a more concrete example of how or where the actual challenge lies? Regards, Bill On 31/05/16 16:11, William wrote: > Hi, > > > > I am trying to do an experiment with one client communicating with > multiple CoAP servers for some real scenarios. > > Does anyone have experience or can figure out how can a client can make > multiple websocket connections to multiple CoAP servers at the same time? > > > > > > Hope to have your support! > > > > Many thanks, > > William > > > > Smart Furniture IoT > Research > > > > > > _______________________________________________ > 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