From nobody Thu Mar 1 09:32:33 2018 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 0095F12EBB2; Thu, 1 Mar 2018 09:32:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151992555197.21668.9651600215164766636@ietfa.amsl.com> Date: Thu, 01 Mar 2018 09:32:31 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:32:32 -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 WG of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-13.txt Pages : 70 Date : 2018-03-01 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-13 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-13 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 Thu Mar 1 09:58:18 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0546612EC00 for ; Thu, 1 Mar 2018 09:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 ZCD14l6-4lvQ for ; Thu, 1 Mar 2018 09:58:15 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75E712EC06 for ; Thu, 1 Mar 2018 09:58:14 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 703CF494EA for ; Thu, 1 Mar 2018 18:58:12 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7D7FB199 for ; Thu, 1 Mar 2018 18:58:11 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 474D85E for ; Thu, 1 Mar 2018 18:58:11 +0100 (CET) Received: (nullmailer pid 26262 invoked by uid 1000); Thu, 01 Mar 2018 17:58:10 -0000 Date: Thu, 1 Mar 2018 18:58:10 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20180301175810.GB25963@hephaistos.amsuess.com> References: <151992555197.21668.9651600215164766636@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline In-Reply-To: <151992555197.21668.9651600215164766636@ietfa.amsl.com> User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-resource-directory-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:58:17 -0000 --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Working Group, On Thu, Mar 01, 2018 at 09:32:31AM -0800, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. >=20 > [...] >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-resource-directory-13 > https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-= 13 Given that the document is closing its completion, the authors would like to ask the working group for reviews on it. Big changes since -12 are: * Added "all resource directory" nodes MC address * Clarified observation behavior * Reduced the significance of domains (removed from figure 2) * Explained how endpoints from other RDs can be members of a group * Resolve RFC6690-vs-8288 resolution ambiguities: * require registered links not to be relative when using anchor * return absolute URIs in resource lookup * Explain that multiple RDs can be found, and can have absolute addresses * Refer to t2trg-rel-impl for server metadata / versioning * Add explanatory text Best regards, Christian --=20 You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe) --8GpibOaaTibBMecb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqYPy4ACgkQOY0REtOk veFo1RAArIsfC6JKImX46LFmXcRzlyi1nfOB8xCTesMEEe9y7uBF5b+Mo0aU1q5z y6K+KHFLbFid7jr+uFdgBa5vEXYepLc73ysOVFV+zIeTfVHTB+E0k7zn89mdXnJi j9uXSNO6gTVHi+nvJRntS2ZXTB/HXVs0sebX1dnzlu+ZPyxxwBmi0KlMeC631jxw 8WE+b6FbKwAhJpqVc9LHEx8db8kFMBrzDri8/ci0z9o47C0R+hgeyQbi0EygtBrQ RSo0kxNK5irkYjgKtMD+xufwpRS3DvnbV15YL8oBRs5zTLM2/IZpeGi4iYvlDOnp rEta+T2Rg3nSSMgE/DfzJqsf5tN+kizIU91mhf6IIrCyuJ4Ume/xilf3b5zL0Aaa jo2MbuxAefrcJVV0npiPQgcEgvS5ausSu76TBJr6+V9OWLNJd5/wgsJyW6HJuJ8N voSk4DsAJrgb7cnsS+7lHbHbZjAyjEPz2uNL+uwegFCTY6kLksnqf+TOgWyNFj8i GDnqJab2Q3Xs6m5wvO5PXyU2HEiHmfeaT3YL9XJCwOeDpTbn5L6oPzkoWu8ujxPn EBD0s2NqgRDPawrZhm5yos8VMgF0EwL7Jz3z68JH/V+I3X3LxvXqWMVEZYr/EWPd Obcn11xVDSy3qws0IhfBAfVzbF6quZ/JGSV8VMdJQrMGx6RHlIo= =c+M2 -----END PGP SIGNATURE----- --8GpibOaaTibBMecb-- From nobody Fri Mar 2 01:26:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23E01270AE for ; Fri, 2 Mar 2018 01:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 BOjv-qL5A_ku for ; Fri, 2 Mar 2018 01:26:44 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224D41267BB for ; Fri, 2 Mar 2018 01:26:43 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9F2BE494EA for ; Fri, 2 Mar 2018 10:26:39 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A3063182 for ; Fri, 2 Mar 2018 10:26:38 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [141.244.83.126]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5551D3A for ; Fri, 2 Mar 2018 10:26:38 +0100 (CET) Received: (nullmailer pid 12311 invoked by uid 1000); Fri, 02 Mar 2018 09:26:37 -0000 Date: Fri, 2 Mar 2018 10:26:37 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: <20180302092637.GA10917@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: [core] Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 02 Mar 2018 09:26:46 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone interested in Resource Directory development, with the RD document[1] in a late stage of its development, I would like to run a plugtest of resource directory implementations. If you have implemented any part of RD (the directory itself, registering endpoint, a commissioning tool or a lookup client), are in the process of doing so or planning to, please contact me so we can arrange for the implementors to test their interoperability. Participation by parties that prefer not to be publicly named can be arranged if so desired. Date and modus of the event will depend on who'd be willing to participate. Looking forward to working with you Christian [1]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-13 --=20 You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe) --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqZGMgACgkQOY0REtOk veE21hAA1EzI0SdihrczJvdz9xSD+R15k00jEcbJXLehZHnXAxD9r3m2hsG3058k 03ODWlpKksFPi25SxFzBfqaWqzCuKJpLX78cpt6gIvTd0GjshoFnZqtsD3fvsT35 O21W9DQr/QTBAgFD1Dxl9ntVHj9kDE11zyimR3RYseD39k/EJAUKXrhz3zLE0WH0 bghD/9jZTBoiUzWD4fvE4KtJOX23XYdeQQNHPaXF8ORuBxJkmsd1ZeWuLBUM1AaL mTpFVC71/WzzwJIO+0fEgGwgqRiM3juUj9LreAOJtL5HstGSUudcCFFrciyWXiZr deheNst62NwmdigMWjgttYtPiRhb4Fi2h7HGL5Qi6sCy0bJEmoBa6W/17tjbkB96 HRS/mBbpSkEjxAUPRKm/TgRKu+eozEba9KuI3uuAQ5znmPTeXdndAVn4teYywq/z WvQ7TohkllR8At+jp6n0crK68ZDuq7KYrshO8Kbl3xTX8Cy/F59K0X86OYOVhkFG BxVRYA0j+TQB7LcRZmumze4d+T/QxGvUJPsOutkDEfpR8GlZ1mzlNN9Wh9Ja9pom NqUwzUo6JJtVLNuU7eCLXPWCzKcdZR877lLnUK61+qT6+BKF255zvn4SaFiBv/eG s39v4mhbVA7oe1bXxKfnhKGnes8eJ/8j/kCKL5BiNQu/l5jKA78= =mVz4 -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From nobody Fri Mar 2 01:42:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83392127201 for ; Fri, 2 Mar 2018 01:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 IY27naYl5sp4 for ; Fri, 2 Mar 2018 01:42:26 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7C2E21270AE for ; Fri, 2 Mar 2018 01:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519983744; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=exyMyDPQCOJiAxZRf+6pKseW/UA9iZl5cmACRNJ2PFo=; b=bbJ+4fTLyPRQQneJyDagpu/KRniJPLNOmqk+q9/ugC00oa4uTcrgVxMsTXnEAb/i oDe2hSW6wYkCWiDTnIYaClLwd43j3FsJPxAGTaNaXMXD2xuoYCSaYqdfPDymz3Am Lrof8VA9cH/IJKBkCwzl4qoLpo/zBxADEHBDV93z2+s=; X-AuditID: c1b4fb30-3b1ff70000004778-c9-5a991c806f1f Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.89.18296.08C199A5; Fri, 2 Mar 2018 10:42:24 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.88]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 10:42:24 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] Review of draft-silverajan-core-coap-protocol-negotiation Thread-Index: AQHTsgrDKsZ251wL3Em/Q+oEjvu8LQ== Date: Fri, 2 Mar 2018 09:42:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [194.157.54.14] Content-Type: multipart/signed; boundary="Apple-Mail=_D339DD3E-8F9B-4E57-95CA-5E9F69153D36"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM2K7gW6DzMwog+4p6hYXT8la7Hu7ntmB yWPJkp9MHvOnr2AMYIrisklJzcksSy3St0vgyrj3eA9TweeQilfzdzI2MDb5dTFyckgImEic XbKcsYuRi0NI4DCjxPcji6CcRYwS76ftZQapYhNwlvj0rJEdxBYRMJPYsusrK4jNLBAm8XX2 WrC4sICnxOen3SwQNQESM2/1MkLYehJvF/wFm8MioCIxY9NkMJtXwF5i9eaJTCA2o4CYxPdT a5ggZopL3HoynwniOhGJhxdPs0HYohIvH/9jhbAVJabMWskGciizwBRGifYlC5kghgpKnJz5 hGUCo9AsJLNmIaubhaQOoihJYs6ZH8wQtrbEsoWvoWxNif3dy1kwxTUkOr9NZIWwTSVeH/3I CGFbS8z4dZANwgY6sPsh+wJG7lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgbF4cMtvgx2M L587HmIU4GBU4uGdzDUzSog1say4MvcQowrQnEcbVl9glGLJy89LVRLhbfkwI0qINyWxsiq1 KD++qDQntfgQozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QDY4jdVcsbJ0+8+NTv+t5n 75+Ls1VmCgpt0ZybNN/aOGJ9jd+56tKrJ38IJf5ROHORIXrJ0/xqB5OzpXsPTVU3clyw/fCP WuXKdfNVH/Jbzje2/xX96dHKNk9by61G5gzlb1j63X7E8ExZ8CjP4Pwh7b3T+4uyTv5sV9jk pVn1QKf3GEvw+7x9e5RYijMSDbWYi4oTAT5KRubNAgAA Archived-At: Subject: [core] Review of draft-silverajan-core-coap-protocol-negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 02 Mar 2018 09:42:28 -0000 --Apple-Mail=_D339DD3E-8F9B-4E57-95CA-5E9F69153D36 Content-Type: multipart/alternative; boundary="Apple-Mail=_9DCFDD57-7138-478E-97E0-347E78CC830E" --Apple-Mail=_9DCFDD57-7138-478E-97E0-347E78CC830E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear authors, I had some time to review = draft-silverajan-core-coap-protocol-negotiation-07, below is the = feedback. * The RD option:=20 - have you thought about using this mechanism as a NAT traversal tool? - what happens if any of the context on =E2=80=9Cat=E2=80=9D is = different than the one used to register the endpoint. - is the lifetime of the registration also carried to the other = transport (is the ep being registered on both transports)? - are security associations between client and server reset when = switching transport? - I think the lookup example could benefit from a more complex lookup, = for instance using =E2=80=9Crt=E2=80=9D or =E2=80=9Cet=E2=80=9D with = =E2=80=9Ctt=E2=80=9D. * Alternative transports option: - I=E2=80=99m not sure about this but wouldn=E2=80=99t this force to = mandate specific CoAP ports per transport? - How large can the payload get? How many alternative transports are = there? Can=E2=80=99t we assume that we keep the scheme and simply answer = with the transport supported? * =E2=80=9Col=E2=80=9D attribute: - typo: availabilty=20 - this option, with no comment to how the context should be the same can = redirect a client to another server, right? Is that what we want? - OCF uses a similar link attribute called =E2=80=9Ceps=E2=80=9D. - there should at least exist an informative ref to core-link format. The security considerations part will require quite a bit of work. Implications on ETCH? This draft is intended as informational, however at some point we should = have some normative text too for implementors, right? Ciao! - - Jaime Jim=C3=A9nez= --Apple-Mail=_9DCFDD57-7138-478E-97E0-347E78CC830E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear authors,

I had some time to review = draft-silverajan-core-coap-protocol-negotiation-07, below is the = feedback.

* = The RD option: 
- have you thought about using = this mechanism as a NAT traversal tool?
- what = happens if any of the context on =E2=80=9Cat=E2=80=9D is different than = the one used to register the endpoint.
- is the = lifetime of the registration also carried to the other transport (is the = ep being registered on both transports)?
- are = security associations between client and server reset when switching = transport?
- I think the lookup example could = benefit from a more complex lookup, for instance using =E2=80=9Crt=E2=80=9D= or =E2=80=9Cet=E2=80=9D with =E2=80=9Ctt=E2=80=9D.

* Alternative transports = option:
- I=E2=80=99m not sure about this but = wouldn=E2=80=99t this force to mandate specific CoAP ports per = transport?
- How large can the payload get? How = many alternative transports are there? Can=E2=80=99t we assume that we = keep the scheme and simply answer with the transport = supported?

* = =E2=80=9Col=E2=80=9D attribute:
- typo: = availabilty 
- this option, with no comment to = how the context should be the same can redirect a client to another = server, right? Is that what we want?
- OCF uses a = similar link attribute called =E2=80=9Ceps=E2=80=9D.
- there should at least exist an informative ref to = core-link format.

The security considerations part will require quite a bit of = work.
Implications on ETCH?
This= draft is intended as informational, however at some point we should = have some normative text too for implementors, right?

Ciao!
- - Jaime = Jim=C3=A9nez
= --Apple-Mail=_9DCFDD57-7138-478E-97E0-347E78CC830E-- --Apple-Mail=_D339DD3E-8F9B-4E57-95CA-5E9F69153D36 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDMwMjA5NDIyMlowIwYJKoZIhvcNAQkEMRYEFESRXE2EaS/VQWfli5iA7UJndyEj MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEADf2+zxbZcIslfS1DfOpdrp1keDlW+1yKzmuxkvhXxw64HFs1nfIHz+TPI1TFAeJO 1EYXAU1ydMvzLR+8RTwpMJmmLXR8/vJwTbU33bEfMzntRVpRLlG/RnVNaaQ9IZ5a6hAT7GZwPeRF QsqiVDzqCLxEs/l7GPCTsE05a3CxTsjUNW/amrQoY1y9cSTk/z+aTllVhiR3X1uzkkrx6xMh6AQO +GF5Ohsahjty5wcJB0hy+ojpjk+ohW0oSzfI+ba6CwZf1ywl1V3MgAdzXABu6oJ2r79eGTjxJIAF fQruI2PhRmCW2VwZ3hrmjwjNUnMMEcSHnelXajaItDMb7nvb6AAAAAAAAA== --Apple-Mail=_D339DD3E-8F9B-4E57-95CA-5E9F69153D36-- From nobody Fri Mar 2 08:15:16 2018 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 AE36B12D82F; Fri, 2 Mar 2018 08:15:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152000730965.15767.8553862404707109358@ietfa.amsl.com> Date: Fri, 02 Mar 2018 08:15:09 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 16:15:10 -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 WG of the IETF. Title : Media Types for Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-13.txt Pages : 49 Date : 2018-03-02 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-13 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-13 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 Mar 2 08:19:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5006712E04F for ; Fri, 2 Mar 2018 08:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 s1EpGYTAUJlS for ; Fri, 2 Mar 2018 08:19:00 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 37B1212D7ED for ; Fri, 2 Mar 2018 08:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520007537; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CCn3Vmk6QC16Rr2Q0bGPyMoOX1WgQWY9VTar1ifVsn0=; b=Y9Os3je9EN1NojiDP5U18fRhWCSWUj1M7npczEtfJ+1dJT+ncFDwa9lMhp6vXW7U XPVMFlIEhFXPW5n94u/EBxy40mex94s3rpgAMZC0GIrYP68oEH89vl5gsNS8smcY LICEOWsuRg1WLnSGuY3iC6zxUMkC0b+ddRtLMDmLoMs=; X-AuditID: c1b4fb30-799639c000004778-02-5a99797135f4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BF.FF.18296.179799A5; Fri, 2 Mar 2018 17:18:57 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 17:18:15 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "core@ietf.org WG" Thread-Topic: [core] I-D Action: draft-ietf-core-senml-13.txt Thread-Index: AQHTskHBQZc2NgGN2Uy1KGq6X9M9eqO9DtoA Date: Fri, 2 Mar 2018 16:18:15 +0000 Message-ID: <4FB349EB-DEBC-48E5-BE87-1F041F1B60B1@ericsson.com> References: <152000730965.15767.8553862404707109358@ietfa.amsl.com> In-Reply-To: <152000730965.15767.8553862404707109358@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1306F6A2CB57784080856B7BB082EEC9@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7qG5h5cwog40LpS1mrC6y2Pd2PbMD k8eSJT+ZPE41GwYwRXHZpKTmZJalFunbJXBlvJy/nqXguGDFkcudLA2Mu3i7GDk5JARMJKbc e8bexcjFISRwmFHif99MNghnEaPE9o8rGEGq2ATsJSav+QhmiwioSbROesUGYjML6Ev82XiJ GcQWFrCR2PW0mQmixlbi2+NeNgjbSGLy5XOsIDaLgIrE4Q3tQNs4OHiBZs48ZQoSFhJwltgy /Qs7iM0p4CLx+Mc9MJtRQEzi+6k1TBCrxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2PISM87e gqrXk7gxdQrUmdYSbVu2sUPY2hLLFr4G6+UVEJQ4OfMJywRGsVlIVsxC0j4LSfssJO2zkLQv YGRdxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYUwe3/DbYwfjyueMhRgEORiUe3otZM6OE WBPLiitzDzFKcDArifC2fJgRJcSbklhZlVqUH19UmpNafIhRmoNFSZz3pCdvlJBAemJJanZq akFqEUyWiYNTqoGx2lbomeXnDXMNQqwePEwM5T9hfG7bi19vTmsXrvLwZ5wo4/V3slvyGpHZ uf8Pci9MOCJ8OHVDQK4Ed1agidYyLz27eWG+jF8mpd4zms70Xz7clUW8IJB7e7f2hspHX8qn 26kqvwzJ275vidU1lwcXm1d+ZbHh2L38YSjjAon27lPhx07FNXQpsRRnJBpqMRcVJwIApcBQ IqUCAAA= Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 02 Mar 2018 16:19:04 -0000 This update addresses the AD review comments from Alexey: https://www.ietf.org/mail-archive/web/core/current/msg09287.html Cheers, Ari > On 2 Mar 2018, at 18.15, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. >=20 > Title : Media Types for Sensor Measurement Lists (SenML) > Authors : Cullen Jennings > Zach Shelby > Jari Arkko > Ari Keranen > Carsten Bormann > Filename : draft-ietf-core-senml-13.txt > Pages : 49 > Date : 2018-03-02 >=20 > Abstract: > This specification defines media types for representing simple sensor > measurements and device parameters in the Sensor Measurement Lists > (SenML). Representations are defined in JavaScript Object Notation > (JSON), Concise Binary Object Representation (CBOR), eXtensible > Markup Language (XML), and Efficient XML Interchange (EXI), which > share the common SenML data model. A simple sensor, such as a > temperature sensor, could use one of these media types in protocols > such as HTTP or CoAP to transport the measurements of the sensor or > to be configured. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-senml/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-senml-13 > https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 From nobody Fri Mar 2 08:38:36 2018 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 5263312D779; Fri, 2 Mar 2018 08:38:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-senml@ietf.org, Jaime Jimenez , core@ietf.org, alexey.melnikov@isode.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152000871428.15727.17678319751035273348.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2018 08:38:34 -0800 Archived-At: Subject: [core] Last Call: (Media Types for Sensor Measurement Lists (SenML)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 16:38:35 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Media Types for Sensor Measurement Lists (SenML)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-senml/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-senml/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 2 14:11:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F081812D876; Fri, 2 Mar 2018 14:11:11 -0800 (PST) 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 E6kI81Mq3eGU; Fri, 2 Mar 2018 14:11:10 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 CFDDE1250B8; Fri, 2 Mar 2018 14:11:09 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id m69so15381369lfe.8; Fri, 02 Mar 2018 14:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=TE5G5502zci2EYM5qfgKwNKDoM2h7x1LM3uj124oKYU=; b=DtL/zjsHkdTIM4OcfyP4WKIpsuGkWTSv8rk15o9rrPAA3PUVkSr4v+7w5HQ7wxfbBj M21Y0C6k9pZVDEqzpCRRn3Neb+JgpfygdW1SlycVwEYY/VJ1qnNItH6hJs5uuA6IBO2a 7sm9ASdLqxBniaTCJegiO8W8thqRxu+NZB3oVFj5QqSo8BV2V464GqUP44PVfP1wGiwY UXTjWGOb+zRsCVEIQpMs7GCa5gSlgXQTl/8Nam3nft1W5D8HaBAWic9c4p34tOsIYuQG ViRkqiACqGQ54+G98EZLQwgei03YqLJW/PCrHNldX5tWaIH+bqTpJgS5BhrsODgHJR/k H+og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=TE5G5502zci2EYM5qfgKwNKDoM2h7x1LM3uj124oKYU=; b=BGrJrb7c0EBOJ9CIlvNZFD4cpAIznjjYnfK0HWQo7+3SMc9iaOVd3E0OZ8+1VPoXnA tLIa6TosWPnxwEUu409gDd6Pckkz488/WRUJEu54p7IzwD2DcespmzBM1XIo4bUUW0AC HiitmNjkBqFMNO/rS20ksd/6tBBTH9DHRFQ4jyMmVx1h5DoCO7PE7qu0p8pa02LOmnSM llcmn2kn2wPiE6Zb9CnWuHvM6mTDX24yQyaGgYExlE2kQ2ISZPf8hWx1lVgNWGCVGzIE Ya0ddVO6WYL9GJ9Ie3QrrfACBVrl07aLJEvqKw2uvD3gCzstGuLMbFAmKwCSnTQs9C4f Tahw== X-Gm-Message-State: AElRT7ElpnNW5CQMB9FGBvsiFjeihvB3gLG/HNJID8XdsX0FQDpPMLs1 o0ilVnTDFSejU90gQQSVLEsAQ9Y4Yu0OF3JhHhKFmJ+D X-Google-Smtp-Source: AG47ELsimSgiou48x8sB/as2VFEeYL6D3j7ticD+UpdUgrKCQJl19Uv5AduO+rXKpizc0jUn0nLk5+XgojPB7JcDNzk= X-Received: by 10.46.126.16 with SMTP id z16mr5024611ljc.103.1520028667931; Fri, 02 Mar 2018 14:11:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.54.13 with HTTP; Fri, 2 Mar 2018 14:11:07 -0800 (PST) From: Pascal Urien Date: Fri, 2 Mar 2018 23:11:07 +0100 Message-ID: To: core Cc: core-chairs@ietf.org Content-Type: multipart/alternative; boundary="089e08278f54ccf2f305667540d1" Archived-At: Subject: [core] http://www.ietf.org/id/draft-urien-core-blockchain-transaction-protocol-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 02 Mar 2018 22:11:12 -0000 --089e08278f54ccf2f305667540d1 Content-Type: text/plain; charset="UTF-8" Dear All The draft http://www.ietf.org/id/draft-urien-core-blockchain-transaction-protocol-00.txt introduces the idea of Blockchain Transaction Protocol for Constraint Nodes Anybody interested by this new paradigm ? The goal of the blockchain transaction protocol for constraint nodes is to enable the generation of blockchain transactions by constraint nodes, according to the following principles : - transactions are triggered by Provisioning-Messages that include the needed blockchain parameters. - binary encoded transactions are returned in Transaction-Messages, which include sensors/actuators data. Constraint nodes, associated with blockchain addresses, compute the transaction signature. Best Regards Pascal Urien --089e08278f54ccf2f305667540d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All

The draft


introduces= the idea of Blockchain Transaction Protocol for Constraint Nodes

Anybody interested by this new paradigm ?

The goal of the blockchain transaction protocol for constraint node= s=C2=A0=C2=A0is to enable the generation of blockchain transactions by cons= traint=C2=A0 nodes, according to the following principles :
- transacti= ons are triggered by Provisioning-Messages that include=C2=A0 the needed bl= ockchain parameters.=C2=A0
- binary encoded transactions are returned in= Transaction-Messages,=C2=A0=C2=A0=C2=A0 which include sensors/actuators da= ta. Constraint nodes, associated with blockchain addresses, compute the tra= nsaction signature.

Best Regards

Pascal Urien
--089e08278f54ccf2f305667540d1-- From nobody Sun Mar 4 11:20:49 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638DE124B18 for ; Sun, 4 Mar 2018 11:20:47 -0800 (PST) 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 Iw68RK2Vf7bQ for ; Sun, 4 Mar 2018 11:20:46 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 B217B1242F7 for ; Sun, 4 Mar 2018 11:20:45 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id v9so20000556lfa.11 for ; Sun, 04 Mar 2018 11:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0SKKMAi7XlMJ3+8jrn50tcCi8tVbeEHWrcJYOjMZXH0=; b=qQdqJObtmwqukNigWCJGpABBS6PPqaIxK9blEBja397bMqkFj9paqwIfLsWuRoGZ1h wAJ2nvTrXSBw2QaWuPw/wyI6tI0HF0RjMRUOt+w3v1TINQRdt7wY8ri4MOfPM8lKAeq1 5rHKw9O9ylZHd1DqWL+U5Gz9hZPNskXel/wBAyPHNhCmP1EHaI77WaZbopQExQ4UzDbg 4SgrAkAK2+pjO1pzemvCd08phL4iXSGTkMUz4Lnvo3oE28Rink1rIrkH2Lrf7oj19ztJ oAfp6a00xCnc4r+e4F+6v/nyOf3IZr8p+SFHgE5dOYECH5/D4vTqLBfESZeuWG5I2KpY 6jSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=0SKKMAi7XlMJ3+8jrn50tcCi8tVbeEHWrcJYOjMZXH0=; b=CBSHfgVfGOSnRTg5f4ttGXiZqT3mu+vAiiA6pqcqnlSE7RfvMALB/YqrgOCg6VCVXR BIGgeXea8i1ez7dH4bWt5VRaz6gPakarlSalcCaWhDJ8r1rADaWdqfy7oA+4QiXTT6Rk 6fGLmAcp6cRX13+qrAqtKVZrffwnKRvcIrA/DPBbB6Z708su/BNGP+S0UpEigIyzsJRs POu58OG7xVhq63TQO3e0jHVaJcPgk2GJFfqmM7/GMD5/wFaGnuEvtcv3bf/QLodW+rOG xlK/d2mv2UyyxUe3vkGw9dQOlQ+kzszIEelbmWOC0mj/XfpbynYBQXNkEyy54OBGL1F3 kSgg== X-Gm-Message-State: APf1xPBPzJKO6wTnnt2nJvqLaWUWojM8nQ5YzM6voX899pjycnQmsLH4 Me/IGZjF0dDQSp78ythhHe+v9Vwr4yeptCs713zFCVv7 X-Google-Smtp-Source: AG47ELs7l3pE/7bbgZhAQMHqWLU3LznuiQjgU2GcsQh6WK8Ba+8ANW6oRjbF5TBDvecbBgXlLGOJre3YFNHne5fVikk= X-Received: by 10.46.91.20 with SMTP id p20mr8595659ljb.61.1520191243737; Sun, 04 Mar 2018 11:20:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.54.13 with HTTP; Sun, 4 Mar 2018 11:20:43 -0800 (PST) In-Reply-To: References: From: Pascal Urien Date: Sun, 4 Mar 2018 20:20:43 +0100 Message-ID: To: core Content-Type: multipart/alternative; boundary="94eb2c075cc612e07805669b1b36" Archived-At: Subject: Re: [core] http://www.ietf.org/id/draft-urien-core-blockchain-transaction-protocol-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 04 Mar 2018 19:20:47 -0000 --94eb2c075cc612e07805669b1b36 Content-Type: text/plain; charset="UTF-8" Hi All The draft http://www.ietf.org/id/draft-urien-core-blockchain- transaction-protocol-00.txt proposes to forward sensors/actuators data in blockchain transactions for authentication, publication and dating purposes Two messages are nedeed, to be inserted in CoAP payload 1) Provisionning Message, such as ========================== { "type": 1, "nonce": 12, "gasPrice": 30, "gasLimit": 80000, "address": "6BAC1B75185D9051AF740AB909F81C71BBB221A6", "value": 0 } 2) Transaction Message, such as ========================= { "type": 1, "transaction": "F8 74 // RLP List, length= 116 bytes 0C // nonce 1 byte =12 decimal 85 06FC23AC00 // gasPrice = 30 GWei 83 013880 // gasLimit = 80000 gas // recipient address 20 bytes 94 6BAC1B75185D9051AF740AB909F81C71BBB221A6 80 // Null Ether Value // Data 15 bytes "Temperature=25C" 8F 54656D70657261747572653D323543 1B // recovery parameter, 1 byte A0 // r, 32 bytes, ECDSA r paramter A9B58980F76EE6284800B82A2B5DF13E456887EC0CF426A5E5D6A738EB1784ED A0 // s, 32 bytes, ECDSA s parameter 629633C6A3ED5FEE0FB40E2D1CF251345B885D372857B1A6C4762C9BE914281F " } Any comment ? Pascal --94eb2c075cc612e07805669b1b36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
proposes to forward sensors/actuators data in blockchain = transactions for authentication, publication and dating purposes
=
Two messages are nedeed, to be inserted in CoAP payload

1) Provisionning Message, such as
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=C2=A0{
=C2=A0 =C2=A0 =C2=A0"type&= quot;: 1,
=C2=A0 =C2=A0 =C2=A0"nonce": 12,
= =C2=A0 =C2=A0 =C2=A0"gasPrice": 30,
=C2=A0 =C2=A0 =C2= =A0"gasLimit": 80000,
=C2=A0 =C2=A0 =C2=A0"address= ": "6BAC1B75185D9051AF740AB909F81C71BBB221A6",
=C2= =A0 =C2=A0 =C2=A0"value": 0
=C2=A0 }

2) Transaction Message, such as
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0{
=C2=A0 =C2=A0"type": 1,
=C2=A0 =C2= =A0"transaction":
=C2=A0 =C2=A0"F8 74 // RLP List,= length=3D 116 bytes
=C2=A0 =C2=A0 0C // nonce 1 byte =3D12 decim= al
=C2=A0 =C2=A0 85 06FC23AC00 // gasPrice =3D 30 GWei
= =C2=A0 =C2=A0 83 013880=C2=A0 =C2=A0 =C2=A0// gasLimit =3D 80000 gas
<= div>=C2=A0 =C2=A0 // recipient address 20 bytes
=C2=A0 =C2=A0 94 = 6BAC1B75185D9051AF740AB909F81C71BBB221A6
=C2=A0 =C2=A0 80 // Null= Ether Value
=C2=A0 =C2=A0 // Data 15 bytes "Temperature=3D2= 5C"
=C2=A0 =C2=A0 8F 54656D70657261747572653D323543
=C2=A0 =C2=A0 1B // recovery parameter, 1 byte
=C2=A0 =C2=A0 A0= // r, 32 bytes, ECDSA r paramter
=C2=A0 =C2=A0 A9B58980F76EE6284= 800B82A2B5DF13E456887EC0CF426A5E5D6A738EB1784ED
=C2=A0 =C2=A0 A0 = // s, 32 bytes, ECDSA s parameter
=C2=A0 =C2=A0 629633C6A3ED5FEE0= FB40E2D1CF251345B885D372857B1A6C4762C9BE914281F
=C2=A0 =C2=A0&quo= t;

=C2=A0}


Any comment ?

Pascal
--94eb2c075cc612e07805669b1b36-- From nobody Mon Mar 5 03:23:55 2018 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 0EA4E128D2E; Mon, 5 Mar 2018 03:23:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152024903003.27943.18205993894391280293@ietfa.amsl.com> Date: Mon, 05 Mar 2018 03:23:50 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 11:23:50 -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 WG of the IETF. Title : Secure group communication for CoAP Authors : Marco Tiloca Goeran Selander Francesca Palombini Jiye Park Filename : draft-ietf-core-oscore-groupcomm-01.txt Pages : 33 Date : 2018-03-05 Abstract: This document describes a mode for protecting group communication over the Constrained Application Protocol (CoAP). The proposed mode relies on Object Security for Constrained RESTful Environments (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. In particular, it is defined how OSCORE should be used in a group communication setting, while fulfilling the same security requirements for request messages and related response messages. Source authentication of all messages exchanged within the group is ensured, by means of digital signatures produced through private keys of sender endpoints and embedded in the protected CoAP messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-01 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 Mar 5 03:25:26 2018 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 71C2C128D2E; Mon, 5 Mar 2018 03:25:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152024912542.27878.598291923832364161@ietfa.amsl.com> Date: Mon, 05 Mar 2018 03:25:25 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-interfaces-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 11:25:25 -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 WG of the IETF. Title : Reusable Interface Definitions for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Julian Zhu Bilhanan Silverajan Filename : draft-ietf-core-interfaces-11.txt Pages : 27 Date : 2018-03-05 Abstract: This document defines a set of Constrained RESTful Environments (CoRE) Link Format Interface Descriptions [RFC6690] applicable for use in constrained environments. These include the: Actuator, Parameter, Read-only parameter, Sensor, Batch, Linked Batch and Link List interfaces. The Batch, Linked Batch and Link List interfaces make use of resource collections. This document further describes how collections relate to interfaces. Many applications require a set of interface descriptions in order provide the required functionality. This document defines an Interface Description atribute value to describe resources conforming to a particular interface. Editor's notes: o The git repository for the draft is found at https://github.com/ The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-interfaces-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-11 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 Mar 5 06:30:58 2018 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 4DC2512D82F; Mon, 5 Mar 2018 06:30:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152026025626.14608.10905496210990952016@ietfa.amsl.com> Date: Mon, 05 Mar 2018 06:30:56 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 14:30:56 -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 WG of the IETF. Title : Uniform Resource Names for Device Identifiers Authors : Jari Arkko Cullen Jennings Zach Shelby Filename : draft-ietf-core-dev-urn-00.txt Pages : 12 Date : 2018-03-05 Abstract: This memo describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dev-urn-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-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 Mar 5 06:52:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C7412711E for ; Mon, 5 Mar 2018 06:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 2WWHc4fmBk6q for ; Mon, 5 Mar 2018 06:52:18 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6654712711D for ; Mon, 5 Mar 2018 06:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520261536; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KbCAwbEgh+G11Hj47xVqzwHHCbbIR11Luf75JFqAbSI=; b=Ur5acNdixiHG0m8mKVMR13cDGqoVsME3L9CJXR7J3neAL0vscI7PW64WH+ke20Fe 6w5FR+eg4eO+ggYF2PwmX3X1w+5sRdanQoMF2BpLa7rS7AxyinJjdQvjtBI/DMgX lJXrxBdfcQHmyuCPHqTa5gw42T4qVHOeUG+y+P9n7vQ=; X-AuditID: c1b4fb25-44ba69c000002d5f-62-5a9d59a0cff8 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 00.C5.11615.0A95D9A5; Mon, 5 Mar 2018 15:52:16 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 5 Mar 2018 15:52:03 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) Thread-Index: AQHTtJGF3s1hygoqikCLwnlBtqOdjw== Date: Mon, 5 Mar 2018 14:52:03 +0000 Message-ID: <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.234.218.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <67AC64D6E56ED146922D7CFA59DD33A5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7iu6CyLlRBleu6Vrse7ue2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGTcWdbEUfOOv2LdpFVsD4yOeLkZODgkBE4lTm+awdDFycQgJ HGaUaNhylRXCWcQo8XDDVhaQKjYBe4nJaz4ygtgiAhISnV/3s4PYwgKJEhc2H2GFiKdJrLm7 AMrWkzjd/RSonoODRUBF4uC0XJAwL9CYmV8/sIHYQgJ+Etdm3mYGsRkFxCS+n1rDBGIzC4hL 3HoynwniOAGJJXvOM0PYohIvH/9jhbCVJdY9eMIIUa8ncWPqFDYI21qiaedHFghbW2LZwtfM EHsFJU7OfMIygVFkFpIVs5C0z0LSPgtJ+ywk7QsYWVcxihanFiflphsZ66UWZSYXF+fn6eWl lmxiBMbEwS2/VXcwXn7jeIhRgINRiYfX0ntulBBrYllxZe4hRgkOZiURXilJoBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXHeOcLtUUIC6YklqdmpqQWpRTBZJg5OqQbGmNkBL02nzbTfOon3420x ph9bJojVZX+10c76uXJ7aDh3SdqmEu4I8UwZ5ile5/euEm+b2VQvfUMsYqpqR7pAYcIdiy9Z rcwLHlgYx0gx/l8U95phw8ubARbO67j+Kf1W/5cofF5QT2dKT9zzCtMvy5J+Poj8nmkWuV6D 7dadhHoFReUTB/mUWIozEg21mIuKEwEDlkqyhQIAAA== Archived-At: Subject: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 14:52:20 -0000 Hi all, I submitted a new draft about the "Too Many Requests" CoAP Response Code (s= ee details below). This was part of the CoAP pub/sub draft before, but as d= iscussed in the previous meeting, there's also more wider use for this resp= onse code so it makes sense to have a separate draft about it. While thinking about the details, I did realize that we may want to also de= fine ways for the server to indicate what kind of requests are OK, or not O= K. However, that topic may also be applicable beyond this Response Code so = I didn't yet put any details here, just TBD markers. Perhaps that's also so= mething to discuss at the London meeting. Cheers, Ari > A new version of I-D, draft-keranen-core-too-many-reqs-00.txt > has been successfully submitted by Ari Keranen and posted to the > IETF repository. >=20 > Name: draft-keranen-core-too-many-reqs > Revision: 00 > Title: Too Many Requests Response Code for the Constrained Application P= rotocol > Document date: 2018-03-05 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-keranen-core-t= oo-many-reqs-00.txt > Status: https://datatracker.ietf.org/doc/draft-keranen-core-too-m= any-reqs/ > Htmlized: https://tools.ietf.org/html/draft-keranen-core-too-many-r= eqs-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-keranen-core-= too-many-reqs-00 >=20 >=20 > Abstract: > A Constrained Application Protocol (CoAP) server can experience > temporary overload because one or more clients are sending requests > to the server at a higher rate than the server is capable or willing > to handle. This document defines a new CoAP Response Code for a > server to indicate that a client should reduce the rate of requests. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon Mar 5 08:23:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4477012D944 for ; Mon, 5 Mar 2018 08:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] 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 hFXilQovfqfD for ; Mon, 5 Mar 2018 08:23:41 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09B912D940 for ; Mon, 5 Mar 2018 08:23:40 -0800 (PST) Received: from mail-qt0-f180.google.com ([209.85.216.180]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1esstm-0001xT-GL; Mon, 05 Mar 2018 17:23:38 +0100 Received: by mail-qt0-f180.google.com with SMTP id c7so20991717qtn.3 for ; Mon, 05 Mar 2018 08:23:38 -0800 (PST) X-Gm-Message-State: AElRT7Fjgj2N865rpFrhlsjv1ioLsbxNqc2jhcppyE7JdTmaMGblvipW MzAjGocnVHRC5tcNV3iPLPuRtjxAHMRS5zC9/Uo= X-Google-Smtp-Source: AG47ELuYMXV+/m0RfnjqZe94KF3EWfyYHVEWi5PLIm8vmC9xgTh6O+a0hTZqnl0XtMEu/ELCCndZPv22bBW34LUP+p8= X-Received: by 10.200.35.235 with SMTP id r40mr24486233qtr.256.1520267017344; Mon, 05 Mar 2018 08:23:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.134.195 with HTTP; Mon, 5 Mar 2018 08:22:57 -0800 (PST) In-Reply-To: <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> From: Klaus Hartke Date: Mon, 5 Mar 2018 17:22:57 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1520267021; d0a8fecd; X-HE-SMSGID: 1esstm-0001xT-GL Archived-At: Subject: Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 16:23:43 -0000 Hi Ari, > TBD: If a server chooses to (not)accept a request based on the > method/resource, how should this be indicated in the reply? > > TBD: what kind of requests are (not) OK during the Max-Age? For > example: the client MAY send a different request, in particular if > the expected load for the server is smaller with that request? I guess the response code could be used in a number of ways, e.g.: A: 1. if not resource exists: return 4.04 2. if too many requests: return 4.29 3. if not method supported: return 4.05 4. process request B: 1. if not resource exists: return 4.04 2. if not method supported: return 4.05 3. if too many requests: return 4.29 4. process request C: 1. if too many requests: return 4.29 2. if not resource exists: return 4.04 3. if not method supported: return 4.05 4. process request 'A' seems to make sense if the request rate is limited per client/resource pair; 'B' if the request rate is limited per client/resource/method triple; and 'C' if the request rate is limited per client only. Is it important that a client can distinguish between these three modes? Should all of them be supported or would it be ok to mandate one of them? RFC 6585 seems to leave all details to implementations. Quick, pedantic review of KEYWORDS: > If a CoAP server is unable to serve a client that is sending CoAP > request messages more often than the server is capable or willing to > handle, the server SHOULD respond to the request(s) with the Response > Code 4.29, "Too Many Requests". This "SHOULD" is hard to satisfy since not all implementers might be aware that this response code exists. --> "A server MAY return a 4.29 (Too Many Requests) response if a CoAP client request messages more often than the server is capable or willing to handle." > The server MAY include in the > response a Max-Age option indicating the number of seconds after > which the server assumes it is OK for the client to retry the > request. Thou shalt not make normative statements that repeat or contradict RFC 7252= . Every 4.xx response has a Max-Age option (which may be efficiently encoded with 0 bytes if the value equals the default value, but is technically still there). --> "The Max-Age Option is used to indicate the number of seconds after which to retry." > If a client receives the 4.29 Response Code from a CoAP server to a > request, it SHOULD NOT send the same request to the server before the > time indicated in the Max-Age option has passed. Not sure if this can be required. It's more like the client is encouraged to not retry before Max-Age expires. > If the response > does not contain Max-Age option, the client SHOULD wait for the Max- > Age default value, 60 seconds. Thou shalt not make normative statements that repeat or contradict RFC 7252= . The default value of 60 seconds is already specified. Review summary: Ready for WG adoption. (Are there any other proposed CoAP codes that could be merged into this document to streamline registration?) Klaus On 5 March 2018 at 15:52, Ari Ker=C3=A4nen wrote= : > Hi all, > > I submitted a new draft about the "Too Many Requests" CoAP Response Code = (see details below). This was part of the CoAP pub/sub draft before, but as= discussed in the previous meeting, there's also more wider use for this re= sponse code so it makes sense to have a separate draft about it. > > While thinking about the details, I did realize that we may want to also = define ways for the server to indicate what kind of requests are OK, or not= OK. However, that topic may also be applicable beyond this Response Code s= o I didn't yet put any details here, just TBD markers. Perhaps that's also = something to discuss at the London meeting. > > > Cheers, > Ari > >> A new version of I-D, draft-keranen-core-too-many-reqs-00.txt >> has been successfully submitted by Ari Keranen and posted to the >> IETF repository. >> >> Name: draft-keranen-core-too-many-reqs >> Revision: 00 >> Title: Too Many Requests Response Code for the Constraine= d Application Protocol >> Document date: 2018-03-05 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/internet-drafts/draft-keranen-core-= too-many-reqs-00.txt >> Status: https://datatracker.ietf.org/doc/draft-keranen-core-too-= many-reqs/ >> Htmlized: https://tools.ietf.org/html/draft-keranen-core-too-many-= reqs-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-keranen-core= -too-many-reqs-00 >> >> >> Abstract: >> A Constrained Application Protocol (CoAP) server can experience >> temporary overload because one or more clients are sending requests >> to the server at a higher rate than the server is capable or willing >> to handle. This document defines a new CoAP Response Code for a >> server to indicate that a client should reduce the rate of requests. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat From nobody Mon Mar 5 09:18:40 2018 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 0EB2D12D96B; Mon, 5 Mar 2018 09:18:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152027031904.14551.17307338670823240824@ietfa.amsl.com> Date: Mon, 05 Mar 2018 09:18:39 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 17:18:39 -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 WG of the IETF. Title : Object Security for Constrained RESTful Environments (OSCORE) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-09.txt Pages : 64 Date : 2018-03-05 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-09 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-09 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 Mar 5 09:39:28 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B93124F57 for ; Mon, 5 Mar 2018 09:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 JF-2gJw9klMK for ; Mon, 5 Mar 2018 09:39:14 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 7CC4E12DA19 for ; Mon, 5 Mar 2018 09:39:14 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id e7so18889970ioj.1 for ; Mon, 05 Mar 2018 09:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NqE886jKnluFs4mXh/cf7V7T+SoR6JoaZeTsvhtTmes=; b=M0p2MMYapMyV+Lq4XJcmwuT1W0Aoj9jA9PoEF/WbYtpdkgbENDZhPpkUU4s9b2VPpl 2JICSIznDmvEJvDnCth7BTqW+dldma5aWMAGrXpbeQL7XcFqbtBhIklNlSu8EAZA3da8 m883FWCL9IdqO1vGpboOjc0H3zD2r0erUWNi83QpC2eMkSgOsrwt14MYMfRa81oePd30 6W3zrf8Ql3sDE/t5fVcxUMro9MtAhWapWF3u/sEj1RGsEifUya7RK0i91/DBW4HYgSJT +hUL6G8dZfJ/Hptr+wXMRN2128mzLqZEasvV8FL8oiMeJTV6mkzPSrJvKk6V1B+Ukz2+ d4+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NqE886jKnluFs4mXh/cf7V7T+SoR6JoaZeTsvhtTmes=; b=B8TrdpX5aPMZ/jTtGYC8cKo2aih98S3Jh2zK2Fa9GD3tyrpKoq0lzJ0MI3rs0NvHEN tdpU71zHNZkvlnycbAhQtgvyIU9SpQvUW4AusmsV1OD8fmYxSdqH4xxvD3qz4oBunOiw WrznG4yMpfHJZmoG6+SuKlFWEOJVZ6C/OuaXMR05RyO2sjHAJUcELFxhbYbXCxjk0EKl 7Nq7IYMO9VTmUbmmYNRXRXgjBFGWGo/7aj94XPwcmxpMyyUlWwENeveFveQEn05GfXu1 wp/qGc6TyB5Gyf0AUziQvcUC49tlpUxhpDy/HqXcOWdqfSIbRBu5phOvAEW9bMO46pAz pVcA== X-Gm-Message-State: AElRT7HrcDmH5KSjfTMTNtwQHXlXTNeH7qfrEuR0KDxAqoEubhiUONjS xnsydlJuLG4fGcrnBVRiG+8= X-Google-Smtp-Source: AG47ELtUe2xAG61XUPpnyZjrcWvlAnSvgBSJvm8y/dhvEFTA9XVWHxG17So7SCYN5h1A0OQBNSdEqg== X-Received: by 10.107.24.4 with SMTP id 4mr1787997ioy.149.1520271553654; Mon, 05 Mar 2018 09:39:13 -0800 (PST) Received: from [10.0.0.3] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id k6sm8166873ioc.75.2018.03.05.09.39.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 09:39:12 -0800 (PST) From: Michael Koster Message-Id: <2599BFCF-9A26-40BE-95E1-FBFF6B1ECDD4@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F1D9466-28B0-47C4-A260-BC8084553AC3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 5 Mar 2018 09:39:10 -0800 In-Reply-To: Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , core To: Klaus Hartke References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 17:39:16 -0000 --Apple-Mail=_6F1D9466-28B0-47C4-A260-BC8084553AC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We are proposing a code in Pub/Sub for the case of a broker where the = topic exists but there is not a valid data value. We may be able to use = an empty representation as we have decided to do with empty link = collections but I fear we need more generality than depending on a = special representation value to indicae no data. We thought that an equivalent to the HTTP 204 "No Content" could be used = but the code conflicts with 2.04 in CoAP, so we propose 2.07 https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ = Not sure if it makes sense to combine them at this time, but it might. Best regards, MIchael > On Mar 5, 2018, at 8:22 AM, Klaus Hartke = wrote: >=20 > Review summary: Ready for WG adoption. (Are there any other proposed > CoAP codes that could be merged into this document to streamline > registration?) --Apple-Mail=_6F1D9466-28B0-47C4-A260-BC8084553AC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We are proposing a code in Pub/Sub for the case of a broker = where the topic exists but there is not a valid data value. We may be = able to use an empty representation as we have decided to do with empty = link collections but I fear we need more generality than depending on a = special representation value to indicae no data.

We thought that an equivalent to the = HTTP 204 "No Content" could be used but the code conflicts with 2.04 in = CoAP, so we propose 2.07

https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/

Not sure if = it makes sense to combine them at this time, but it might.

Best regards,

MIchael


On = Mar 5, 2018, at 8:22 AM, Klaus Hartke <hartke@projectcool.de> wrote:

Review summary: Ready for WG = adoption. (Are there any other proposed
CoAP codes that could be merged = into this document to streamline
registration?)

= --Apple-Mail=_6F1D9466-28B0-47C4-A260-BC8084553AC3-- From nobody Mon Mar 5 09:45:05 2018 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 4B269124F57; Mon, 5 Mar 2018 09:44:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152027189927.14579.7504583833581298444@ietfa.amsl.com> Date: Mon, 05 Mar 2018 09:44:59 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-rd-dns-sd-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 17:44:59 -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 WG of the IETF. Title : CoRE Resource Directory: DNS-SD mapping Authors : Kerry Lynn Peter van der Stok Michael Koster Christian Amsuess Filename : draft-ietf-core-rd-dns-sd-01.txt Pages : 12 Date : 2018-03-05 Abstract: Resource and service discovery are complimentary. Resource discovery provides fine-grained detail about the content of a server, while service discovery can provide a scalable method to locate servers in large networks. This document defines a method for mapping between CoRE Link Format attributes and DNS-Based Service Discovery fields to facilitate the use of either method to locate RESTful service interfaces (APIs) in mixed HTTP/CoAP environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-rd-dns-sd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-rd-dns-sd-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-rd-dns-sd-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-rd-dns-sd-01 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 Mar 5 09:52:42 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196C112DA19 for ; Mon, 5 Mar 2018 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] 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 fj05ntQwsIOW for ; Mon, 5 Mar 2018 09:52:38 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A3B12DA14 for ; Mon, 5 Mar 2018 09:52:38 -0800 (PST) Received: from mail-qt0-f174.google.com ([209.85.216.174]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1esuHs-0008PH-Cm; Mon, 05 Mar 2018 18:52:36 +0100 Received: by mail-qt0-f174.google.com with SMTP id a23so21355542qtn.0 for ; Mon, 05 Mar 2018 09:52:36 -0800 (PST) X-Gm-Message-State: AElRT7Ek1zF/CVRRLsWwaWuEfAbIW6LDH6k+V7Jg4F4SfNUH4VlLzFTT 4sJs4g3MqQt2sYbrimmxalE0EuMNhgBEHVXQaAA= X-Google-Smtp-Source: AG47ELuZcI75SfzKxVHiRNQsbFK/DmTEhccAhkZ6XrEUrFkmxu42puD+kQoyrP39kw2xZg/RYrRdcjs/Uiip3Or2x8M= X-Received: by 10.200.81.84 with SMTP id h20mr24733918qtn.340.1520272355364; Mon, 05 Mar 2018 09:52:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.134.195 with HTTP; Mon, 5 Mar 2018 09:51:54 -0800 (PST) In-Reply-To: <2599BFCF-9A26-40BE-95E1-FBFF6B1ECDD4@gmail.com> References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> <2599BFCF-9A26-40BE-95E1-FBFF6B1ECDD4@gmail.com> From: Klaus Hartke Date: Mon, 5 Mar 2018 18:51:54 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michael Koster Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , core Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1520272358; a42cabf8; X-HE-SMSGID: 1esuHs-0008PH-Cm Archived-At: Subject: Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 17:52:40 -0000 Michael Koster wrote: > We are proposing a code in Pub/Sub for the case of a broker where the topic > exists but there is not a valid data value. This sounds strangely familiar: https://tools.ietf.org/html/draft-hartke-core-pending-02 > We thought that an equivalent to the HTTP 204 "No Content" could be used but > the code conflicts with 2.04 in CoAP, so we propose 2.07 We had that in the -01 version of the draft, but that didn't seem to gain traction, so we've switched to a new content-format to indicate this status. Would this work for pub/sub? Klaus From nobody Mon Mar 5 13:30:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8520D12E8C7 for ; Mon, 5 Mar 2018 13:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 o35n121vmruq for ; Mon, 5 Mar 2018 13:30:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 63F2712D870 for ; Mon, 5 Mar 2018 13:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520285420; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7QQMtuhXlYIZN6PrN5qUITPleHcygl3nLsru8dWdFYw=; b=AeGxcTQT7P9DT2VGoZPTfUjVksaCkPWoaAEFgBXHMA0d3H1qSt982BzJPBGAKsAV 1qCYds6tyQ7sFlOBM79yclfikS1P4x5KS8Lc1HcRG9zmoO9871MRqKKmR9/9aGvv O6y8lUyQFI90BSiCT3gIcUxzlIeR9qtFVNuhjAjDni0=; X-AuditID: c1b4fb2d-4b1ff70000005540-5d-5a9db6ec033f Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.AB.21824.CE6BD9A5; Mon, 5 Mar 2018 22:30:20 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 5 Mar 2018 22:30:18 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: "Media Types for FETCH & PATCH with SenML" draft (draft-keranen-core-senml-fetch-00) Thread-Index: AQHTtMknO+zwwwSFMEe89ySYTKMyxA== Date: Mon, 5 Mar 2018 21:30:17 +0000 Message-ID: References: <152028460919.31626.889945460120040546.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdQPfNtrlRBrOP6Vjse7ue2eLarh0s DkweS5b8ZPLoORMawBTFZZOSmpNZllqkb5fAlbFow0/Wgh+CFXNmzWVpYNzG18XIySEhYCLx a34HC4gtJHCYUeJwZ2oXIxeQvYhR4sTmc6wgCTYBe4nJaz4ygtgiAhISnV/3s4PYzAI6Eh3/ eplAbGGBeInJM3+wQNSkSPyZ8x3I5gCy9ST2vdMBMVkEVCQW73UBqeAFmvj9ciMbxFofickf dzGD2IwCYhLfT61hgpguLnHryXwmiDMFJJbsOc8MYYtKvHz8jxXClpeYcfYWVL2exI2pU9gg bGuJ7/2zWCFsbYllC18zQ+wVlDg58wnLBEbRWUhWzELSPgtJ+ywk7bOQtC9gZF3FKFqcWlyc m25krJdalJlcXJyfp5eXWrKJERg5B7f81t3BuPq14yFGAQ5GJR7ezNVzo4RYE8uKK3MPMUpw MCuJ8F5vAArxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLglGpg lJY/sL+lcZprzotJU1+vvHE2jLkpbc+SqFub90k23dxR+lD954N05d8iH9XYQqYJKh1iv7D9 iJpj+eZUhdDMX+dWf1yjzKydeKX+iV6j7KMtlTWim4K09D7fPBiS8PVnopvl/ZL3VxVVZ09r m+M897GNVivH2p0aWywqb+dze+Zd45kedfbJQyWW4oxEQy3mouJEADEqhoqYAgAA Archived-At: Subject: [core] "Media Types for FETCH & PATCH with SenML" draft (draft-keranen-core-senml-fetch-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 21:30:25 -0000 Hi all, We have submitted a new draft about "Media Types for FETCH & PATCH with Sen= ML" (see details below).=20 The idea behind the draft is to enable efficient retrieval and changing of = data represented using the SenML data model. The draft proposes a simple wa= y to extend the SenML data model for use with the FETCH and PATCH methods. The main use case so far has been with IPSO smart objects (and that's why t= he examples currently use SenML of IPSO smart objects), but naturally the s= ame media types should apply to any SenML data. The draft also misses still= quite a bit of formality and focuses on the examples. In particular we'd like to hear your opinions on the potential format for w= ild card selectors: https://tools.ietf.org/html/draft-keranen-core-senml-fetch-00#section-3.1.1 Cheers, Ari > A new version of I-D, draft-keranen-core-senml-fetch-00.txt > has been successfully submitted by Ari Keranen and posted to the > IETF repository. >=20 > Name: draft-keranen-core-senml-fetch > Revision: 00 > Title: Media Types for FETCH & PATCH with Sensor Measurement Lists (SenM= L) > Document date: 2018-03-05 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-keranen-core-s= enml-fetch-00.txt > Status: https://datatracker.ietf.org/doc/draft-keranen-core-senml= -fetch/ > Htmlized: https://tools.ietf.org/html/draft-keranen-core-senml-fetc= h-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-keranen-core-= senml-fetch-00 >=20 >=20 > Abstract: > The Sensor Measurement Lists (SenML) media type and data model can be > used to send collections of resources, such as batches of sensor data > or configuration parameters. The CoAP PATCH and FETCH methods enable > accessing and updating parts of a resource or multiple resources with > one request. This document defines two new media types that can be > used with the CoAP PATCH and FETCH methods for resources represented > with the SenML data model. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon Mar 5 14:05:56 2018 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 0F61D12008A; Mon, 5 Mar 2018 14:05:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152028755604.12856.5158122301533944634@ietfa.amsl.com> Date: Mon, 05 Mar 2018 14:05:56 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 22:05:56 -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 WG of the IETF. Title : Echo and Request-Tag Authors : Christian Amsüss John Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-01.txt Pages : 19 Date : 2018-03-05 Abstract: This document specifies several security enhancements to the Constrained Application Protocol (CoAP). Two optional extensions are defined: the Echo option and the Request-Tag option. Each of these options provide additional features to CoAP and protects against certain attacks. The document also updates the processing requirements on the Block options and the Token. The updated Token processing ensures secure binding of responses to requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-01 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 Mar 5 14:18:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D912008A for ; Mon, 5 Mar 2018 14:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 w-WtIrFrtXy3 for ; Mon, 5 Mar 2018 14:18:28 -0800 (PST) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4EF126D05 for ; Mon, 5 Mar 2018 14:18:20 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 8AF64205109; Mon, 5 Mar 2018 22:18:16 +0000 (UTC) Received: from [192.168.0.65] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 5 Mar 2018 23:18:17 +0100 To: Esko Dijk , =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" References: From: Marco Tiloca Message-ID: Date: Mon, 5 Mar 2018 23:18:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8FUbQ422YuUNv6I4Dqs6pOXgoVycUeEwB" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=v2DPQv5-lfwA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=xPT6tdSuAAAA:8 a=T-so6kaxz5RBB1ExsiAA:9 a=PWQcVS_gFDwuQD_L:21 a=JEaEsvG0ce9qI4ja:21 a=QEXdDO2ut3YA:10 a=UqCG9HQmAAAA:8 a=VTINOrHo9nOQEdvltRcA:9 a=uZN14KWFS1839jFZ:21 a=OxQg_4DK8WxHTRwx:21 a=JWjjDCEsxlVRG9bD:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=PG1v3UBYGiaZf4S919wA:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=80PJfYVSYmV_jLpvUEnt:22 X-Virus-Scanned: clamav-milter 0.99.3 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-tilo?= =?utf-8?q?ca-core-multicast-oscoap?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 22:18:37 -0000 --8FUbQ422YuUNv6I4Dqs6pOXgoVycUeEwB Content-Type: multipart/mixed; boundary="OANRdThn9Qyz1bndRcKQ4x2XgxbIZ54DO"; protected-headers="v1" From: Marco Tiloca To: Esko Dijk , =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: =?UTF-8?Q?Re:_[core]_=f0=9f=94=94_WG_Call_for_Adoption_on_draft-til?= =?UTF-8?Q?oca-core-multicast-oscoap?= References: In-Reply-To: --OANRdThn9Qyz1bndRcKQ4x2XgxbIZ54DO Content-Type: multipart/alternative; boundary="------------0BCDE1B4B39BA01EE5896B24" Content-Language: en-US This is a multi-part message in MIME format. --------------0BCDE1B4B39BA01EE5896B24 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Esko, Thanks for your support and comments, we have considered them when producing the latest version of the draft [1]. Please, find in line some answers to your comments. Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-01 On 2017-12-04 14:35, Esko Dijk wrote: > > I also support the adoption of this draft as a work item for CoRE. > Below are the results of a quick review, also. > > =C2=A0 > > Best regards > > Esko Dijk > > =C2=A0 > > =C2=A0 > > Overall comments =E2=80=93 or work that the WG could take up next > > =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Detailed example= with message sizes would be useful. Since > it=E2=80=99s important for multicast over 6lowpan performance that the = IPv6 > packets stay small enough (one 802.15.4 frame). At this moment, I > can=E2=80=99t judge that yet easily based on the draft. > [MT] We have now included detailed examples in Sections 3.1 (Request) and Section 3.2 (Response). > =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Normally, for ap= plications (e.g. Building automation and > lighting) groups do need a stable and non-random group ID, that > identifies the group over time even as changes occur, e.g. members > added/removed. The =E2=80=9CGid=E2=80=9D in the draft however changes. = There could be > some text added to explain how Gid is linked to a stable ID. E.g., > this could be configured by the Group Manager. The stable group ID is > then not used over-the-wire for multicast OSCORE. > [MT] It is true that the Gid in this draft changes over time, especially upon renewing the group keying material, and the Group Manager is the only responsible for managing its value update. However, this Gid has to be intended as the identifier of the OSCORE =E2=80=9Csecurity group=E2=80= =9D, including as members the endpoints that share the same Common Security Context. [MT] As you say, applications do rely on a stable and non-random group ID, which is not used over-the-wire for group OSCORE, and instead identifies an =E2=80=9Capplication group=E2=80=9D having as members the e= ndpoints that participate in a same group application. There is no relation between this application-level group ID and the OSCORE Gid defined in this draft. However, one may possibly map multiple =E2=80=9Capplication groups= =E2=80=9D to the same =E2=80=9Csecurity group=E2=80=9D. [MT] In order to clarify this point, we included also a definition of =E2=80=9CGroup=E2=80=9D and =E2=80=9CGroup ID=E2=80=9D in Section 1.1. > =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is normati= ve text in the Appendices; it could be > clarified what the status of this is. E.g. only normative if one > chooses to implement the optional element described in the Appendix?I > have a preference for avoiding normative text in the Appendices, but > I=E2=80=99m curious to hear what others think. > [MT] We relaxed the text in Appendices to avoid normative references, with the exception of a =E2=80=9CNOT RECOMMENDED=E2=80=9D in current Appe= ndix F =E2=80=9CNo Verification of Signatures=E2=80=9D. > =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The text sometim= es suggests that a secure group context is > linked to one and only one multicast IP address. In practice, there > may be more variety =E2=80=93 e.g. one multicast IP address plus one or= more > unicast IP addresses to which the group message is subsequently > delivered. E.g. repeat of the group message to members which did not > get it yet. The proposed solution could be reviewed with that view in > mind, that there may be multiple (multicast/unicast) IP destination > addresses to which a group message will be sent. I did not do that > yet; can do so in a future in-depth review. > [MT] Thanks, that=E2=80=99s a very good comment. We=E2=80=99ll think more= on the possible view you propose. It should be fine as long as a recipient is able to retrieve the right group Security Context, by using the Gid. > =C2=A0 > > Section 2.1 > > Some things here are listed as out of scope, but they do come back > later in the doc =E2=80=93 such as forward security and backward securi= ty , > which are addressed I think =E2=80=93 certainly not out of scope. > [MT] Group OSCORE does not ensure forward security and backward security itself. Instead, they are entrusted to the specifying group rekeying protocol enforced by the Group Manager. The specific rekeying protocol if out of scope for Group OSCORE, which however recommends the use of one able to ensure backward and forward security in the group. > =C2=A0 > > Section 3 > > " Gid MUST be random " -> seems to contradict Appendix B which uses an > Epoch counter in the Gid.=C2=A0 Should it say =E2=80=9CMUST have a rand= om component=E2=80=9D ? > [MT] Right, now fixed (in current Appendix C). > =C2=A0 > > Appendices > > * Appendix B, a concrete example instance is missing. E.g. > =E2=80=9Cw3fj90f0a_0042=E2=80=9D or its bstr equivalent=C2=A0 (just= guessing here to > the format) > [MT] We added an example, in current Appendix C. > * > > > > * Appendix C, is this an example blueprint of how to do it =E2=80=93 = fully > optional to follow or not follow this? > [MT] We relaxed the text in current Appendix D, as for the time being it is intended to be a guideline example. > * > > =C2=A0 > > Minor > > * ligthing -> lighting > * enpoint=C2=A0 -> endpoint > * Pg 25 , [I-D.ietf-ace-dtls-authorize] reference breaks across line > and as such becomes non-searchable in the browser. And I like > these refs to be searchable =F0=9F=98=89 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > *From:* core [mailto:core-bounces@ietf.org] *On Behalf Of *Jaime Jim=C3= =A9nez > *Sent:* Thursday, November 23, 2017 17:59 > *To:* core@ietf.org WG (core@ietf.org) > *Cc:* ji-ye.park@uni-due.de > *Subject:* [core] =F0=9F=94=94 WG Call for Adoption on > draft-tiloca-core-multicast-oscoap > > =C2=A0 > > Dear all, > > =C2=A0 > > The draft on "Secure group communication for CoAP" > (=C2=A0draft-tiloca-core-multicast-oscoap > =C2=A0= ) > had in room consensus for adoption during IETF99 already, now we are > clear to confirm it on the mailing list.=C2=A0 > > =C2=A0 > > Please reply to the list with your comments, including although > not=C2=A0limited to whether=C2=A0or not you support adoption. Non-autho= rs are > especially=C2=A0encouraged to comment. > > =C2=A0 > > Target to end the WGA is 14th of December. > > =C2=A0 > > Ciao, > > - - Jaime Jim=C3=A9nez > > =C2=A0 > > > -----------------------------------------------------------------------= - > The information contained in this email may be confidential and/or > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this email is strictly prohibited and may be unlawful. > If you are not the intended recipient, please contact the sender by > return e-mail and destroy all copies of the original email. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. --------------0BCDE1B4B39BA01EE5896B24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
Hello Esko,

Thanks for your support and comments, we have considered them=
 when producing the latest version of the  draft [1].

Please, find in line some answers to your comments.

Best,
/Marco

[1] https://tools.ietf.org=
/html/draft-ietf-core-oscore-groupcomm-01

On 2017-12-04 14:35, Esko Dijk wrote:<= br>

I also support the adoption of this draft as a work item for CoRE. Below are the results of a quick review, also.

=C2=A0

Best regards

Esko Dijk

=C2=A0

=C2=A0

Overall comments =E2=80=93 or work that th= e WG could take up next

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Detailed example with message sizes would be useful. Since it=E2=80=99s important for= multicast over 6lowpan performance that the IPv6 packets stay small enough (one 802.15.4 frame). At this moment, I can=E2=80=99= t judge that yet easily based on the draft.


[MT] We have now included detailed examples in Sections 3.1 (Request) and Section 3.2 (Response).


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Normally, for applications (e.g. Building automation and lighting) groups do need a stable and non-random group ID, that identifies the group over time even as changes occur, e.g. members added/removed. The =E2=80=9CGid=E2=80=9D in the draft however c= hanges. There could be some text added to explain how Gid is linked to a stable ID. E.g., this could be configured by the Group Manager. The stable group ID is then not used over-the-wire for multicast OSCORE.


[MT] It is true that the Gid in this draft changes over time, especially upon renewing the group keying material, and the Group Manager is the only responsible for managing its value update. However, this Gid has to be intended as the identifier of the OSCORE =E2=80=9Csecurit= y group=E2=80=9D, including as members the endpoints that share the same Common Security Context.

[MT] As you say, applications do rely on a stable and non-random group ID, which is not used over-the-wire for group OSCORE, and instead identifies an =E2=80=9Capplication group=E2=80=9D having as mem= bers the endpoints that participate in a same group application. There is no relation between this application-level group ID and the OSCORE Gid defined in this draft. However, one may possibly map multiple =E2=80=9Capplication groups=E2=80=9D to the same =E2=80=9Csecurity group=E2=80=9D.

[MT] In order to clarify this point, we included also a definition of =E2=80=9CGroup=E2=80=9D and =E2=80=9CGroup ID=E2=80=9D in Secti= on 1.1.


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 There is normative text in the Appendices; it could be clarified what the status of this is. E.g. only normative if one chooses to implement the optional element described in the Appendix?I have a preference for avoiding normative text in the Appendices, but I=E2=80=99m = curious to hear what others think.


[MT] We relaxed the text in Appendices to avoid normative references, with the exception of a =E2=80=9CNOT RECOMMENDED=E2=80=9D in current A= ppendix F =E2=80=9CNo Verification of Signatures=E2=80=9D.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 The text sometimes suggests that a secure group context is linked to one and only one multicast IP address. In practice, there may be more variety =E2=80=93 e.g. one multicast IP address plus one or mor= e unicast IP addresses to which the group message is subsequently delivered. E.g. repeat of the group message to members which did not get it yet. The proposed solution could be reviewed with that view in mind, that there may be multiple (multicast/unicast) IP destination addresses to which a group message will be sent. I did not do that yet; can do so in a future in-depth review.


[MT] Thanks, that=E2=80=99s a very good comment. We=E2=80=99ll think= more on the possible view you propose. It should be fine as long as a recipient is able to retrieve the right group Security Context, by using the Gid.


=C2=A0

Section 2.1

Some things here are listed as out of scope, but they do come back later in the doc =E2=80=93 such as= forward security and backward security , which are addressed I think =E2=80=93 certainly not out of scope.


[MT] Group OSCORE does not ensure forward security and backward security itself. Instead, they are entrusted to the specifying group rekeying protocol enforced by the Group Manager. The specific rekeying protocol if out of scope for Group OSCORE, which however recommends the use of one able to ensure backward and forward security in the group.


=C2=A0

Section 3

" Gid MUST be random " -> seems to contradict Appendix B which uses an Epoch counter in the Gid.=C2= =A0 Should it say =E2=80=9CMUST have a random component=E2=80=9D ?<= /p>


[MT] Right, now fixed (in current Appendix C).


=C2=A0

Appendices

  • Appendix B, a concrete example instance is missing. E.g. =E2=80=9Cw3fj90f0a_0042=E2=80=9D or its bstr equivalent=C2=A0= (just guessing here to the format)

[MT] We added an example, in current Appendix C.



  • Appendix C, is this an example blueprint of how to do it =E2=80=93 fully optional to follow = or not follow this?

[MT] We relaxed the text in current Appendix D, as for the time being it is intended to be a guideline example.


=C2=A0

Minor

  • ligthing -> lighting
  • enpoint=C2=A0= -> endpoint
  • Pg 25 , [I-D.ietf-ace-dtls-authorize] reference breaks across line and as such becomes non-searchable in the browser. And I like these refs to be searchable =F0=9F=98=89
    • =

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: core [mailto:core-bounces@ietf.org] On Behalf Of Jaime Jim=C3=A9nez
Sent: Thursday, November 23, 2017 17:59
To: core@ietf.org WG (core@ietf.org) <core@ietf.org>
Cc: ji-ye.park@uni-due.de
Subject: [core] =F0=9F=94=94 WG Call for A= doption on draft-tiloca-core-multicast-oscoap

=C2=A0

Dear all,

=C2=A0

The draft on "Secure group communication= for CoAP" (=C2=A0draft-tiloca-core-multicast-oscoap= =C2=A0) had in room consensus for adoption during IETF99 already, now we are clear to confirm it on the mailing list.=C2=A0

=C2=A0

Please reply to the list with your comments, including although not=C2=A0limited to whether=C2= =A0or not you support adoption. Non-authors are especially=C2=A0encouraged to comment.

=C2=A0

Target to end the WGA is 14th of December.

=C2=A0

Ciao,

- - Ja= ime Jim=C3=A9nez

=C2=A0


The information cont= ained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.
 

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


--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://w=
ww.sics.se

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.
--------------0BCDE1B4B39BA01EE5896B24-- --OANRdThn9Qyz1bndRcKQ4x2XgxbIZ54DO-- --8FUbQ422YuUNv6I4Dqs6pOXgoVycUeEwB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJancIoAAoJEO4mZLQOWNpDMSIIALU0eAV9ZyJEDlxbftUxBo2O rx7bBjDoIh0I8tenRuv3DbjYn2EajekeAYhaF8gp76gRvRjYBo9SVfmvTYOX65Wq WJuaxiE6kHO19YD4xaqhK8IdwGXdrcWft2QqVjA+x0HAu6zv7fZNP3mSB38JNKmK +dOOy+mSjHjV3DfcSOcw1j6QOlXmeZvB/LHpUswgcvCUmfPl3n7HEZ+i3BWi7rA6 aPj4xiaaZAzKPirSCQF0cQNC61fvtJbiVnFBF8L9q+XWIleiQ47a/pl1MjkN5Lhq twQH3hx4cXXCCM5RubH9LImWkrNydoaJO4LwdaSE6hiua1KAcx+Hhe5/qFxAfWI= =n/91 -----END PGP SIGNATURE----- --8FUbQ422YuUNv6I4Dqs6pOXgoVycUeEwB-- From nobody Mon Mar 5 14:20:06 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B094312EAB0; Mon, 5 Mar 2018 14:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 X42Gd3PJujwu; Mon, 5 Mar 2018 14:19:55 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E270812E9DD; Mon, 5 Mar 2018 14:19:49 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1750849535; Mon, 5 Mar 2018 23:19:47 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6164D61; Mon, 5 Mar 2018 23:19:46 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2F5215E; Mon, 5 Mar 2018 23:19:46 +0100 (CET) Received: (nullmailer pid 9182 invoked by uid 1000); Mon, 05 Mar 2018 22:19:45 -0000 Date: Mon, 5 Mar 2018 23:19:45 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-block@ietf.org Cc: Core WG mailing list Message-ID: <20180305221945.GA25693@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: [core] Strictness of RFC7959 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 22:20:05 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello block-wise authors, hello CoRE, I am uncertain about the behavior RFC7959 actually prescribes to servers: How liberal is it for servers about which blocks can be acted on together (or when to send 4.08 Request Entity Incomplete)? The last paragraph of section 2.4 implies that the Cache-Key[1] is what messages are grouped by (which makes sense and would make the specification of Request-Tag much shorter), but nowhere else is the cache key mentioned in the document. What is the expected behavior of a server (or let's say proxy, as the proxy needs to do block-wise too but doesn't need to know elective options) in presence of similar-but-not-quite-alike messages from the same source that could be a blockwise operation? Group by URI? By Cach-Key? By all options unless it knows it's irrelevant from the option's description? May the server choose depending on the application? And can I rely on that behavior in echo-request-tag? Best regards Christian [1]: Actually Cache-Key without request body after RFC7252 errata, as that body is not represented in Block2 phase when combining. --=20 Reflection. Surprise. Terror. For the future. -- Kosh --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqdwn0ACgkQOY0REtOk veFx3Q/9EePUQ4rxCDWdKTMjYAvHSP5ANPIl+TjsCo/6QE3sFG1lZpRlexP1GTdv 5Nkko7GkEKHFDgKWhizORI8s0WeGBXKYm6mxWuHLJexJdeujg0kar0gTZSGY3jqO oBqKOWaHlkFLAC+MFdfSdbCE/YI9sUhqysJqsoS6kc07wTQ0/1+eDHaQrClj0Dod 0E6HKVyrpIp9BCIdLNDyr3BlXNHURQAZr/p4C3ahOjZLr00wA/B4acHU5Sk9bkxf IoLQKgph6eU7xRiWTzHb5ygibKN3oX4FhNSymUkRw7U5S9PZQxPfcwXprBGE8H+J qWujjc3x8eWrfMkwBofY2qtO7adQomIgVQe/CU8ZBUTgyXS7urHRfmUyH1pdtdGx DohlxuPsrQ0UD5L6UqEdMxamcpFEUlr4Iq9lunsQmW/lVFE5ReIUTgESOUVPqABF VWkrm2Qi1ppOv3TTBH/zJjbujuQ3Z+1/3MoajUtC2QXv9W+FEHDBy1yTIl6yhj5i IC7l/sM0s0bFx2bfUy/y9f7Vo70tpxcSf8tH3Z5xbTFqLVurxtF7Wes43j18lgND ZS+sGLg42l11/spagRc5QlMxbRKxjfk9RTRlNHwcMEm9lpVZ5JIM1jhvN2rk0n8Z LYxI/SqVftMQP/eRr5i8/7MgVcOG2Vuzd+pQM699qJ2Gcw7SFTw= =hugC -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From nobody Mon Mar 5 14:21:18 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B681126DD9 for ; Mon, 5 Mar 2018 14:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 G1k79qpXCm2u for ; Mon, 5 Mar 2018 14:21:15 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF41126DC2 for ; Mon, 5 Mar 2018 14:21:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8A315660254 for ; Tue, 6 Mar 2018 00:21:14 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lJoVhd7uGWZ for ; Tue, 6 Mar 2018 00:21:13 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 4CA93660182 for ; Tue, 6 Mar 2018 00:21:13 +0200 (EET) From: Jari Arkko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: References: <152026025653.14608.1120615633883487426.idtracker@ietfa.amsl.com> To: Core Date: Tue, 6 Mar 2018 00:21:12 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Fwd: New Version Notification for draft-ietf-core-dev-urn-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 22:21:16 -0000 FYI >=20 > Name: draft-ietf-core-dev-urn > Revision: 00 > Title: Uniform Resource Names for Device Identifiers > Document date: 2018-03-05 > Group: core > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-core-dev-urn-00.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ > Htmlized: https://tools.ietf.org/html/draft-ietf-core-dev-urn-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-00 >=20 >=20 > Abstract: > This memo describes a new Uniform Resource Name (URN) namespace for > hardware device identifiers. A general representation of device > identity can be useful in many applications, such as in sensor data > streams and storage, or equipment inventories. A URN-based > representation can be easily passed along in any application that > needs the information. From nobody Mon Mar 5 14:58:39 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D831275AB for ; Mon, 5 Mar 2018 14:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 htj_Oc5nXr0y for ; Mon, 5 Mar 2018 14:58:30 -0800 (PST) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F99C12711E for ; Mon, 5 Mar 2018 14:58:29 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 17994221FCD; Mon, 5 Mar 2018 22:58:29 +0000 (UTC) Received: from [192.168.0.65] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 5 Mar 2018 23:58:26 +0100 To: , Core References: From: Marco Tiloca Message-ID: <1226ef9a-c95d-42c4-4bd0-b59c64135dde@ri.se> Date: Mon, 5 Mar 2018 23:58:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VBNPWHlO6sy7A9jH9bZMVjIJjjLQsM45u" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=v2DPQv5-lfwA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=xPT6tdSuAAAA:8 a=gf6o5gKAHCQBkT3G5IUA:9 a=3EBF0hqEJpPGorfV:21 a=K1HI0-BMohcEc9dS:21 a=QEXdDO2ut3YA:10 a=PkKVtKu-3bODk5XFDMMA:9 a=mSqDSMiuFR75rgdb:21 a=8ht8O83RjKfo48HU:21 a=fQz2Tac5qV1fLKqh:21 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=mBr-oMQauN9WSH-0ONEA:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=80PJfYVSYmV_jLpvUEnt:22 X-Virus-Scanned: clamav-milter 0.99.3 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [core] tiloca-core-muticast-oscoap-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Mar 2018 22:58:38 -0000 --VBNPWHlO6sy7A9jH9bZMVjIJjjLQsM45u Content-Type: multipart/mixed; boundary="XiXnheOWeZ8MXzNXEGpfH8MAFtby07kJF"; protected-headers="v1" From: Marco Tiloca To: consultancy@vanderstok.org, Core Message-ID: <1226ef9a-c95d-42c4-4bd0-b59c64135dde@ri.se> Subject: Re: [core] tiloca-core-muticast-oscoap-4 References: In-Reply-To: --XiXnheOWeZ8MXzNXEGpfH8MAFtby07kJF Content-Type: multipart/alternative; boundary="------------5AA319B466C4EB100BE4E0EF" Content-Language: en-US This is a multi-part message in MIME format. --------------5AA319B466C4EB100BE4E0EF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Peter, Thank you for your review and comments. Please, find some answers in line= =2E We took into account your comments for producing the latest version of the draft [1]. Please, find some answers in line. Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-01 On 2018-02-06 12:04, peter van der Stok wrote: > Hi authors, > > Many thanks for this very useful document. Below some comments. These > are mainly restricted to document structure, relation to other > documents, and new concepts and terminology. I hope they are > sufficiently clear and help improving the text. > > Peter > > Abstract: > I did not see text that validates the phrase: > =E2=80=9CAll security requirements fulfilled by OSCORE are > maintained for multicast OSCORE request messages and related OSCORE > response messages.=E2=80=9D > I did see: this document specifies the parameter values for OSCORE > messages applied to group communication. [MT] Now rephrased as: =E2=80=9CIn particular, it is defined how OSCORE s= hould be used in a group communication setting, while fulfilling the same security requirements for request messages and related response message.=E2= =80=9D > Why is source authentication more important (mentioned separately) > than all other security aspects of OCORE? > [MT] In the main OSCORE specification, one hassource authentication among two parties directly from the usage of the AEAD. Instead, in the group communication setting considered bygroup OSCORE, the Common Context is sufficient to ensure group authentication, while the same components alone are not sufficient to achieve source authentication too. This is the reason why we additionally introduce countersignatures trough each individual endpoint's private key, and why we present source-authentication as a specific requirement to be =E2=80=9Cbrought ba= ck again=E2=80=9D. > Introduction: > Benefit from a group communication model: A possible group > communication model is the use of unicast for all individual > destinations; I don=E2=80=99t see how this increases efficiency. May-be= you > mean: leveraging the broadcast model of the underlying communication > medium? [MT] Yes, that's right, however this should already come from RFC7390. The advantage from the underlying communication model is limited to requests. > Across intermediary nodes -> possibly involving intermediary nodes. [MT] Done. > The phrase: =E2=80=9CTo this end, =E2=80=A6. protected message=E2=80=9D= is funny. I did not > know that you could protect messages by including payload (something > went wrong in this phrase). [MT] We rephrased as =E2=80=9CTo this end, a CoAP message is protected by= including its payload (if any), certain options, and header fields in a COSE object, which finally replaces the authenticated and encrypted fields in the protected message.=E2=80=9D > Remove: =E2=80=9Cwhile fulfilling the same security requirements=E2=80=9D= =2E My > suggestion: end-to-end security is assured by using the same security > technology as for OSCORE. [MT] As aligned with the main OSCORE document, we rephrased as =E2=80=9Cs= o that end-to-end security is assured by using the same security method=E2=80=9D= =2E > The OSCORE draft mentions: > =E2=80=9Cproviding end-to-end encryption, integrity, replay protection,= and > secure the binding of response to request=E2=80=9D. It does not mention= source > authentication explicitly. So, why is multicast-oscoap different? [MT] In OSCORE, one hassource authentication among two parties directly from the usage of the AEAD. Instead, in the group communication setting considered by group OSCORE, the Common Context is sufficient to ensure group authentication, while the same components alone are not sufficient to achieve source authentication too. This is the reason why we additionally introduce countersignatures trough each individual endpoint's private key, and why we present source-authentication as a specific requirement to be =E2=80=9Cbrought back again=E2=80=9D. > > Section 1.1 > Multicaster: Is M <=3D N? [MT] Not necessarily. > sub-question is: are the destinations always all group members and is > the source also a destination? [MT] Destinations are always group members, while a source is not necessarily a destination, it depends on the role(s) in the group. For example, an endpoint configured only as multicaster will be only-source in a group where all the other members are configured as pure listeners. > May be you should refer to section 2.2 which provides a better > explanation. [MT] Section 2.2 has now become Appendix A.2, in order to have the document body more in synch with the main OSCORE document. Which portion(s) of Appendix A.2 do you think it is better to point at? > > Endpoint ID: why this exclusion of pure listeners? It complicates the > protocol. [MT] This was previously discussed with Jim, as a group member configured _only_ as pure listener does not need to receive upon join (and thereafter store) an Endpoint ID. In fact, that endpoint is never going to transmit group messages where including its own Endpoint ID as Sender ID. > Remove: =E2=80=9CThat is, =E2=80=A6. same time=E2=80=9D. Does not clari= fy uniqueness. [MT] Done. > > Section 2. > I do understand the purpose of section 2.2, but not of section 2.1. As > far as I understand the Group Manager is essential for secure group > communication as specified here; No GM means no group communication > (is that correct?) In that case I would suggest two other subsections. [MT] =E2=80=9CNo GM means no group communication=E2=80=9D is essentially = correct in this context, as there would be no provisioning of keying material to joining endpoints. To be more precise, with no GM: i) group membership has to be static; and ii) all key provisioning has to be done once and for all before deployment through other means. > Section 2.1a Requirements on group manager, section 2.1b, Protocol > characteristics. [MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager (that is, your proposed Section 2.1a). Instead, your proposed Section 2.1b is essentially the current Appendix A. This was driven by having the document body more in synch with the main OSCORE document. > > Multicast communication topology: remove the lighting use case, and > refer to appendix. [MT] Done. > Multicast group size: is this the number of members? The fact that a > member may be listener as well as multicaster is another aspect and > not relevant to size. The numbers are interesting to guide implementers= =2E [MT] We now put less stress on the roles of group members, but we would anyway keep the roles related to the indicative numbers provided, i.e. =E2=80=9C=E2=80=A6 The group size is the current number of members in a m= ulticast group. In the use cases mentioned in this document, the number of multicasters (normally the controlling devices) is expected to be much smaller than the number of listeners (i.e. the controlled devices). A security solution for group communication that supports 1 to 50 multicasters would be able to properly cover the group sizes required for most use cases that are relevant for this document =E2=80=A6=E2=80=9D. > > Establishment and Management of Security context: I recommend to > mention relation to OSCORE security contexts. [MT] Done. > Actually, the text seems to discuss requirements on the GM. GM > specification is out of scope but not any GM design can be used with > oscoap-multicast. [MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager. Do you think any particular additional requirement/responsibility on the Group Manager is missing? [MT] Note that the Group Manager is not expected to necessarily be an actual member of the group. That is, it needs to generate/manage/provide OSCORE Contexts upon joining and to renew Common Contexts within the group, but it is not required to communicate _by means of_group OSCORE itself. > > Multicast data security Cipher suite: GM requirement?? [MT] I would not say so. The Group Manager indicates keying material and security parameters to new endpoints during the join process (see current Section 6 and current Appendix D), specifying also the security Cipher Suite to use in the group. However, the Group Manager is not required to use such Cipher Suite itself, unless it is also an actual group member. > > Backward security: GM requirement? [MT] This is actually a requirement of the group rekeying scheme used by the GM to manage the group keying material. So I would not say it is a GM requirement. > Actually, this poses the question of ordering of messages from > different sources; Is there a total ordering of messages or only a > partial source order? (I see this is explained in section 2.2) May be > a forward reference? [MT] At the beginning of current Section 4, we now list the security objectives fulfilled by group OSCORE, and point at current Appendix A.2 for further details. > > Forward security: GM requirement? [MT] This is actually a requirement of the group rekeying scheme used by the GM to manage the group keying material. So I would not say it is a GM requirement. > > Section 2.2 security Objectives > Bullet 2; remove =E2=80=9CIn fact, =E2=80=A6plaintext=E2=80=9D ; does n= ot add much [MT] Done. > Bullet 3: shall be authenticated with respect to two sources (sender > and group) (simultaneously?) [MT] We have group authentication already from the usage of the AEAD, plus source authentication through the countersignature. Do you think we should have source authentication as aseparate bullet? > > Section 3; > Suggestion: Each endpoint stores extensions of the Oscore context. I > seem to read that the Contexts used for group communication are > extensions to the one specified for OSCORE. If that is true, use > different names or use extension of . > Common context -> group context? In OSCORE the common context is > defined as common between send and receiver, not common to the group. [MT] We actually need both =E2=80=9CCommon context=E2=80=9D and =E2=80=9C= Group Context=E2=80=9D, as different concepts. In each endpoint, =E2=80=9CGroup Context=E2=80=9D is = what you would implicitly define as =E2=80=9Cpair context=E2=80=9D in OSCORE, and it sim= ilarly includes a =E2=80=9CCommon context=E2=80=9D, a =E2=80=9CSender context=E2=80=9D an= d _multiple_ (unlike OSCORE) =E2=80=9CRecipient contexts=E2=80=9D, all of which with additional elemen= ts with respect to their equivalent in OSCORE. > Point 1, bullet 2: =E2=80=9C =E2=80=A6 once the security context is est= ablished=E2=80=9D: do > you mean the common context? [MT] Yes, now clarified. > Point 2, The phrase =E2=80=9CIn practice,=C2=A0 =E2=80=A6 OSCORE messag= es=E2=80=9D is difficult to > understand (at least I see multiple explanations) [MT] We have rephrased as: =E2=80=9CIn practice, the symmetric keying mat= erial in the Sender Context of the sender endpoint is shared with all the recipient endpoints that have received group messages from that same sender endpoint.=E2=80=9D [MT] Also, we have similarly rephrased the related sentence in the paragraph below about the Recipient Context, i.e.: =E2=80=9CIn practice, = the symmetric keying material in a given Recipient Context of the recipient endpoint is shared with the associated sender endpoint from which group messages are received=E2=80=9D. > Do you mean that SenderID is equal to its endpointID received at joinin= g? [MT] Yes, we have clarified it in the definition of Endpoint ID in Section 1.1. > It would be nice to give tables with additions to OSCORE security > context for Sender Context, Recipient Context and Common (group) > context; Now one has to search for them in the text. [MT] Done. > Point 3 Is Recipient Id also equal to endpointID. The text about > Recipient context creation is unclear. Is the creation done by the > Recipient endpoint? How are the contexts shared? Who does the sharing? > Or do you mean that they are copied over at reception? > Sender pubic key is extracted from Sender context (stored in GM, or > sent over with message?) or from a trusted key repository? This > paragraph is not very clear to me. Parts of the text are good > candidates for a GM requirements section. See my comments about > appendix C. [MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager. [MT] As to the other points: - Like in OSCORE, the Recipient ID is the Endpoint ID of a sender endpoint _from the perspective of the recipient endpoint_. - Yes, the creation of a Recipient Context is done by the recipient endpoint upon the reception of a first message from the corresponding other endpoint acting as sender endpoint. Now it is stated explicitly, and followed by a pointer to current Sections4.2 and 4.4about processing incoming messages. - The sender's public key has to be retrieved anyway from a trusted key repository, using the Endpoint ID of such sender endpoint. As a possible configuration (see current Appendix D.2), the Group Manager can be configured to act as trusted key repository. This is also mentioned as an optional task of the Group Manager in the current Section 6. > > Section 3.1 Remove: =E2=80=9Csuch a risk=E2=80=A6 office buildings. Nev= ertheless=E2=80=9D. The > fun with drones provided by Dutch universities, proves these > assumptions to be futile. [MT] Done. > > Distribution of master key is another GM requirement. [MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager. The Group Manager distributes the OSCORE Master Secret as part of the Security Common Context. > > Section 4 bullit 1: The phrase =E2=80=9Cset to the SenderId of the endp= oint=E2=80=9D > creates the impression that an endpoint has multiple IDs. Probably, > you mean:=C2=A0 the SenderId of the Context is set to the ID of the > endpoint (or similar much better text) [MT] The Sender ID is related to the endpoint, which has indeed a single one stored in its own Sender Context, but not to the Context. We rephrased as =E2=80=9Cset to the Endpoint ID of the endpoint transmitting= the message, i.e. the Sender ID=E2=80=9D. > Bullit 2 star 1: Is the group=E2=80=99s Security Context equal to the C= ommon=C2=A0 > context? [MT] No, and we actually need both =E2=80=9CCommon context=E2=80=9D and =E2= =80=9CGroup Context=E2=80=9D, as different concepts. In each endpoint, =E2=80=9CGroup Context=E2=80=9D = is what you would implicitly define as =E2=80=9Cpair context=E2=80=9D in OSCORE, and = it similarly includes a =E2=80=9CCommon context=E2=80=9D, a =E2=80=9CSender context=E2= =80=9D and _multiple_ (unlike OSCORE) =E2=80=9CRecipient contexts=E2=80=9D, all of which with additiona= l elements with respect to their equivalent in OSCORE. > > Figure 1 differs from figure 7 in OSCORE draft [MT] Figure 1 actually is related to Figure 8 in the OSCORE draft. > > Section 5; Suggestion: In case of malformed messages a =E2=80=9Clisteni= ng > only=E2=80=9D receiver endpoint silently rejects the message and sends = no > error message; all other receivers return an error message x.xx. [MT] The current text was the result of a discussion with Jim at IETF99, to avoid congesting the group. Perhaps we can rephrase the current text as a possible conservative behavior, while adding what you suggest especially in case of groups that are small or hard to congest. > > Section 5.1 > The document uses two terms: multicaster endpoint and sender endpoint; > I assume they are equal concepts; If yes, choose one, if no, explain > difference. [MT] The definition of =E2=80=9CMulticaster=E2=80=9D is provided in Secti= on 1.1, and it refers to an endpoint acting as =E2=80=9CSender=E2=80=9D when transmittin= g group requests and =E2=80=9CRecipient=E2=80=9D when receiving responses. On the= other hand, a sender can be a multicaster sending a group request or as well a listener sending a response. The concepts of =E2=80=9CSender=E2=80=9D and= =E2=80=9CRecipient=E2=80=9D as such as inherited from the main OSCORE document. > > Point 1; stores where? Find where? [MT] I am not sure we should provide similar details here. Not even OSCORE specifies this in its Section 8.1, point 6. > > Section 5.2 point 2; It is not clear how a new Recipient context is > created; That is probably due to the vague duties of the GM. [MT] It is created just like in OSCORE, plus the inclusion of the sender endpoint's public key to be separately retrieved. > > Section 6; I think that synchronizing sequence numbers is part of the > standard and should be specified as requirement on the GM. [MT] The GM is expected to indicate to a joining endpoint the approach to follow. So, specifying the approach to use can be seen as a GM requirement, rather than enforcing that approach in the group itself. This is now also part of the GM's responsibilities listed in current Section 6. > > > Section 7.1=C2=A0 Remove =E2=80=9Cfor instance .. those roles=E2=80=9D = Refer to appendix A. [MT] Done (now Appendix B). > > Section 7; Don=E2=80=99t you need some discussion on size of group to d= iscuss > security breach probabilities? [MT] That's something more we can add. Input are welcome. > > Appendix A > lighting control; here you refer to multicast group, which is > sometimes correct. In the introduction you talk about group communicati= on. [MT] A group displays group communication including delivery of multicast messages (requests) together with unicast messages (responses). We have revised the document and simply refer to =E2=80=9Cgr= oup=E2=80=9D now. > Switches but also sensors can control the state of the lights. Why is > the backbone multicast enabled? Is that a MUST? [MT] That can be relaxed, as long as IP packets having a multicast destination address are correctly delivered all the way to the border routers acting as entry points. > Events within a 200 ms interval are perceived as simultaneous by > humans. Necessary in many configurations. [MT] Ok, now mentioned. > > In Building control, intervals of seconds are sufficient. > [MT] Ok, now mentioned. > Commissioning of LLN system; Interesting idea that multicast should be > enabled on a subnetwork for discovery. However, that would be after > enrollment of the devices? I think the use case needs a bit more though= t. [MT] Agree, we can think more about it and collect input. > > Emergency multicast; Also interesting, but that needs a fault tolerant > multicast algorithm, like MPL. for example. [MT] Ok, now mentioned. > > Appendix C. I like this appendix, it provides the necessary > understanding how things will work in practice. Please keep this > appendix but also create a section with GM requirements, with the > purpose of the requirements explained in the appendix. (this is a > suggestion, don=E2=80=99t know if it will work actually) [MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager. > > C.1=C2=A0 bullit management keying material: depend -> depends [MT] I think that =E2=80=9Cdepend=E2=80=9D is correct. The subject is =E2= =80=9Celements=E2=80=9D. > > C.3 I think the utilization of ACE framework SHOULD be part of the > standard. Too many options reduce the interoperability. Especially > standards about the GM seem rather crucial to me. [MT] This is something we can further discuss in the WG. I personally support your view, while for the time being the ACE-based approach in current Appendix D.3 is seen as a possible incarnation of the more generic description in current Appendix D.1. It might be good to still leave room for alternative join approaches that are not based on ACE, as long as they correctly initialize new endpoints upon joining the group. > > Appendix D. Are the proposed options interoperable within a group? > Also here I would advocate interoperable solutions only. [MT] Yes, they are. Upon joining, the Group Manager can possibly mention the synchronization policy to follow on a per-endpoint basis (see current Section 5 introducing this aspect at a high-level). > > --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. --------------5AA319B466C4EB100BE4E0EF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
Hello Peter,

Thank you for your review and comments. Please, find some ans=
wers in line.

We took into account your comments for producing the latest v=
ersion of the  draft [1]. Please, find some answers in line.

Best,
/Marco

[1] https://tools.ietf.org=
/html/draft-ietf-core-oscore-groupcomm-01

On 2018-02-06 12:04, peter van der Sto= k wrote:
Hi authors,=

Many thanks for this very useful document. Below some comments. These are mainly restricted to document structure, relation to other documents, and new concepts and terminology. I hope they are sufficiently clear and help improving the text.

Peter

Abstract:
I did not see text that validates the phrase:
=E2=80=9CAll security requirements fulfilled by OSCORE are
maintained for multicast OSCORE request messages and related OSCORE
response messages.=E2=80=9D
I did see: this document specifies the parameter values for OSCORE messages applied to group communication.

[MT] Now rephrased as: =E2=80=9CIn particular, it is defined how OSC= ORE should be used in a group communication setting, while fulfilling the same security requirements for request messages and related response message.=E2=80=9D


Why is source authentication more important (mentioned separately) than all other security aspects of OCORE?


[MT] In the main OSCORE specification, one has source authentication among two parties directly from the usage of th= e AEAD. Instead, in the grou= p communication sett= ing considered by grou= p OSCORE, the Common Context is sufficient to ensure group authentication, while the same components alone are not sufficient to achieve source authentication too. This is the reason why we additionally introduce countersignatures trough each individual endpoint's private key, and why we present source-authentication as a specific requirement to be =E2=80=9Cbrought back again=E2=80=9D.

Introductio= n:
Benefit from a group communication model: A possible group communication model is the use of unicast for all individual destinations; I don=E2=80=99t see how this increases efficiency. Ma= y-be you mean: leveraging the broadcast model of the underlying communication medium?

[MT] Yes, that's right, however this should already come from RFC7390. The advantage from the underlying communication model is limited to requests.


Across intermediary nodes -> possibly involving intermediary nodes.
=


[MT] Done.


The phrase:= =E2=80=9CTo this end, =E2=80=A6. protected message=E2=80=9D is funn= y. I did not know that you could protect messages by including payload (something went wrong in this phrase).

[MT] We rephrased as =E2=80=9CTo this end, a CoAP message is prote= cted by including its payload (if any), certain options, and header fields in a COSE object, which finally replaces the authenticated and encrypted fields in the protected message.=E2=80=9D


Remove: =E2=80=9Cwhile fulfilling the same security requirements=E2=80=9D. = My suggestion: end-to-end security is assured by using the same security technology as for OSCORE.

[MT] As aligned with the main OSCORE document, we rephrased as =E2=80= =9Cso that end-to-end security is assured by using the same security method=E2=80=9D.


The OSCORE draft mentions:
=E2=80=9Cproviding end-to-end encryption, integrity, replay protect= ion, and
secure the binding of response to request=E2=80=9D. It does not men= tion source authentication explicitly. So, why is multicast-oscoap different?

[MT] In OSCORE, one has source authentication among two parties directly from the usage of th= e AEAD. Instead, in the grou= p communication sett= ing considered by grou= p OSCORE, the Common Context is sufficient to ensure group authentication, while the same components alone are not sufficient to achieve source authentication too. This is the reason why we additionally introduce countersignatures trough each individual endpoint's private key, and why we present source-authentication as a specific requirement to be =E2=80=9Cbrought back again=E2=80=9D.


Section 1.1
Multicaster: Is M <=3D N?

[MT] Not necessarily.


sub-questio= n is: are the destinations always all group members and is the source also a destination?


[MT] Destinations are always group members, while a source is not necessarily a destination, it depends on the role(s) in the group. For example, an endpoint configured only as multicaster will be only-source in a group where all the other members are configured as pure listeners.


May be you should refer to section 2.2 which provides a better explanation.

[MT] Section 2.2 has now become Appendix A.2, in order to have the document body more in synch with the main OSCORE document. Which portion(s) of Appendix A.2 do you think it is better to point at?



Endpoint ID: why this exclusion of pure listeners? It complicates the protocol.

[MT] This was previously discussed with Jim, as a group member configured _only_ as pure listener does not need to receive upon join (and thereafter store) an Endpoint ID. In fact, that endpoint is never going to transmit group messages where including its own Endpoint ID as Sender ID.


Remove: =E2=80=9CThat is, =E2=80=A6. same time=E2=80=9D. Does not clarify u= niqueness.

[MT] Done.



Section 2.
I do understand the purpose of section 2.2, but not of section 2.1. As far as I understand the Group Manager is essential for secure group communication as specified here; No GM means no group communication (is that correct?) In that case I would suggest two other subsections.

[MT] =E2=80=9CNo GM means no group communication=E2=80=9D is essenti= ally correct in this context, as there would be no provisioning of keying material to joining endpoints. To be more precise, with no GM: i) group membership has to be static; and ii) all key provisioning has to be done once and for all before deployment through other means.


Section 2.1= a Requirements on group manager, section 2.1b, Protocol characteristics.

[MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager (that is, your proposed Section 2.1a). Instead, your proposed Section 2.1b is essentially the current Appendix A. This was driven by having the document body more in synch with the main OSCORE document.



Multicast communication topology: remove the lighting use case, and refer to appendix.

[MT] Done.


Multicast group size: is this the number of members? The fact that a member may be listener as well as multicaster is another aspect and not relevant to size. The numbers are interesting to guide implementers.

[MT] We now put less stress on the roles of group members, but we would anyway keep the roles related to the indicative numbers provided, i.e. =E2=80=9C=E2=80=A6 The group size is the current number of= members in a multicast group. In the use cases mentioned in this document, the number of multicasters (normally the controlling devices) is expected to be much smaller than the number of listeners (i.e. the controlled devices). A security solution for group communication that supports 1 to 50 multicasters would be able to properly cover the group sizes required for most use cases that are relevant for this document =E2=80=A6=E2=80=9D.



Establishment and Management of Security context: I recommend to mention relation to OSCORE security contexts.

[MT] Done.


Actually, the text seems to discuss requirements on the GM. GM specification is out of scope but not any GM design can be used with oscoap-multicast.

[MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager. Do you think any particular additional requirement/responsibility on the Group Manager is missing?

[MT] Note that the Group Manager is not expected to necessarily be an actual member of the group. That is, it needs to generate/manage/provide OSCORE Contexts upon joining and to renew Common Contexts within the group, but it is not required to communicate by means of group OSCORE itself.



Multicast data security Cipher suite: GM requirement??

[MT] I would not say so. The Group Manager indicates keying material and security parameters to new endpoints during the join process (see current Section 6 and current Appendix D), specifying also the security Cipher Suite to use in the group. However, the Group Manager is not required to use such Cipher Suite itself, unless it is also an actual group member.<= /font>



Backward security: GM requirement?

[MT] This is actually a requirement of the group rekeying scheme used by the GM to manage the group keying material. So I would not say it is a GM requirement.


Actually, this poses the question of ordering of messages from different sources; Is there a total ordering of messages or only a partial source order? (I see this is explained in section 2.2) May be a forward reference?

[MT] At the beginning of current Section 4, we now list the security objectives fulfilled by group OSCORE, and point at current Appendix A.2 for further details.



Forward security: GM requirement?

[MT] This is actually a requirement of the group rekeying scheme used by the GM to manage the group keying material. So I would not say it is a GM requirement.



Section 2.2 security Objectives
Bullet 2; remove =E2=80=9CIn fact, =E2=80=A6plaintext=E2=80=9D ; do= es not add much

[MT] Done.


Bullet 3: shall be authenticated with respect to two sources (sender and group) (simultaneously?)

[MT] We have group authentication already from the usage of the AEAD, plus source authentication through the countersignature. Do you think we should have source authentication as a separate bullet?



Section 3;
Suggestion: Each endpoint stores extensions of the Oscore context. I seem to read that the Contexts used for group communication are extensions to the one specified for OSCORE. If that is true, use different names or use extension of .
Common context -> group context? In OSCORE the common context is defined as common between send and receiver, not common to the group.

[MT] We actually need both =E2=80=9CCommon context=E2=80=9D and =E2=80= =9CGroup Context=E2=80=9D, as different concepts. In each endpoint, =E2=80=9CGroup Context= =E2=80=9D is what you would implicitly define as =E2=80=9Cpair context=E2=80=9D i= n OSCORE, and it similarly includes a =E2=80=9CCommon context=E2=80=9D, a =E2=80= =9CSender context=E2=80=9D and _multiple_ (unlike OSCORE) =E2=80=9CRecipient contexts=E2=80=9D= , all of which with additional elements with respect to their equivalent in OSCORE.


Point 1, bullet 2: =E2=80=9C =E2=80=A6 once the security context is establis= hed=E2=80=9D: do you mean the common context?

[MT] Yes, now clarified.


Point 2, Th= e phrase =E2=80=9CIn practice,=C2=A0 =E2=80=A6 OSCORE messages=E2=80=9D= is difficult to understand (at least I see multiple explanations)

[MT] We have rephrased as: =E2=80=9CIn practice, the symmetric keyin= g material in the Sender Context of the sender endpoint is shared with all the recipient endpoints that have received group messages from that same sender endpoint.=E2=80=9D

[MT] Also, we have similarly rephrased the related sentence in the paragraph below about the Recipient Context, i.e.: =E2=80=9CIn practice, the symmetric keying material in a given Recipient Context of the recipient endpoint is shared with the associated sender endpoint from which group messages are received=E2=80=9D.


Do you mean= that SenderID is equal to its endpointID received at joining?

[MT] Yes, we have clarified it in the definition of Endpoint ID in Section 1.1.


It would be= nice to give tables with additions to OSCORE security context for Sender Context, Recipient Context and Common (group) context; Now one has to search for them in the text.

[MT] Done.


Point 3 Is Recipient Id also equal to endpointID. The text about Recipient context creation is unclear. Is the creation done by the Recipient endpoint? How are the contexts shared? Who does the sharing? Or do you mean that they are copied over at reception?
Sender pubic key is extracted from Sender context (stored in GM, or sent over with message?) or from a trusted key repository? This paragraph is not very clear to me. Parts of the text are good candidates for a GM requirements section. See my comments about appendix C.

[MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager.

[MT] As to the other points:

- Like in OSCORE, the Recipient ID is the Endpoint ID of a sender endpoint from the perspective of the recipient endpoint<= span style=3D"text-decoration: none">.

- Yes, the creation of a Recipient Context is done by the recipient endpoint upon the reception of a first message from the corresponding other endpoint acting as sender endpoint. Now it is stated explicitly, and followed by a pointer to current Sections 4.2 and 4.4 about processing incoming messages.=

- The sender's publi= c key has to be retrieved anyway from a trusted key repository, using the Endpoint ID of such sender endpoint. As a possible configuration (see current Appendix D.2), the Group Manager can be configured to act as trusted key repository. This is also mentioned as an optional task of the Group Manager in the current Section 6.



Section 3.1 Remove: =E2=80=9Csuch a risk=E2=80=A6 office buildings.= Nevertheless=E2=80=9D. The fun with drones provided by Dutch universities, proves these assumptions to be futile.

[MT] Done.



Distribution of master key is another GM requirement.

[MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager. The Group Manager distributes the OSCORE Master Secret as part of the Security Common Context.



Section 4 bullit 1: The phrase =E2=80=9Cset to the SenderId of the endpoint=E2=80=9D creates the impression that an endpoint has multi= ple IDs. Probably, you mean:=C2=A0 the SenderId of the Context is set t= o the ID of the endpoint (or similar much better text)

[MT] The Sender ID is related to the endpoint, which has indeed a single one stored in its own Sender Context, but not to the Context. We rephrased as =E2=80=9Cset to the Endpoint ID of the endpoint= transmitting the message, i.e. the Sender ID=E2=80=9D.


Bullit 2 star 1: Is the group=E2=80=99s Security Context equal to the Common= =C2=A0 context?

[MT] No, and we actually need both =E2=80=9CCommon context=E2=80=9D = and =E2=80=9CGroup Context=E2=80=9D, as different concepts. In each endpoint, =E2=80= =9CGroup Context=E2=80=9D is what you would implicitly define as =E2=80=9C= pair context=E2=80=9D in OSCORE, and it similarly includes a =E2=80=9CCommon context=E2= =80=9D, a =E2=80=9CSender context=E2=80=9D and _multiple_ (unlike OSCORE)= =E2=80=9CRecipient contexts=E2=80=9D, all of which with additional elements with r= espect to their equivalent in OSCORE.



Figure 1 differs from figure 7 in OSCORE draft

[MT] Figure 1 actually is related to Figure 8 in the OSCORE draft.



Section 5; Suggestion: In case of malformed messages a =E2=80=9Clis= tening only=E2=80=9D receiver endpoint silently rejects the message and se= nds no error message; all other receivers return an error message x.xx.

[MT] The current text was the result of a discussion with Jim at IETF99, to avoid congesting the group. Perhaps we can rephrase the current text as a possible conservative behavior, while adding what you suggest especially in case of groups that are small or hard to congest.



Section 5.1
The document uses two terms: multicaster endpoint and sender endpoint; I assume they are equal concepts; If yes, choose one, if no, explain difference.

[MT] The definition of =E2=80=9CMulticaster=E2= =80=9D is provided in Section 1.1, and it refers to an endpoint acting as =E2=80=9CSender=E2=80=9D when transmitting group req= uests and =E2=80=9CRecipient=E2=80= =9D when receiving responses. On the other hand, a sender can be a multicaster sending a group request or as well a listener sending a response. The concepts= of = =E2=80=9CSender=E2= =80=9D and =E2=80=9CRecipient=E2=80=9D as such as inherited fro= m the main OSCORE document.



Point 1; stores where? Find where?

[MT] I am not sure we should provide similar details here. Not even OSCORE specifies this in its Section 8.1, point 6.



Section 5.2 point 2; It is not clear how a new Recipient context is created; That is probably due to the vague duties of the GM.
=

[MT] It is created just like in OSCORE, plus the inclusion of the sender endpoint's public key to be separately retrieved.=



Section 6; I think that synchronizing sequence numbers is part of the standard and should be specified as requirement on the GM.

[MT] The GM is expected to indicate to a joining endpoint the approach to follow. So, specifying the approach to use can be seen as a GM requirement, rather than enforcing that approach in the group itself. This is now also part of the GM's responsibilities listed in current Section 6.




Section 7.1=C2=A0 Remove =E2=80=9Cfor instance .. those roles=E2=80= =9D Refer to appendix A.

[MT] Done (now Appendix B).



Section 7; Don=E2=80=99t you need some discussion on size of group = to discuss security breach probabilities?

[MT] That's something more we can add. Input are welcome.



Appendix A
lighting control; here you refer to multicast group, which is sometimes correct. In the introduction you talk about group communication.

[MT] A group displays group communication including delivery of multicast messages (requests) together with unicast messages (responses). We have revised the document and simply refer to =E2=80=9Cgroup=E2= =80=9D now.


Switches bu= t also sensors can control the state of the lights. Why is the backbone multicast enabled? Is that a MUST?

[MT] That can be relaxed, as long as IP packets having a multicast destination address are correctly delivered all the way to the border routers acting as entry points.


Events within a 200 ms interval are perceived as simultaneous by humans. Necessary in many configurations.

[MT] Ok, now mentioned.



In Building control, intervals of seconds are sufficient.


[MT] Ok, now mentioned.


Commissioni= ng of LLN system; Interesting idea that multicast should be enabled on a subnetwork for discovery. However, that would be after enrollment of the devices? I think the use case needs a bit more thought.

[MT] Agree, we can think more about it and collect input.



Emergency multicast; Also interesting, but that needs a fault tolerant multicast algorithm, like MPL. for example.

[MT] Ok, now mentioned.



Appendix C. I like this appendix, it provides the necessary understanding how things will work in practice. Please keep this appendix but also create a section with GM requirements, with the purpose of the requirements explained in the appendix. (this is a suggestion, don=E2=80=99t know if it will work actually)

[MT] Also related to other comments, we now have a new Section 6 listing the responsibilities of the Group Manager.



C.1=C2=A0 bullit management keying material: depend -> depends

[MT] I think that =E2=80=9Cdepend=E2=80=9D is correct. The subject i= s =E2=80=9Celements=E2=80=9D.



C.3 I think the utilization of ACE framework SHOULD be part of the standard. Too many options reduce the interoperability. Especially standards about the GM seem rather crucial to me.

[MT] This is something we can further discuss in the WG. I personally support your view, while for the time being the ACE-based approach in current Appendix D.3 is seen as a possible incarnation of the more generic description in current Appendix D.1. It might be good to still leave room for alternative join approaches that are not based on ACE, as long as they correctly initialize new endpoints upon joining the group.




Appendix D. Are the proposed options interoperable within a group? Also here I would advocate interoperable solutions only.

[MT] Yes, they are. Upon joining, the Group Manager can possibly mention the synchronization policy to follow on a per-endpoint basis (see current Section 5 introducing this aspect at a high-level).





--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://w=
ww.sics.se

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.
--------------5AA319B466C4EB100BE4E0EF-- --XiXnheOWeZ8MXzNXEGpfH8MAFtby07kJF-- --VBNPWHlO6sy7A9jH9bZMVjIJjjLQsM45u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJancuMAAoJEO4mZLQOWNpDSBcH/j3ZQft0C3ekjNBOJaforWZl I5szt8qtsdRgHIlsftcAMEPRHtRDFPnOvy1oJzk82Kqzhy4J3hThANMNq5UlZmct +vFANvr/nque5cRIX4fXcPkM/eeiddU9KB8vAv1z8HMBOIomQViRICm2zYqaSltO k2fWjniWyMvmNzTbjbZPMd21sdIrFlhbajGh/N9B58akhcAAU/RFd9NLTu3EbU7p F4nd5U9QlwJMkTohGMPPsidIg9aR8FRUWEYyDf0VQzemnrU7ZywWCT1nA6wTQt0/ HhAVuBxwX8hGCIGXMzh5b1MkYx5Xf1UN1e3OmEBQDJ6iOVpMEfavbgbYVD+8Bdg= =XJN1 -----END PGP SIGNATURE----- --VBNPWHlO6sy7A9jH9bZMVjIJjjLQsM45u-- From nobody Mon Mar 5 15:37:26 2018 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 C2E1E12025C; Mon, 5 Mar 2018 15:37:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152029304475.12888.13935118205162912829@ietfa.amsl.com> Date: Mon, 05 Mar 2018 15:37:24 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-pubsub-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 23:37:25 -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 WG of the IETF. Title : Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Authors : Michael Koster Ari Keranen Jaime Jimenez Filename : draft-ietf-core-coap-pubsub-04.txt Pages : 23 Date : 2018-03-05 Abstract: The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-pubsub-04 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 Tue Mar 6 00:41:04 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA906126BF0 for ; Tue, 6 Mar 2018 00:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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, 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 mvdjaefcUCmI for ; Tue, 6 Mar 2018 00:40:59 -0800 (PST) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 053C1120724 for ; Tue, 6 Mar 2018 00:40:58 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud9.xs4all.net with ESMTPA id t89YeZeTvHLVet89YecMi4; Tue, 06 Mar 2018 09:40:57 +0100 Received: from AMontpellier-654-1-236-32.w92-145.abo.wanadoo.fr ([92.145.179.32]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 06 Mar 2018 09:40:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 06 Mar 2018 09:40:56 +0100 From: peter van der Stok To: Marco Tiloca Cc: consultancy@vanderstok.org, Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <1226ef9a-c95d-42c4-4bd0-b59c64135dde@ri.se> References: <1226ef9a-c95d-42c4-4bd0-b59c64135dde@ri.se> Message-ID: <04e5444a9d16de7f7004ea926737cbed@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJuq3zB0w23+Yf7PCMWgKHxUsezhjLIfkTNbuolhSwOokP/63U77lGYEEhepFY8yJdqdw+XerfA8xZ2l2z1dg9+QwjmPNItDtbAdKRnvWNq6phAwJGdj SN4P6yRdaY3qhno8AW4GS3V82qJkCrhO6MNVXPHAriN8Zvkl3gHVr4J9CR+eowkQGbWev/kVXSVbItAd+la2UvoT6NOaxnK7xF8h3UNUnQjlWZ3WmFTom8rb Kg/RsA+L8HzrM6xz3aW8Gw== Archived-At: Subject: Re: [core] tiloca-core-muticast-oscoap-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Mar 2018 08:41:03 -0000 Hi Marco, thanks for your reaction. I will read the new version and comment on that. Peter Marco Tiloca schreef op 2018-03-05 23:58: > Hello Peter, > > Thank you for your review and comments. Please, find some answers in > line. > > We took into account your comments for producing the latest version of > the draft [1]. Please, find some answers in line. > > Best, > /Marco > > [1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-01 > > On 2018-02-06 12:04, peter van der Stok wrote: > >> Hi authors, >> >> Many thanks for this very useful document. Below some comments. >> These are mainly restricted to document structure, relation to other >> documents, and new concepts and terminology. I hope they are >> sufficiently clear and help improving the text. >> >> Peter >> >> Abstract: >> I did not see text that validates the phrase: >> “All security requirements fulfilled by OSCORE are >> maintained for multicast OSCORE request messages and related OSCORE >> response messages.” >> I did see: this document specifies the parameter values for OSCORE >> messages applied to group communication. > > [MT] Now rephrased as: “In particular, it is defined how OSCORE > should be used in a group communication setting, while fulfilling the > same security requirements for request messages and related response > message.” > >> Why is source authentication more important (mentioned separately) >> than all other security aspects of OCORE? > > [MT] In the main OSCORE specification, one has source authentication > among two parties directly from the usage of the AEAD. Instead, in the > group communication setting considered by group OSCORE, the Common > Context is sufficient to ensure group authentication, while the same > components alone are not sufficient to achieve source authentication > too. This is the reason why we additionally introduce > countersignatures trough each individual endpoint's private key, and > why we present source-authentication as a specific requirement to be > “brought back again”. > >> Introduction: >> Benefit from a group communication model: A possible group >> communication model is the use of unicast for all individual >> destinations; I don’t see how this increases efficiency. May-be >> you mean: leveraging the broadcast model of the underlying >> communication medium? > > [MT] Yes, that's right, however this should already come from RFC7390. > The advantage from the underlying communication model is limited to > requests. > >> Across intermediary nodes -> possibly involving intermediary nodes. > > [MT] Done. > >> The phrase: “To this end, …. protected message” is funny. I >> did not know that you could protect messages by including payload >> (something went wrong in this phrase). > > [MT] We rephrased as “To this end, a CoAP message is protected by > including its payload (if any), certain options, and header fields in > a COSE object, which finally replaces the authenticated and encrypted > fields in the protected message.” > >> Remove: “while fulfilling the same security requirements”. My >> suggestion: end-to-end security is assured by using the same >> security technology as for OSCORE. > > [MT] As aligned with the main OSCORE document, we rephrased as “so > that end-to-end security is assured by using the same security > method”. > >> The OSCORE draft mentions: >> “providing end-to-end encryption, integrity, replay protection, >> and >> secure the binding of response to request”. It does not mention >> source authentication explicitly. So, why is multicast-oscoap >> different? > > [MT] In OSCORE, one has source authentication among two parties > directly from the usage of the AEAD. Instead, in the group > communication setting considered by group OSCORE, the Common Context > is sufficient to ensure group authentication, while the same > components alone are not sufficient to achieve source authentication > too. This is the reason why we additionally introduce > countersignatures trough each individual endpoint's private key, and > why we present source-authentication as a specific requirement to be > “brought back again”. > >> Section 1.1 >> Multicaster: Is M <= N? > > [MT] Not necessarily. > >> sub-question is: are the destinations always all group members and >> is the source also a destination? > > [MT] Destinations are always group members, while a source is not > necessarily a destination, it depends on the role(s) in the group. For > example, an endpoint configured only as multicaster will be > only-source in a group where all the other members are configured as > pure listeners. > >> May be you should refer to section 2.2 which provides a better >> explanation. > > [MT] Section 2.2 has now become Appendix A.2, in order to have the > document body more in synch with the main OSCORE document. Which > portion(s) of Appendix A.2 do you think it is better to point at? > >> Endpoint ID: why this exclusion of pure listeners? It complicates >> the protocol. > > [MT] This was previously discussed with Jim, as a group member > configured _only_ as pure listener does not need to receive upon join > (and thereafter store) an Endpoint ID. In fact, that endpoint is never > going to transmit group messages where including its own Endpoint ID > as Sender ID. > >> Remove: “That is, …. same time”. Does not clarify uniqueness. > > [MT] Done. > >> Section 2. >> I do understand the purpose of section 2.2, but not of section 2.1. >> As far as I understand the Group Manager is essential for secure >> group communication as specified here; No GM means no group >> communication (is that correct?) In that case I would suggest two >> other subsections. > > [MT] “No GM means no group communication” is essentially correct > in this context, as there would be no provisioning of keying material > to joining endpoints. To be more precise, with no GM: i) group > membership has to be static; and ii) all key provisioning has to be > done once and for all before deployment through other means. > >> Section 2.1a Requirements on group manager, section 2.1b, Protocol >> characteristics. > > [MT] Also related to other comments, we now have a new Section 6 > listing the responsibilities of the Group Manager (that is, your > proposed Section 2.1a). Instead, your proposed Section 2.1b is > essentially the current Appendix A. This was driven by having the > document body more in synch with the main OSCORE document. > >> Multicast communication topology: remove the lighting use case, and >> refer to appendix. > > [MT] Done. > >> Multicast group size: is this the number of members? The fact that a >> member may be listener as well as multicaster is another aspect and >> not relevant to size. The numbers are interesting to guide >> implementers. > > [MT] We now put less stress on the roles of group members, but we > would anyway keep the roles related to the indicative numbers > provided, i.e. “… The group size is the current number of members > in a multicast group. In the use cases mentioned in this document, the > number of multicasters (normally the controlling devices) is expected > to be much smaller than the number of listeners (i.e. the controlled > devices). A security solution for group communication that supports 1 > to 50 multicasters would be able to properly cover the group sizes > required for most use cases that are relevant for this document > …”. > >> Establishment and Management of Security context: I recommend to >> mention relation to OSCORE security contexts. > > [MT] Done. > >> Actually, the text seems to discuss requirements on the GM. GM >> specification is out of scope but not any GM design can be used with >> oscoap-multicast. > > [MT] Also related to other comments, we now have a new Section 6 > listing the responsibilities of the Group Manager. Do you think any > particular additional requirement/responsibility on the Group Manager > is missing? > > [MT] Note that the Group Manager is not expected to necessarily be an > actual member of the group. That is, it needs to > generate/manage/provide OSCORE Contexts upon joining and to renew > Common Contexts within the group, but it is not required to > communicate by means of group OSCORE itself. > >> Multicast data security Cipher suite: GM requirement?? > > [MT] I would not say so. The Group Manager indicates keying material > and security parameters to new endpoints during the join process (see > current Section 6 and current Appendix D), specifying also the > security Cipher Suite to use in the group. However, the Group Manager > is not required to use such Cipher Suite itself, unless it is also an > actual group member. > >> Backward security: GM requirement? > > [MT] This is actually a requirement of the group rekeying scheme used > by the GM to manage the group keying material. So I would not say it > is a GM requirement. > >> Actually, this poses the question of ordering of messages from >> different sources; Is there a total ordering of messages or only a >> partial source order? (I see this is explained in section 2.2) May >> be a forward reference? > > [MT] At the beginning of current Section 4, we now list the security > objectives fulfilled by group OSCORE, and point at current Appendix > A.2 for further details. > >> Forward security: GM requirement? > > [MT] This is actually a requirement of the group rekeying scheme used > by the GM to manage the group keying material. So I would not say it > is a GM requirement. > >> Section 2.2 security Objectives >> Bullet 2; remove “In fact, …plaintext” ; does not add much > > [MT] Done. > >> Bullet 3: shall be authenticated with respect to two sources (sender >> and group) (simultaneously?) > > [MT] We have group authentication already from the usage of the AEAD, > plus source authentication through the countersignature. Do you think > we should have source authentication as a separate bullet? > >> Section 3; >> Suggestion: Each endpoint stores extensions of the Oscore context. I >> seem to read that the Contexts used for group communication are >> extensions to the one specified for OSCORE. If that is true, use >> different names or use extension of . >> Common context -> group context? In OSCORE the common context is >> defined as common between send and receiver, not common to the >> group. > > [MT] We actually need both “Common context” and “Group > Context”, as different concepts. In each endpoint, “Group > Context” is what you would implicitly define as “pair context” > in OSCORE, and it similarly includes a “Common context”, a > “Sender context” and _multiple_ (unlike OSCORE) “Recipient > contexts”, all of which with additional elements with respect to > their equivalent in OSCORE. > >> Point 1, bullet 2: “ … once the security context is >> established”: do you mean the common context? > > [MT] Yes, now clarified. > >> Point 2, The phrase “In practice, … OSCORE messages” is >> difficult to understand (at least I see multiple explanations) > > [MT] We have rephrased as: “In practice, the symmetric keying > material in the Sender Context of the sender endpoint is shared with > all the recipient endpoints that have received group messages from > that same sender endpoint.” > > [MT] Also, we have similarly rephrased the related sentence in the > paragraph below about the Recipient Context, i.e.: “In practice, the > symmetric keying material in a given Recipient Context of the > recipient endpoint is shared with the associated sender endpoint from > which group messages are received”. > >> Do you mean that SenderID is equal to its endpointID received at >> joining? > > [MT] Yes, we have clarified it in the definition of Endpoint ID in > Section 1.1. > >> It would be nice to give tables with additions to OSCORE security >> context for Sender Context, Recipient Context and Common (group) >> context; Now one has to search for them in the text. > > [MT] Done. > >> Point 3 Is Recipient Id also equal to endpointID. The text about >> Recipient context creation is unclear. Is the creation done by the >> Recipient endpoint? How are the contexts shared? Who does the >> sharing? Or do you mean that they are copied over at reception? >> Sender pubic key is extracted from Sender context (stored in GM, or >> sent over with message?) or from a trusted key repository? This >> paragraph is not very clear to me. Parts of the text are good >> candidates for a GM requirements section. See my comments about >> appendix C. > > [MT] Also related to other comments, we now have a new Section 6 > listing the responsibilities of the Group Manager. > > [MT] As to the other points: > > - Like in OSCORE, the Recipient ID is the Endpoint ID of a sender > endpoint from the perspective of the recipient endpoint. > > - Yes, the creation of a Recipient Context is done by the recipient > endpoint upon the reception of a first message from the corresponding > other endpoint acting as sender endpoint. Now it is stated explicitly, > and followed by a pointer to current Sections 4.2 and 4.4 about > processing incoming messages. > > - The sender's public key has to be retrieved anyway from a trusted > key repository, using the Endpoint ID of such sender endpoint. As a > possible configuration (see current Appendix D.2), the Group Manager > can be configured to act as trusted key repository. This is also > mentioned as an optional task of the Group Manager in the current > Section 6. > >> Section 3.1 Remove: “such a risk… office buildings. >> Nevertheless”. The fun with drones provided by Dutch universities, >> proves these assumptions to be futile. > > [MT] Done. > >> Distribution of master key is another GM requirement. > > [MT] Also related to other comments, we now have a new Section 6 > listing the responsibilities of the Group Manager. The Group Manager > distributes the OSCORE Master Secret as part of the Security Common > Context. > >> Section 4 bullit 1: The phrase “set to the SenderId of the >> endpoint” creates the impression that an endpoint has multiple >> IDs. Probably, you mean: the SenderId of the Context is set to the >> ID of the endpoint (or similar much better text) > > [MT] The Sender ID is related to the endpoint, which has indeed a > single one stored in its own Sender Context, but not to the Context. > We rephrased as “set to the Endpoint ID of the endpoint transmitting > the message, i.e. the Sender ID”. > >> Bullit 2 star 1: Is the group’s Security Context equal to the >> Common context? > > [MT] No, and we actually need both “Common context” and “Group > Context”, as different concepts. In each endpoint, “Group > Context” is what you would implicitly define as “pair context” > in OSCORE, and it similarly includes a “Common context”, a > “Sender context” and _multiple_ (unlike OSCORE) “Recipient > contexts”, all of which with additional elements with respect to > their equivalent in OSCORE. > >> Figure 1 differs from figure 7 in OSCORE draft > > [MT] Figure 1 actually is related to Figure 8 in the OSCORE draft. > >> Section 5; Suggestion: In case of malformed messages a “listening >> only” receiver endpoint silently rejects the message and sends no >> error message; all other receivers return an error message x.xx. > > [MT] The current text was the result of a discussion with Jim at > IETF99, to avoid congesting the group. Perhaps we can rephrase the > current text as a possible conservative behavior, while adding what > you suggest especially in case of groups that are small or hard to > congest. > >> Section 5.1 >> The document uses two terms: multicaster endpoint and sender >> endpoint; I assume they are equal concepts; If yes, choose one, if >> no, explain difference. > > [MT] The definition of “Multicaster” is provided in Section 1.1, > and it refers to an endpoint acting as “Sender” when transmitting > group requests and “Recipient” when receiving responses. On the > other hand, a sender can be a multicaster sending a group request or > as well a listener sending a response. The concepts of “Sender” > and “Recipient” as such as inherited from the main OSCORE > document. > >> Point 1; stores where? Find where? > > [MT] I am not sure we should provide similar details here. Not even > OSCORE specifies this in its Section 8.1, point 6. > >> Section 5.2 point 2; It is not clear how a new Recipient context is >> created; That is probably due to the vague duties of the GM. > > [MT] It is created just like in OSCORE, plus the inclusion of the > sender endpoint's public key to be separately retrieved. > >> Section 6; I think that synchronizing sequence numbers is part of >> the standard and should be specified as requirement on the GM. > > [MT] The GM is expected to indicate to a joining endpoint the approach > to follow. So, specifying the approach to use can be seen as a GM > requirement, rather than enforcing that approach in the group itself. > This is now also part of the GM's responsibilities listed in current > Section 6. > >> Section 7.1 Remove “for instance .. those roles” Refer to >> appendix A. > > [MT] Done (now Appendix B). > >> Section 7; Don’t you need some discussion on size of group to >> discuss security breach probabilities? > > [MT] That's something more we can add. Input are welcome. > >> Appendix A >> lighting control; here you refer to multicast group, which is >> sometimes correct. In the introduction you talk about group >> communication. > > [MT] A group displays group communication including delivery of > multicast messages (requests) together with unicast messages > (responses). We have revised the document and simply refer to > “group” now. > >> Switches but also sensors can control the state of the lights. Why >> is the backbone multicast enabled? Is that a MUST? > > [MT] That can be relaxed, as long as IP packets having a multicast > destination address are correctly delivered all the way to the border > routers acting as entry points. > >> Events within a 200 ms interval are perceived as simultaneous by >> humans. Necessary in many configurations. > > [MT] Ok, now mentioned. > >> In Building control, intervals of seconds are sufficient. > > [MT] Ok, now mentioned. > >> Commissioning of LLN system; Interesting idea that multicast should >> be enabled on a subnetwork for discovery. However, that would be >> after enrollment of the devices? I think the use case needs a bit >> more thought. > > [MT] Agree, we can think more about it and collect input. > >> Emergency multicast; Also interesting, but that needs a fault >> tolerant multicast algorithm, like MPL. for example. > > [MT] Ok, now mentioned. > >> Appendix C. I like this appendix, it provides the necessary >> understanding how things will work in practice. Please keep this >> appendix but also create a section with GM requirements, with the >> purpose of the requirements explained in the appendix. (this is a >> suggestion, don’t know if it will work actually) > > [MT] Also related to other comments, we now have a new Section 6 > listing the responsibilities of the Group Manager. > >> C.1 bullit management keying material: depend -> depends > > [MT] I think that “depend” is correct. The subject is > “elements”. > >> C.3 I think the utilization of ACE framework SHOULD be part of the >> standard. Too many options reduce the interoperability. Especially >> standards about the GM seem rather crucial to me. > > [MT] This is something we can further discuss in the WG. I personally > support your view, while for the time being the ACE-based approach in > current Appendix D.3 is seen as a possible incarnation of the more > generic description in current Appendix D.1. It might be good to still > leave room for alternative join approaches that are not based on ACE, > as long as they correctly initialize new endpoints upon joining the > group. > >> Appendix D. Are the proposed options interoperable within a group? >> Also here I would advocate interoperable solutions only. > > [MT] Yes, they are. Upon joining, the Group Manager can possibly > mention the synchronization policy to follow on a per-endpoint basis > (see current Section 5 introducing this aspect at a high-level). > >> > > -- > Marco Tiloca, PhD > Research Institutes of Sweden > RISE ICT/SICS > Isafjordsgatan 22 / Kistagången 16 > SE-164 40 Kista (Sweden) > Phone: +46 (0)70 60 46 501 > https://www.sics.se > > The RISE institutes Innventia, SP and Swedish ICT > have merged in order to become a stronger research > and innovation partner for businesses and society. > > SICS Swedish ICT AB, has now changed name to RISE SICS AB. From nobody Tue Mar 6 06:24:56 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FE712D779 for ; Tue, 6 Mar 2018 06:24:55 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 2OoaOsmQ02Dw for ; Tue, 6 Mar 2018 06:24:53 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 3039F127076 for ; Tue, 6 Mar 2018 06:24:53 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id x12so14929728oie.13 for ; Tue, 06 Mar 2018 06:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=7v9KE1d2P6o1JyvXzTBZRKckzKTmGzwK/dl33Ma5Lls=; b=ZQfkMXlDvlbfzinCzP2vzuQG9ltw/sooM7NH8/YA7oSKmVRb2XXHAia8cMJY+rYe2r QVw1sbYAUdop1eae0gr0c/9I4fiuZujrJLdXPcHU/uvcBfPIaEh/RoExt4RSmdZlUr19 7xnTCq9yXW3tN1BwUzidhEdemq7SlvQ8BXf9eIV1JDpGsunJr21CNTDAwCBoB4bJKqCz 1lmTTr3Mz8R/lGngD8VGVF3jMKvXVanq/Ptz8Xnfdd6V2rAO2J/QuVxFz2rtvFY4YdVL PjbC5VYRw+xSqR6snrnKnbyrVGLxU1DDUeIaaecHNUHNr1g9ATMc9jy1hmvCLeRfTksW 1zFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7v9KE1d2P6o1JyvXzTBZRKckzKTmGzwK/dl33Ma5Lls=; b=K6Sl4vgKPiLFW/Eaf8ruGGSsaxnCfQiLJ+1XYwat0HFaHb2/8spMfgKME/k5Udj60O uKBe0OYjykSqPWsbbzsxftpsFQTJcQwrwap0fVkvTnxbIiivaZqsSIoxQQ3mGKjg10qZ P2FIiCKPsYlXjZtZsgMsPgoySGmowuGZK6ajw34zPIHDwBnEsB24zl5hl+0S+I9OuEBF JUz0kvuEc57eimMu9Y/fNruK97amWnN5btXiI8xXGBU85WyevCcrPBAcsvuoQWhcslC4 fjcVaIEFgmqhDSAcudWCQYW9+CZFJeVxP8hQGm0dNAOfRyfOyYz96Os4vwNAbXSwEAC2 j9Cw== X-Gm-Message-State: AElRT7HVvxOLzMr4E16bedN6J85OWUO1/BFLSqvflFV5raA6WjPZCABt YXzQUvSPw1H0qeuGnP79IQeRIQ== X-Google-Smtp-Source: AG47ELuS2vsKlIFgZ+6gktqj2yyhonnZN78xAickBOBfpRrEdMIUF/6AFjc5tSL7FnhU4dIvEtNg/w== X-Received: by 10.202.87.136 with SMTP id l130mr12375730oib.356.1520346292479; Tue, 06 Mar 2018 06:24:52 -0800 (PST) Received: from [172.24.9.177] ([12.202.65.58]) by smtp.gmail.com with ESMTPSA id c70sm441144oih.56.2018.03.06.06.24.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 06:24:51 -0800 (PST) To: Carsten Bormann Cc: tsv-art@ietf.org, IETF discussion list , core@ietf.org, draft-ietf-core-cocoa.all@ietf.org References: <151544955659.9620.8608063613527533195@ietfa.amsl.com> <3D867C10-CBD6-4A8B-8149-5F91A75C57A5@tzi.org> From: Wesley Eddy Message-ID: <34939c50-7667-a670-1af9-336bc6ec5ecb@mti-systems.com> Date: Tue, 6 Mar 2018 09:24:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3D867C10-CBD6-4A8B-8149-5F91A75C57A5@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [core] Tsvart early review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Mar 2018 14:24:55 -0000 Thank you; I'm fine with these changes. On 2/21/2018 5:23 PM, Carsten Bormann wrote: > Hi Wesley, > > Thank you for this thorough review, and apologies for the high RTT of this email. > > We have prepared > > https://tools.ietf.org/html/draft-ietf-core-cocoa-03 > > with some reactions to your (and Mirja’s) comments; diff is in > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt > >> The terminology "RTO estimate" used throughout the document is confusing to me. >> The RTO is a solid value, not estimated, and is computed from estimates of the >> RTT and RTT variation. You could talk about estimating the "optimal" RTO value >> (for some definition of optimal), but I don't think that's the case here. >> Similarly section 4.2 is titled "Measured RTO Estimate", but RTO is not a >> measured quantity (it is always computed). I think this terminology needs to >> be corrected throughout the document. > We fixed the title of 4.2 (which was indeed misleading) to “Measurement-based RTO Estimate”. > We are using “RTO estimate” because we have three estimator processes (the weak, the strong, and the combined one). The result of the last estimator is used as the actual RTO value. But in 15 places we were trying to highlight the estimator process and not the use the result is being put to, that’s where it says RTO estimate. > If you have an idea how to get this result as well as avoid some of the confusion this seems to generate, we’d like to hear it. > >> Section 3 seems important to me, but doesn't say very clearly what it means by >> "generally applicable". Does that mean that it could run across the Internet? >> Does it work if there are very short or very long delays, or only ones around >> the values mentioned in Apppendix C? Does it work if the links are very thin >> bandwidth? Is it efficient when there is very high bandwidth (e.g. Gbps >> range)? Since there are many classes of IoT device and many possible use >> cases, it seems important to me to be a little bit more clear about the >> envisioned use cases, or at least the specific ones that have been explored >> to-date, versus what hasn't been explicitly considered but might (or might not) >> also work. The appendix just sort of uses the word "diverse" and mentions a >> couple link technologies, but otherwise doesn’t provide any enlightenment. > We expanded this a bit, please see > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-4 > > We did not explicitly restate the area of application of CoAP; of course CoCoA is intended to be used with CoAP, so this is less about data center use with Gbit/s channels, but more about the environments described in RFC 7228. > > (Note that there are also different “efficiency” considerations here: it is not the objective of CoCoA to fill a link.) > >> The first sentence in section 4 doesn't make much sense to me, since the >> default timeout doesn't imply any knowledge of the RTT. Do you mean to say >> that a more appropriate RTO can be computed once some RTT samples are >> available? The wording could be clarified here. > Should be fixed now. > >> The description in the beginning of section 4.2 says that ambiguous samples >> resulting from retransmissions are used in the "weak" estimator, and seems to >> be saying that Karn's algorithm is not used for filtering samples? The >> rationale seems to be in 4.2.2, but the text there is vague. In general, it >> would seem to result only in a potentially slower than necessary timeout, but >> still faster than the default. That seems inherently safe, and I'd think there >> could be a stronger argument made than the current text. > We didn’t feel like attempting to strengthen the language here, but did add a little bit of information in > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-5 > >> That said, the statement in this section that the rate of retries is reduced >> does not make sense, since any time the RTO decreases, the rate of retries >> should be increasing, with all other things considered equal? > Reduced as compared to strong-only (as the text now states). > >> Is there sensitivity to the weights for the EWMA? This has been studied a bit >> for TCP, but I guess may be different for CoAP scenarios since there are less >> samples typically, or something? > Several weights were tried in the research. Unfortunately, this is less than adequately documented at this time. It would be more satisfying to have some documentation about choosing these weights, maybe we can spawn some more formal research about this, but the important thing of course is that the results do look good with the suggested weights. > >> Why is this being targeted for just Informational rather than Experimental or >> better? It's mentioned as being informational in both the header and Section >> 1.1, but I didn't notice an explanation of why the WG thinks it wouldn't be a >> candidate for widespread use, etc. Is there a concern that needs to be >> described? > CoCoA is certainly intended to be the go-to implementation strategy for all but class-1 [RFC7228] devices. > > Experimental would be fine if we had an experiment that we want to run. > But the experiments we came up with already were done (see Appendix A). > > The question is, of course, whether unilateral implementation methods, to which congestion control methods without participation of the peer such as CoCoA belong, should be informational or standards track. Given that the Security area does most of its standardization work in informational documents, the line is blurry. Outside security, generally, what needs to be implemented for interoperability goes into standards track, and the rest is much less well-defined. We went for informational because it’s possible. Standards-Track also would work; I think we can leave this decision to the wisdom of the IESG. > > Grüße, Carsten > > From nobody Wed Mar 7 00:29:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0BF12778E for ; Wed, 7 Mar 2018 00:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 TmzC09c0tCwU for ; Wed, 7 Mar 2018 00:29:43 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00094.outbound.protection.outlook.com [40.107.0.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1884C124C27 for ; Wed, 7 Mar 2018 00:29:43 -0800 (PST) Received: from AM5P121CA0003.EURP121.PROD.OUTLOOK.COM (129.75.189.209) by HE1P121MB0041.EURP121.PROD.OUTLOOK.COM (129.75.191.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.15; Wed, 7 Mar 2018 08:29:39 +0000 Received: from VE1EUR02FT053.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::207) by AM5P121CA0003.outlook.office365.com (2603:10a6:224:b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.548.15 via Frontend Transport; Wed, 7 Mar 2018 08:29:39 +0000 Authentication-Results: spf=neutral (sender IP is 40.115.29.120) smtp.mailfrom=philips.com; ri.se; dkim=none (message not signed) header.d=none;ri.se; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 40.115.29.120 is neither permitted nor denied by domain of philips.com) Received: from LIGHT-EDGE-1.lighting.com (40.115.29.120) by VE1EUR02FT053.mail.protection.outlook.com (10.152.13.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.22 via Frontend Transport; Wed, 7 Mar 2018 08:29:39 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (213.199.154.183) by autodiscover.lighting.com (10.0.0.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Wed, 7 Mar 2018 09:29:38 +0100 Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM (129.75.24.213) by VI1P121MB0064.EURP121.PROD.OUTLOOK.COM (129.75.190.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.15; Wed, 7 Mar 2018 08:29:36 +0000 Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::3831:3931:53d7:ba6]) by VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::3831:3931:53d7:ba6%13]) with mapi id 15.20.0548.016; Wed, 7 Mar 2018 08:29:36 +0000 From: Esko Dijk To: Marco Tiloca , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG (core@ietf.org)" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgQ2FsbCBmb3IgQWRvcHRpb24gb24gZHJhZnQtdGls?= =?utf-8?Q?oca-core-multicast-oscoap?= Thread-Index: AQHTtM/gQtPw17I4zUSn1LB52zgqGKPEcBvA Date: Wed, 7 Mar 2018 08:29:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [80.246.199.209] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; VI1P121MB0064; 7:Cusz7tZgIAG9Y2VXxvX/idDIwenA7LoYEatfWcj++wFVuoammMAdP6glnW/wws3p99TFHaLxgElhYy7xu7Ay4VQ7wflZkaVgCzKCQ062eBkWm0r+TfS9n3Iw5d4b9AAY4XvHh5dV5oeo+Mg9isEwFdnVreSuGcEYoe2puEqyYmEWmLiFrmuPK0G4p24aPN8HvIhNQxpxB/f2sN1GtP3pw8Gpc03LcpiDb49dgjYk8sM/qQpZg2yWRiAJENOzJ/JV x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 797a78b6-6898-48bc-f0c7-08d584059180 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:VI1P121MB0064; X-MS-TrafficTypeDiagnostic: VI1P121MB0064:|HE1P121MB0041: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(278428928389397)(192374486261705)(100405760836317)(21748063052155)(260087099026482); UriScan:(37575265505322)(28532068793085)(278428928389397)(192374486261705)(100405760836317)(21748063052155)(260087099026482); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231220)(944501244)(52105095)(10201501046)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:VI1P121MB0064; BCL:0; PCL:0; RULEID:; SRVR:VI1P121MB0064; BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501244)(52105095)(93006095)(93003095)(3002001)(6055026)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061750153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:HE1P121MB0041; BCL:0; PCL:0; RULEID:; SRVR:HE1P121MB0041; x-forefront-prvs: 0604AFA86B X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(376002)(346002)(366004)(377424004)(189003)(199004)(5250100002)(3660700001)(790700001)(2900100001)(2950100002)(6436002)(74316002)(81166006)(6246003)(110136005)(105586002)(59450400001)(81156014)(2906002)(229383001)(8936002)(7736002)(66066001)(68736007)(33656002)(25786009)(7696005)(76176011)(97736004)(106356001)(575784001)(9686003)(86362001)(186003)(99286004)(54896002)(229853002)(6306002)(53936002)(478600001)(53946003)(14454004)(26005)(5660300001)(606006)(3280700002)(966005)(6116002)(236005)(55016002)(316002)(6506007)(53546011)(102836004)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P121MB0064; H:VI1P121MB0014.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) X-Microsoft-Antispam-Message-Info-Original: RRl2oZD6fpIRofbo9okO59AqR1HGrcMSTXbjeHv+Ie7l91SUePHfKjP8WSiFZ0eXCwKxIsBhUO7Aop3tHsTf8QqTnHN9uFhR6ZwevIs4zf4o0pwfLY4E/hEZubuZX89sVMUIwjNXeTgLSAPWKZQiGeoeH3arqdZdix2zJUMd/HwRSjnIyBbG+Z+s8gV7N0hThDj27yf0fCCQaoa4LRvEZNve9vyuV8ezuhpyBh/hBNz6R17IGn582J36HW8YS9vsF4xpbYKp71m4ddAasVSnD4t/80r7CZNs0313oNMAdo0ENjF8qxobRDRNGjXtJLNH2Xo0wPvlkjKoYnJgjZMDAw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1P121MB001470B4EE2FE2E26E5E19DB9BD80VI1P121MB0014EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0064 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR02FT053.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:40.115.29.120; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39380400002)(39860400002)(2980300002)(377424004)(199004)(189003)(33964004)(76176011)(81166006)(575784001)(81156014)(86362001)(84326002)(229383001)(6506007)(59450400001)(53546011)(102836004)(229853002)(61614004)(26826003)(8936002)(498600001)(2950100002)(316002)(2906002)(336012)(110136005)(16586007)(7696005)(74316002)(14454004)(5660300001)(966005)(97736004)(99286004)(606006)(356003)(5250100002)(68736007)(7736002)(106466001)(6116002)(790700001)(3846002)(25786009)(69596002)(105586002)(33656002)(6246003)(2900100001)(9686003)(26005)(6306002)(54896002)(55016002)(53946003)(53936002)(236005)(66066001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P121MB0041; H:LIGHT-EDGE-1.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT053; 1:kWAE2/2ZBNpgPwUJDOezVkmVF7INfWr2GPeNX3Cbp2G9p32OxKBVTcygf+FMRY9S375PQNAYEmjkXyKUTmB+LKHlOW1QYIToVOYSPLEtGQjKdgcau4hA6GysImRjQl8B X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(8559017)(2017052603328)(7193020); SRVR:HE1P121MB0041; X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0041; 3:bKDdkwn5eQktmfJFkAFBN57J2FcWVUB85YYxH2uGhUEQAIaHeYmLKnM4yik2tDqbf8GDUN25ahon+7aLF0hgJYT6KdIUsmot4ES4zZ/jgOQHLrnLWuBTQbN7fI+f8mkKrRLNmGs/18ocOyCYPFwjxsqVaec1+eQhWI9uejduiYvk186gUll0F3Jb0PCgHmAvAsehWJr0YX9OU1MPORcYJrnytHCK0foG53NoHQCttgZ0rjOQhRcWMEmcmBaI6yna1wBBwHE5kwBxVm7UIfeRcdO0cLea/UwwHSz3Axbj+v9tE+rB5YsmJUuCfuumflIdAFIJWFngkV7+uzj+jlOZnEITc1jl72Fc/2lDCyEy5QM=; 25:Ivab7adXmR7Pn5I7Q28LvOIJlp1WX8WzyGT55qxIQxwd149YObVl6y2oINds+/98DidywELLSxwERMbawJoJyV4W4h6PtIISznQY3GWuVwu9aLv1c4aiLjRhkrOUQzqriIN4eXJodCvC9LoDkFuMGXv/dHgAAqAxJ3/D2TNamSEkBUshvRzhZBg9yAw0mw0MrztOgcJxAieojQv3buuMsW1YRu9rdxel42Z7HO09/9nKEXBn8NIQeXPaksTH4Z2yqeuayzdwo5YJfOimf9t4BBHXqSQ3+zUQPOPxLKDqZ3Kvk5GvqJWxETekBvqIrdaUXlkZDbaDfPSyK9A+Pr0dYQ== X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0041; 31:EKTe2xBmYVcmsuokCd9SQ4ONP2e49UOPTq4tP14ursmHLmq+A9cCDofTQKcCz8ujF62b0A3J5GS8788urn5MW7U+TxQrawYZIkjN7QArbP1jI2ygIyPPd6BH3KKn/PTXgcd/hGJcs76NbC3UNI3YouRm6pNmVbkTUz/vn0SyImRz38IyiUbRLOFulXULXqSKplBpgV9TDeB1B33cWovUccLguHzRLZtLj3hZ6ozgEY0=; 20:VMLzDAKVI+ZkxurC9GbPxSTgl6Yyqjr9Qa+9lEDU0cpog0MRIDdJIWM0b/CvdJQwFp3t5Yr7iGIYRjt7EpUi+fJE18T5lUU6X14/sCcOUyBDhGesN95Fmclhxp2p1GnVlSYTQU76koMTSg1YRmIjazi5JrPPP2mV/1kCe8fyoPs3LM/vOBo6WJr8fxMmv1T3culGPSyOAtnhiO3M67wOz8asp+jJWVLqmUAMYNWRsvtuHRrFVtyOAsWi7tAT0svJ9e4rT86VLPkNNMrt9UCBG39jDuK/1X85ifxly4XF3onV8eltl1EGyOlAOnfb6W2ySt9UjrkY3lLFlscn2sGC8m+LUXMSnHovLJs0yVy0uriXCyjrcJZwRRyn7y/bDzSouKqvDoesV4k2d+ZkrdqVOEm8GjS2KR+m+UXug/COm2gFu6Fgeen8aFlvMOOP/lDMYYEHR7nTgL71Md8fTUm471GdJFIk/ZqLPvAj0krp+OJOdlHLp1MhTzo6tJKY7Fd5bsxZ7KpDZkQ4xh4vdvV/B/udmd5YCW1dVtUx2ICzq2Oh9XSnMCxYBX/NN7ZUJgHx39uHJZ90doxsM8jkhQWUXdb/0DD/s1tGbgWqENj4hgQ= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0041; 4:1imD3S5VDac3CSQ+9w+I/5la0n+1W7Ye5k7qpsiKeOY8A2aOznHSOsh62p3COKspXs0fFqI4t06pPw0BAYzyJWcEwXfz5JQezVdgcoABkohRfctzauTS7FmKC4vbI/ryCUvFdKo4tzAL32WYm0fq1RIo+/iB3SHeWsXRS0Qdq/PJJm69nh5kMq+Z15kILVAYtMMr2+JmfqxHAeTmDRuY0yYfC473RxS10+rC68FhkhWHL/h0n1CtRe4Y3/6mN8zRPXdzZpAGpgQ9Wo2hVkE3L6yL4xe8VV6hQNpaKoCyNNnb7dpTKRKzrnGxHdMbP9ii3lV3+9il+DBCniUehOsQFNMTxeglKfyO6Tuo4Shg2OtGIk2sXvJjHxPYxXM6Udy2nv6Ycgx8BqkZwD36JkGGSiBbcIypUs1TWuxpHjymTnqh0IFgToLrYuVs8VKRhYJ+pqGOsrb1wVAHGlMu+8lCdGKdUJxlzk/5qp6zmoNYBoUVWEx5pFhdmcdMTGN1/NGeDFJG2KKA21YIfRdm5OYsGQ== X-Forefront-PRVS: 0604AFA86B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1P121MB0041; 23:g3RnECzxaAd4sno7cHPD+wjyXQAQ577g3JIra5Rcf?= =?us-ascii?Q?kpC4TTDYFGVKa91x/Yfihi7ncgz0i+53qPOSdm97rtLfX+QEq6V0LInDFdRe?= =?us-ascii?Q?3QTUFdRZtvsD4ZWJxERYEPwOlpirVEv9E8Nhz8osVh0iug80A+jcVHeZ+8qd?= =?us-ascii?Q?wdXb38wy8tSEr5HWcRMVv8J3oR6V0ih/qoH57y/m843uilVpqWXl+OWNXI0Q?= =?us-ascii?Q?oyIAE8nV1wEWzF5S260EpSWvCEPysFv44ibtlbNFc9e8+BLuT6zz9bRvviDj?= =?us-ascii?Q?gNZhJM1JN2zue69c85p09ZLxXPn6APEaJC7fLi24zrcmbBviVC31yDJvLWWS?= =?us-ascii?Q?yLZYCK+M1azPpfllT4N5NE3J3qW2Z3h7aNKBnPDXARIHyasIOcPKKAgzBL4B?= =?us-ascii?Q?9nSF6ZtAwxB+B1LO9xIlkyy/9JEYR4WEnp5wb4UfPJg1KUtYx2nImJmp4Sri?= =?us-ascii?Q?M2iH9g20eIVnCL/sEPjFhSawAijLIrY3qgj2Dm9hKIFwuB320/MllD27qTWR?= =?us-ascii?Q?/OQv1X0Q3t4TduaBYX88I79Yy/GR/J9RiqpHtUDAMQyHTY//AEsMGUtSkt+r?= =?us-ascii?Q?FQiKNeCV53GTW41WjJ2JICqr1hlRt57swOra/gaOY2c/yvfWkzy+WpreoY2/?= =?us-ascii?Q?TOrPDe1KwKjKDEQTNUqovfuzK5rqUvOEXvjjSQmVqYQkYhzA5Xlt7w6F3/vf?= =?us-ascii?Q?dLLSj8JfY1RB2LrgkyU8Fs4AcRG+vQ3eIGivi1iEOeKzVnOX83XUdOqOiKnF?= =?us-ascii?Q?oZNvRaPEtI3Bx/ZymUzVwcsUpxSDEZGHeYO3lrZ0guhyFN1VzgfSPaReN6Ta?= =?us-ascii?Q?OjvR0tTq0c64C9yX69EUhaM+le5IYaxuw8r+gjqqJu5bc5Fo8ZBBu8ZjvrOs?= =?us-ascii?Q?2OcP+c3SrejDYTx1i/x3ZyUceQoDLMAqDTY4l2hzeJ2heJ56ozJg+Ojcx9DO?= =?us-ascii?Q?SmED4xxPYDW3FTipUYtl8+/TPVvNnPpA2MTSeOVXJ5pWiRO/oiMMpGfvJFgI?= =?us-ascii?Q?Gzp/cqMN11aDgaBYoRd0VFJ4fydySt7tPcHlt1h5xdAure/kj8rUCbJzasEV?= =?us-ascii?Q?MxH65qPi1pgfwvD4qrj/fKWpUdYC/C0lul4dYtk6VTgdjr2Y+Ux/XXlB7K2S?= =?us-ascii?Q?KHtvNhNdY0kZwOFPPEC2B2AKd9GthMPJwxYuZoOBFO6qnurV+mmOzGCEewyl?= =?us-ascii?Q?h/nq4mEuG51L2/3J3L+buZBqKm6RFyLGRKLI7HsobeF8LX9vS5wbreVP15Ll?= =?us-ascii?Q?GaB4gwLge2qeH5iLUpmPVoyrnY94QUMKjCRdh0VfSo2/bUm8BTKQhyB6V41w?= =?us-ascii?Q?rDcSky86H/DChpcx77Tc5yJcDnGrr825KHqMCfzQOnaCS9f2omGoebEr77ps?= =?us-ascii?Q?i8wWLRdVsbR+XxOsLxxgI3J+rnAk4piTfLzIF83C0PGsYEV+x2IeOkflNWrD?= =?us-ascii?Q?3dFWrbm3vVmEOyrUTOubSt9jW5zkvotimKWWzOM7vB5TFSZ/NX/?= X-Microsoft-Antispam-Message-Info: GnsD3L4XRn0hc1BVb9GhwJDU7stpPxeNZyniOCoBnMVMZHFa/ExsZVr9TxLmFXEG173pR6l5ThPg+0XlDMw9pHcDaFVW1zEobao4af+NWvOgA/dY3OPU0slrjZ3CSQulFd3oEcW7HxEPJLd+5qdIDUxcKRAd/8Le/1cjhr+90jopzVGP8v9ukNgDuBzsZQwlYnOCzx0oS5PYiUJBsELUKPyoA436TpjlmlV6cb3hMJBpB0vTzFysNj4XZRKP+4V1vCm5fUdxVo/lSSZQdW4AfUCiHpLHAMsrgqDHNAK6HAHGqjdUEpuf/p0nsy18O5RaxlwofN91e4pbPxxI79FCHA== X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0041; 6:vai//N0dREqlU2AGtaxCIsZIohx6GJelZ1bPexieCD6Uq3suKBu91vrqPkSC2P71JY5woKXOtSLuwC+s0dlD5QgP7ehrmE6ZbDXKkJgkTOK3JVJbRXoNUqLDoEAz9zgX31g0nrqqyOo5O1ohDQX9AAaBq5vGVjuZ5s6eMKYKOIUjQRg/CpAtnwhwlggOgQTiiZGf5eiG5XwcanhNb6/iCuCAzWPlXsduNRs3dLloDffAxFsDxiAtIZ6Vq05yQTAcXSgFP2WPNu7BZ5B/LCGEcT3N0e74LYx/wL6fYfoyqDDoI8ZoqO4MZzn05vCZJvVRNoPnAEE6yMz9k82N7C9pq2YFwAIDCltsft+l0RbBVIyO64vZqZNco1sEs3r4KawTwke2G4/L8E72J8i7f541fw==; 5:pzZPrwBTc1r7qd6dOS5sjOkShdw2Rna6VgOYSF5KnZqr4newd1F3gaUVcYKCmvlOSRWKjpoClICfHnvw04/6jEi46opQC1rE9K4JoBMdY7F1ulroJzUEG9Knp8UiTe4ikgwFPUpTICi0XY5rXRmuWCtnGOnUW6v3md5d2AlZfaw=; 24:IMpxVlm8S50KnrNOEGsKqAwWfx+gDYP6KjXA+OSfEn2WRZQd09tmoMB7mY6Y0AFf5v+G8rOFMnZ0rh2iCwNl8I12siNGJYGoNo6a808Uxok= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0041; 7:NrFqMd+sDJRFnyrDhDHZ1Qz4yOTmFGa9vmx7YFyivH5Q3wTLKL2mp9OZ7uypBAtVToLsQcM6ECm65XOaqm4JflDmFv0ZhcJ2pE/wwm0GaUHVGVdWgxudduvVwVOVr4FY9QG2oPQwval6nAOVqzaOOH8yTO/D5thGCkY43DCpY9wVmDkC441ifiq4wfjf9gzu0B3NEoCjjK+38ZZu73LV1RobL5WDwfvqLI5zSuBZOnjg5kmcDRPH5Zd2mbdNBbU+ X-OriginatorOrg: lightingaad.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2018 08:29:39.2705 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 797a78b6-6898-48bc-f0c7-08d584059180 X-MS-Exchange-CrossTenant-Id: 75b2f54b-feff-400d-8e0b-67102edb9a23 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=75b2f54b-feff-400d-8e0b-67102edb9a23; Ip=[40.115.29.120]; Helo=[LIGHT-EDGE-1.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0041 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-tilo?= =?utf-8?q?ca-core-multicast-oscoap?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Mar 2018 08:29:47 -0000 --_000_VI1P121MB001470B4EE2FE2E26E5E19DB9BD80VI1P121MB0014EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1hcmNvLA0KDQpUaGlzIHVwZGF0ZSBzb2x2ZXMgdGhlIGlzc3VlcyBJIHRoaW5rIGFu ZCBhbnN3ZXJzIG15IHF1ZXN0aW9ucywgZXhjZXB0IGZvciB0aGUgcmFuZG9tbmVzcyBpbiB0aGUg R2lkOiAg4oCcQSBHaWQgTVVTVCBoYXZlIGEgcmFuZG9tIGNvbXBvbmVudCBhbmQgYmUgbG9uZyBl bm91Z2gsIGluIG9yZGVyIHRvIGFjaGlldmUgYSBuZWdsaWdpYmxlIHByb2JhYmlsaXR5IG9mIGNv bGxpc2lvbnMgYmV0d2VlbiBHcm91cCBJZGVudGlmaWVycyBmcm9tIGRpZmZlcmVudCBHcm91cCBN YW5hZ2Vyc+KAnTsgYW5kIEFwcGVuZGl4IEMuDQoNClRoZSBleGFtcGxlIEFwcGVuZGl4IEMgdXNl cyBhIHNpbmdsZSByYW5kb20gYnl0ZS4gIE1vc3QgcGVvcGxlIHdvdWxkIHRoaW5rIHRoZSBjb2xs aXNpb24gcHJvYmFiaWxpdHkgaXMgcXVpdGUgaGlnaCBpbiB0aGlzIGNhc2U7IHNvIGhvdyBjYW4g dGhpcyBjaG9pY2Ugc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnQ/ICBNYXliZSBpbiB0aGlzIGV4YW1w bGUgdGhlIEdyb3VwIE1hbmFnZXJzIHBpY2sgYSByYW5kb20gdmFsdWUgYW5kIHRoZW4gbXV0dWFs bHkgdmVyaWZ5IHRoYXQgdGhlcmUgYXJlIG5vIGNvbGxpc3Npb25zPw0KDQpUaGUgbmFtZSDigJxH cm91cCBFcG9jaOKAnSBjb3VsZCBiZSBzbGlnaHRseSBjb25mdXNpbmcgaGVyZSDigJMgQXBwZW5k aXggQyBzdGF0ZXMgdGhlIGVwb2NoIGFwcGxpZXMgdG8gYSBzaW5nbGUgZ3JvdXAuIEhvd2V2ZXIg dGhlIGV4YW1wbGUgdGhlcmUgc2hvd3MgdGhlIGVwb2NoIGFwcGxpZXMgdG8gYWxsIGdyb3VwcyBm cm9tIHRoZSBzYW1lIEdyb3VwIE1hbmFnZXIsIG9yIGluIG90aGVyIHdvcmRzIHRoZSBlcG9jaCAq aXMqIHRoZSBncm91cC4gKEJlY2F1c2UgdGhlcmUgaXMgbm8gdGhpbmcgbGlrZSDigJxHcm91cCBJ ROKAnSBpbiB0aGUgZXhhbXBsZSwgb25seSBHTSByYW5kb20gYnl0ZSBhbmQgR3JvdXAgRXBvY2gg Ynl0ZXMuKSAgV2FzIGl0IGludGVuZGVkIHRvIGFkZCBhIGJ5dGUgb3Igc28gZm9yIOKAnEdyb3Vw IElE4oCdID8gU28gdGhhdCBlYWNoIGdyb3VwIGNhbiBoYXZlIGl0cyBvd24gZXBvY2ggY291bnRl ci4NCg0KRXNrbw0KDQoNCg0KRnJvbTogTWFyY28gVGlsb2NhIDxtYXJjby50aWxvY2FAcmkuc2U+ DQpTZW50OiBNb25kYXksIE1hcmNoIDUsIDIwMTggMjM6MTgNClRvOiBFc2tvIERpamsgPGVza28u ZGlqa0BwaGlsaXBzLmNvbT47IEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6QGVyaWNzc29u LmNvbT47IGNvcmVAaWV0Zi5vcmcgV0cgKGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRp bG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXANCg0KDQpIZWxsbyBFc2tvLA0KDQoNCg0KVGhhbmtz IGZvciB5b3VyIHN1cHBvcnQgYW5kIGNvbW1lbnRzLCB3ZSBoYXZlIGNvbnNpZGVyZWQgdGhlbSB3 aGVuIHByb2R1Y2luZyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlICBkcmFmdCBbMV0uDQoNCg0K DQpQbGVhc2UsIGZpbmQgaW4gbGluZSBzb21lIGFuc3dlcnMgdG8geW91ciBjb21tZW50cy4NCg0K DQoNCkJlc3QsDQoNCi9NYXJjbw0KDQoNCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbS0wMQ0KDQpPbiAyMDE3LTEyLTA0IDE0 OjM1LCBFc2tvIERpamsgd3JvdGU6DQpJIGFsc28gc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhp cyBkcmFmdCBhcyBhIHdvcmsgaXRlbSBmb3IgQ29SRS4gQmVsb3cgYXJlIHRoZSByZXN1bHRzIG9m IGEgcXVpY2sgcmV2aWV3LCBhbHNvLg0KDQpCZXN0IHJlZ2FyZHMNCkVza28gRGlqaw0KDQoNCk92 ZXJhbGwgY29tbWVudHMg4oCTIG9yIHdvcmsgdGhhdCB0aGUgV0cgY291bGQgdGFrZSB1cCBuZXh0 DQrCtyAgICAgICAgIERldGFpbGVkIGV4YW1wbGUgd2l0aCBtZXNzYWdlIHNpemVzIHdvdWxkIGJl IHVzZWZ1bC4gU2luY2UgaXTigJlzIGltcG9ydGFudCBmb3IgbXVsdGljYXN0IG92ZXIgNmxvd3Bh biBwZXJmb3JtYW5jZSB0aGF0IHRoZSBJUHY2IHBhY2tldHMgc3RheSBzbWFsbCBlbm91Z2ggKG9u ZSA4MDIuMTUuNCBmcmFtZSkuIEF0IHRoaXMgbW9tZW50LCBJIGNhbuKAmXQganVkZ2UgdGhhdCB5 ZXQgZWFzaWx5IGJhc2VkIG9uIHRoZSBkcmFmdC4NCg0KDQpbTVRdIFdlIGhhdmUgbm93IGluY2x1 ZGVkIGRldGFpbGVkIGV4YW1wbGVzIGluIFNlY3Rpb25zIDMuMSAoUmVxdWVzdCkgYW5kIFNlY3Rp b24gMy4yIChSZXNwb25zZSkuDQoNCg0KwrcgICAgICAgICBOb3JtYWxseSwgZm9yIGFwcGxpY2F0 aW9ucyAoZS5nLiBCdWlsZGluZyBhdXRvbWF0aW9uIGFuZCBsaWdodGluZykgZ3JvdXBzIGRvIG5l ZWQgYSBzdGFibGUgYW5kIG5vbi1yYW5kb20gZ3JvdXAgSUQsIHRoYXQgaWRlbnRpZmllcyB0aGUg Z3JvdXAgb3ZlciB0aW1lIGV2ZW4gYXMgY2hhbmdlcyBvY2N1ciwgZS5nLiBtZW1iZXJzIGFkZGVk L3JlbW92ZWQuIFRoZSDigJxHaWTigJ0gaW4gdGhlIGRyYWZ0IGhvd2V2ZXIgY2hhbmdlcy4gVGhl cmUgY291bGQgYmUgc29tZSB0ZXh0IGFkZGVkIHRvIGV4cGxhaW4gaG93IEdpZCBpcyBsaW5rZWQg dG8gYSBzdGFibGUgSUQuIEUuZy4sIHRoaXMgY291bGQgYmUgY29uZmlndXJlZCBieSB0aGUgR3Jv dXAgTWFuYWdlci4gVGhlIHN0YWJsZSBncm91cCBJRCBpcyB0aGVuIG5vdCB1c2VkIG92ZXItdGhl LXdpcmUgZm9yIG11bHRpY2FzdCBPU0NPUkUuDQoNCg0KW01UXSBJdCBpcyB0cnVlIHRoYXQgdGhl IEdpZCBpbiB0aGlzIGRyYWZ0IGNoYW5nZXMgb3ZlciB0aW1lLCBlc3BlY2lhbGx5IHVwb24gcmVu ZXdpbmcgdGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbCwgYW5kIHRoZSBHcm91cCBNYW5hZ2VyIGlz IHRoZSBvbmx5IHJlc3BvbnNpYmxlIGZvciBtYW5hZ2luZyBpdHMgdmFsdWUgdXBkYXRlLiBIb3dl dmVyLCB0aGlzIEdpZCBoYXMgdG8gYmUgaW50ZW5kZWQgYXMgdGhlIGlkZW50aWZpZXIgb2YgdGhl IE9TQ09SRSDigJxzZWN1cml0eSBncm91cOKAnSwgaW5jbHVkaW5nIGFzIG1lbWJlcnMgdGhlIGVu ZHBvaW50cyB0aGF0IHNoYXJlIHRoZSBzYW1lIENvbW1vbiBTZWN1cml0eSBDb250ZXh0Lg0KDQpb TVRdIEFzIHlvdSBzYXksIGFwcGxpY2F0aW9ucyBkbyByZWx5IG9uIGEgc3RhYmxlIGFuZCBub24t cmFuZG9tIGdyb3VwIElELCB3aGljaCBpcyBub3QgdXNlZCBvdmVyLXRoZS13aXJlIGZvciBncm91 cCBPU0NPUkUsIGFuZCBpbnN0ZWFkIGlkZW50aWZpZXMgYW4g4oCcYXBwbGljYXRpb24gZ3JvdXDi gJ0gaGF2aW5nIGFzIG1lbWJlcnMgdGhlIGVuZHBvaW50cyB0aGF0IHBhcnRpY2lwYXRlIGluIGEg c2FtZSBncm91cCBhcHBsaWNhdGlvbi4gVGhlcmUgaXMgbm8gcmVsYXRpb24gYmV0d2VlbiB0aGlz IGFwcGxpY2F0aW9uLWxldmVsIGdyb3VwIElEIGFuZCB0aGUgT1NDT1JFIEdpZCBkZWZpbmVkIGlu IHRoaXMgZHJhZnQuIEhvd2V2ZXIsIG9uZSBtYXkgcG9zc2libHkgbWFwIG11bHRpcGxlIOKAnGFw cGxpY2F0aW9uIGdyb3Vwc+KAnSB0byB0aGUgc2FtZSDigJxzZWN1cml0eSBncm91cOKAnS4NCg0K W01UXSBJbiBvcmRlciB0byBjbGFyaWZ5IHRoaXMgcG9pbnQsIHdlIGluY2x1ZGVkIGFsc28gYSBk ZWZpbml0aW9uIG9mIOKAnEdyb3Vw4oCdIGFuZCDigJxHcm91cCBJROKAnSBpbiBTZWN0aW9uIDEu MS4NCg0KDQrCtyAgICAgICAgIFRoZXJlIGlzIG5vcm1hdGl2ZSB0ZXh0IGluIHRoZSBBcHBlbmRp Y2VzOyBpdCBjb3VsZCBiZSBjbGFyaWZpZWQgd2hhdCB0aGUgc3RhdHVzIG9mIHRoaXMgaXMuIEUu Zy4gb25seSBub3JtYXRpdmUgaWYgb25lIGNob29zZXMgdG8gaW1wbGVtZW50IHRoZSBvcHRpb25h bCBlbGVtZW50IGRlc2NyaWJlZCBpbiB0aGUgQXBwZW5kaXg/SSBoYXZlIGEgcHJlZmVyZW5jZSBm b3IgYXZvaWRpbmcgbm9ybWF0aXZlIHRleHQgaW4gdGhlIEFwcGVuZGljZXMsIGJ1dCBJ4oCZbSBj dXJpb3VzIHRvIGhlYXIgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCltNVF0gV2UgcmVsYXhlZCB0aGUg dGV4dCBpbiBBcHBlbmRpY2VzIHRvIGF2b2lkIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCB3aXRoIHRo ZSBleGNlcHRpb24gb2YgYSDigJxOT1QgUkVDT01NRU5ERUTigJ0gaW4gY3VycmVudCBBcHBlbmRp eCBGIOKAnE5vIFZlcmlmaWNhdGlvbiBvZiBTaWduYXR1cmVz4oCdLg0KDQoNCsK3ICAgICAgICAg VGhlIHRleHQgc29tZXRpbWVzIHN1Z2dlc3RzIHRoYXQgYSBzZWN1cmUgZ3JvdXAgY29udGV4dCBp cyBsaW5rZWQgdG8gb25lIGFuZCBvbmx5IG9uZSBtdWx0aWNhc3QgSVAgYWRkcmVzcy4gSW4gcHJh Y3RpY2UsIHRoZXJlIG1heSBiZSBtb3JlIHZhcmlldHkg4oCTIGUuZy4gb25lIG11bHRpY2FzdCBJ UCBhZGRyZXNzIHBsdXMgb25lIG9yIG1vcmUgdW5pY2FzdCBJUCBhZGRyZXNzZXMgdG8gd2hpY2gg dGhlIGdyb3VwIG1lc3NhZ2UgaXMgc3Vic2VxdWVudGx5IGRlbGl2ZXJlZC4gRS5nLiByZXBlYXQg b2YgdGhlIGdyb3VwIG1lc3NhZ2UgdG8gbWVtYmVycyB3aGljaCBkaWQgbm90IGdldCBpdCB5ZXQu IFRoZSBwcm9wb3NlZCBzb2x1dGlvbiBjb3VsZCBiZSByZXZpZXdlZCB3aXRoIHRoYXQgdmlldyBp biBtaW5kLCB0aGF0IHRoZXJlIG1heSBiZSBtdWx0aXBsZSAobXVsdGljYXN0L3VuaWNhc3QpIElQ IGRlc3RpbmF0aW9uIGFkZHJlc3NlcyB0byB3aGljaCBhIGdyb3VwIG1lc3NhZ2Ugd2lsbCBiZSBz ZW50LiBJIGRpZCBub3QgZG8gdGhhdCB5ZXQ7IGNhbiBkbyBzbyBpbiBhIGZ1dHVyZSBpbi1kZXB0 aCByZXZpZXcuDQoNCg0KW01UXSBUaGFua3MsIHRoYXTigJlzIGEgdmVyeSBnb29kIGNvbW1lbnQu IFdl4oCZbGwgdGhpbmsgbW9yZSBvbiB0aGUgcG9zc2libGUgdmlldyB5b3UgcHJvcG9zZS4gSXQg c2hvdWxkIGJlIGZpbmUgYXMgbG9uZyBhcyBhIHJlY2lwaWVudCBpcyBhYmxlIHRvIHJldHJpZXZl IHRoZSByaWdodCBncm91cCBTZWN1cml0eSBDb250ZXh0LCBieSB1c2luZyB0aGUgR2lkLg0KDQoN Cg0KU2VjdGlvbiAyLjENClNvbWUgdGhpbmdzIGhlcmUgYXJlIGxpc3RlZCBhcyBvdXQgb2Ygc2Nv cGUsIGJ1dCB0aGV5IGRvIGNvbWUgYmFjayBsYXRlciBpbiB0aGUgZG9jIOKAkyBzdWNoIGFzIGZv cndhcmQgc2VjdXJpdHkgYW5kIGJhY2t3YXJkIHNlY3VyaXR5ICwgd2hpY2ggYXJlIGFkZHJlc3Nl ZCBJIHRoaW5rIOKAkyBjZXJ0YWlubHkgbm90IG91dCBvZiBzY29wZS4NCg0KDQpbTVRdIEdyb3Vw IE9TQ09SRSBkb2VzIG5vdCBlbnN1cmUgZm9yd2FyZCBzZWN1cml0eSBhbmQgYmFja3dhcmQgc2Vj dXJpdHkgaXRzZWxmLiBJbnN0ZWFkLCB0aGV5IGFyZSBlbnRydXN0ZWQgdG8gdGhlIHNwZWNpZnlp bmcgZ3JvdXAgcmVrZXlpbmcgcHJvdG9jb2wgZW5mb3JjZWQgYnkgdGhlIEdyb3VwIE1hbmFnZXIu IFRoZSBzcGVjaWZpYyByZWtleWluZyBwcm90b2NvbCBpZiBvdXQgb2Ygc2NvcGUgZm9yIEdyb3Vw IE9TQ09SRSwgd2hpY2ggaG93ZXZlciByZWNvbW1lbmRzIHRoZSB1c2Ugb2Ygb25lIGFibGUgdG8g ZW5zdXJlIGJhY2t3YXJkIGFuZCBmb3J3YXJkIHNlY3VyaXR5IGluIHRoZSBncm91cC4NCg0KDQoN ClNlY3Rpb24gMw0KIiBHaWQgTVVTVCBiZSByYW5kb20gIiAtPiBzZWVtcyB0byBjb250cmFkaWN0 IEFwcGVuZGl4IEIgd2hpY2ggdXNlcyBhbiBFcG9jaCBjb3VudGVyIGluIHRoZSBHaWQuICBTaG91 bGQgaXQgc2F5IOKAnE1VU1QgaGF2ZSBhIHJhbmRvbSBjb21wb25lbnTigJ0gPw0KDQoNCltNVF0g UmlnaHQsIG5vdyBmaXhlZCAoaW4gY3VycmVudCBBcHBlbmRpeCBDKS4NCg0KDQoNCkFwcGVuZGlj ZXMNCg0KICAqICAgQXBwZW5kaXggQiwgYSBjb25jcmV0ZSBleGFtcGxlIGluc3RhbmNlIGlzIG1p c3NpbmcuIEUuZy4g4oCcdzNmajkwZjBhXzAwNDLigJ0gb3IgaXRzIGJzdHIgZXF1aXZhbGVudCAg KGp1c3QgZ3Vlc3NpbmcgaGVyZSB0byB0aGUgZm9ybWF0KQ0KDQoNCltNVF0gV2UgYWRkZWQgYW4g ZXhhbXBsZSwgaW4gY3VycmVudCBBcHBlbmRpeCBDLg0KDQoNCg0KICAqDQogICogICBBcHBlbmRp eCBDLCBpcyB0aGlzIGFuIGV4YW1wbGUgYmx1ZXByaW50IG9mIGhvdyB0byBkbyBpdCDigJMgZnVs bHkgb3B0aW9uYWwgdG8gZm9sbG93IG9yIG5vdCBmb2xsb3cgdGhpcz8NCg0KDQpbTVRdIFdlIHJl bGF4ZWQgdGhlIHRleHQgaW4gY3VycmVudCBBcHBlbmRpeCBELCBhcyBmb3IgdGhlIHRpbWUgYmVp bmcgaXQgaXMgaW50ZW5kZWQgdG8gYmUgYSBndWlkZWxpbmUgZXhhbXBsZS4NCg0KDQoNCiAgKg0K DQpNaW5vcg0KDQogICogICBsaWd0aGluZyAtPiBsaWdodGluZw0KICAqICAgZW5wb2ludCAgLT4g ZW5kcG9pbnQNCiAgKiAgIFBnIDI1ICwgW0ktRC5pZXRmLWFjZS1kdGxzLWF1dGhvcml6ZV0gcmVm ZXJlbmNlIGJyZWFrcyBhY3Jvc3MgbGluZSBhbmQgYXMgc3VjaCBiZWNvbWVzIG5vbi1zZWFyY2hh YmxlIGluIHRoZSBicm93c2VyLiBBbmQgSSBsaWtlIHRoZXNlIHJlZnMgdG8gYmUgc2VhcmNoYWJs ZSDwn5iJDQoNCg0KDQoNCg0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEphaW1lIEppbcOpbmV6DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIg MjMsIDIwMTcgMTc6NTkNClRvOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPiBX RyAoY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4pIDxjb3JlQGlldGYub3JnPjxt YWlsdG86Y29yZUBpZXRmLm9yZz4NCkNjOiBqaS15ZS5wYXJrQHVuaS1kdWUuZGU8bWFpbHRvOmpp LXllLnBhcmtAdW5pLWR1ZS5kZT4NClN1YmplY3Q6IFtjb3JlXSDwn5SUIFdHIENhbGwgZm9yIEFk b3B0aW9uIG9uIGRyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXANCg0KRGVhciBhbGws DQoNClRoZSBkcmFmdCBvbiAiU2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24gZm9yIENvQVAiICgg ZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcDxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC8+ICkgaGFkIGluIHJvb20g Y29uc2Vuc3VzIGZvciBhZG9wdGlvbiBkdXJpbmcgSUVURjk5IGFscmVhZHksIG5vdyB3ZSBhcmUg Y2xlYXIgdG8gY29uZmlybSBpdCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpQbGVhc2UgcmVwbHkg dG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxp bWl0ZWQgdG8gd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3Jz IGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCg0KVGFyZ2V0IHRvIGVuZCB0 aGUgV0dBIGlzIDE0dGggb2YgRGVjZW1iZXIuDQoNCkNpYW8sDQotIC0gSmFpbWUgSmltw6luZXoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIGVtYWlsIG1heSBiZSBjb25maWRlbnRpYWwgYW5kL29yIGxlZ2FsbHkg cHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGlu ZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgZW1haWwuDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmNvcmUg bWFpbGluZyBsaXN0DQoNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQoNCg0KLS0NCg0KTWFy Y28gVGlsb2NhLCBQaEQNCg0KUmVzZWFyY2ggSW5zdGl0dXRlcyBvZiBTd2VkZW4NCg0KUklTRSBJ Q1QvU0lDUw0KDQpJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KDQpTRS0xNjQg NDAgS2lzdGEgKFN3ZWRlbikNCg0KUGhvbmU6ICs0NiAoMCk3MCA2MCA0NiA1MDENCg0KaHR0cHM6 Ly93d3cuc2ljcy5zZQ0KDQoNCg0KVGhlIFJJU0UgaW5zdGl0dXRlcyBJbm52ZW50aWEsIFNQIGFu ZCBTd2VkaXNoIElDVA0KDQpoYXZlIG1lcmdlZCBpbiBvcmRlciB0byBiZWNvbWUgYSBzdHJvbmdl ciByZXNlYXJjaA0KDQphbmQgaW5ub3ZhdGlvbiBwYXJ0bmVyIGZvciBidXNpbmVzc2VzIGFuZCBz b2NpZXR5Lg0KDQoNCg0KU0lDUyBTd2VkaXNoIElDVCBBQiwgaGFzIG5vdyBjaGFuZ2VkIG5hbWUg dG8gUklTRSBTSUNTIEFCLg0K --_000_VI1P121MB001470B4EE2FE2E26E5E19DB9BD80VI1P121MB0014EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJbGluZS1oZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1oZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWxpbmUtaGVpZ2h0OjEyMCU7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglsaW5l LWhlaWdodDoxMjAlOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ3ODE1MjA5NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTE5MjkxMTQ1Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE0OTI5ODQ1 NzE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTM3 NDc5MjM0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE2MzIxMjU2 MzE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjk4OTAyNzI0O30NCkBsaXN0IGwyOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDMNCgl7bXNvLWxpc3QtaWQ6MTY5OTYxODE0NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIy MjExODU4Njt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjE5NzMyOTE1MzA7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDc1OTQ1NTM2O30NCkBsaXN0IGw0OmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7 bXNvLWxpc3QtaWQ6MjA0MjI0MjAzNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUzMzQwOTIy ODt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1Omxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1 OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoYW5r cyBNYXJjbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoaXMg dXBkYXRlIHNvbHZlcyB0aGUgaXNzdWVzIEkgdGhpbmsgYW5kIGFuc3dlcnMgbXkgcXVlc3Rpb25z LCBleGNlcHQgZm9yIHRoZSByYW5kb21uZXNzIGluIHRoZSBHaWQ6ICZuYnNwO+KAnEEgR2lkIE1V U1QgaGF2ZSBhIHJhbmRvbSBjb21wb25lbnQgYW5kIGJlIGxvbmcgZW5vdWdoLCBpbiBvcmRlciB0 byBhY2hpZXZlIGEgbmVnbGlnaWJsZSBwcm9iYWJpbGl0eSBvZg0KIGNvbGxpc2lvbnMgYmV0d2Vl biBHcm91cCBJZGVudGlmaWVycyBmcm9tIGRpZmZlcmVudCBHcm91cCBNYW5hZ2Vyc+KAnTsgYW5k IEFwcGVuZGl4IEMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5U aGUgZXhhbXBsZSBBcHBlbmRpeCBDIHVzZXMgYSBzaW5nbGUgcmFuZG9tIGJ5dGUuJm5ic3A7IE1v c3QgcGVvcGxlIHdvdWxkIHRoaW5rIHRoZSBjb2xsaXNpb24gcHJvYmFiaWxpdHkgaXMgcXVpdGUg aGlnaCBpbiB0aGlzIGNhc2U7IHNvIGhvdyBjYW4gdGhpcyBjaG9pY2Ugc2F0aXNmeSB0aGUgcmVx dWlyZW1lbnQ/Jm5ic3A7IE1heWJlIGluIHRoaXMgZXhhbXBsZSB0aGUgR3JvdXANCiBNYW5hZ2Vy cyBwaWNrIGEgcmFuZG9tIHZhbHVlIGFuZCB0aGVuIG11dHVhbGx5IHZlcmlmeSB0aGF0IHRoZXJl IGFyZSBubyBjb2xsaXNzaW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPlRoZSBuYW1lIOKAnEdyb3VwIEVwb2No4oCdIGNvdWxkIGJlIHNsaWdodGx5IGNvbmZ1 c2luZyBoZXJlIOKAkyBBcHBlbmRpeCBDIHN0YXRlcyB0aGUgZXBvY2ggYXBwbGllcyB0byBhIHNp bmdsZSBncm91cC4gSG93ZXZlciB0aGUgZXhhbXBsZSB0aGVyZSBzaG93cyB0aGUgZXBvY2ggYXBw bGllcyB0byBhbGwgZ3JvdXBzIGZyb20gdGhlIHNhbWUgR3JvdXAgTWFuYWdlciwNCiBvciBpbiBv dGhlciB3b3JkcyB0aGUgZXBvY2ggKjxiPmlzPC9iPiogdGhlIGdyb3VwLiAoQmVjYXVzZSB0aGVy ZSBpcyBubyB0aGluZyBsaWtlIOKAnEdyb3VwIElE4oCdIGluIHRoZSBleGFtcGxlLCBvbmx5IEdN IHJhbmRvbSBieXRlIGFuZCBHcm91cCBFcG9jaCBieXRlcy4pJm5ic3A7IFdhcyBpdCBpbnRlbmRl ZCB0byBhZGQgYSBieXRlIG9yIHNvIGZvciDigJxHcm91cCBJROKAnSA/IFNvIHRoYXQgZWFjaCBn cm91cCBjYW4gaGF2ZSBpdHMgb3duIGVwb2NoIGNvdW50ZXIuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Fc2tvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBNYXJjbyBUaWxvY2EgJmx0O21hcmNv LnRpbG9jYUByaS5zZSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDUsIDIw MTggMjM6MTg8YnI+DQo8Yj5Ubzo8L2I+IEVza28gRGlqayAmbHQ7ZXNrby5kaWprQHBoaWxpcHMu Y29tJmd0OzsgSmFpbWUgSmltw6luZXogJmx0O2phaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tJmd0 OzsgY29yZUBpZXRmLm9yZyBXRyAoY29yZUBpZXRmLm9yZykgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPiYjMTI4Mjc2Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFdH IENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnki PkhlbGxvIEVza28sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+VGhhbmtzIGZvciB5b3VyIHN1cHBvcnQgYW5kIGNvbW1lbnRzLCB3ZSBoYXZlIGNvbnNp ZGVyZWQgdGhlbSB3aGVuIHByb2R1Y2luZyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlJm5ic3A7 IGRyYWZ0IFsxXS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij5QbGVhc2UsIGZpbmQgaW4gbGluZSBzb21lIGFuc3dlcnMgdG8geW91ciBjb21tZW50cy48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij5CZXN0LDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPi9NYXJjbzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPlsxXSA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9zY29yZS1n cm91cGNvbW0tMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUt b3Njb3JlLWdyb3VwY29tbS0wMTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gMjAxNy0xMi0wNCAxNDozNSwgRXNrbyBEaWprIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBzdXBwb3J0IHRoZSBhZG9wdGlvbiBv ZiB0aGlzIGRyYWZ0IGFzIGEgd29yayBpdGVtIGZvciBDb1JFLiBCZWxvdyBhcmUgdGhlIHJlc3Vs dHMgb2YgYSBxdWljayByZXZpZXcsIGFsc28uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVz dCByZWdhcmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Fc2tvIERpams8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PdmVyYWxsIGNvbW1lbnRzIOKAkyBvciB3b3JrIHRoYXQgdGhlIFdHIGNvdWxk IHRha2UgdXAgbmV4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzI7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkRldGFpbGVkIGV4YW1wbGUg d2l0aCBtZXNzYWdlIHNpemVzIHdvdWxkIGJlIHVzZWZ1bC4gU2luY2UgaXTigJlzIGltcG9ydGFu dCBmb3IgbXVsdGljYXN0IG92ZXIgNmxvd3BhbiBwZXJmb3JtYW5jZSB0aGF0IHRoZSBJUHY2IHBh Y2tldHMgc3RheSBzbWFsbCBlbm91Z2ggKG9uZSA4MDIuMTUuNCBmcmFtZSkuIEF0IHRoaXMgbW9t ZW50LCBJIGNhbuKAmXQganVkZ2UgdGhhdCB5ZXQgZWFzaWx5IGJhc2VkDQogb24gdGhlIGRyYWZ0 LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5l LWhlaWdodDoxMjAlO2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTVRdIFdl IGhhdmUgbm93IGluY2x1ZGVkIGRldGFpbGVkIGV4YW1wbGVzIGluIFNlY3Rpb25zIDMuMSAoUmVx dWVzdCkgYW5kIFNlY3Rpb24gMy4yIChSZXNwb25zZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0Omw0IGxldmVsMSBsZm8yO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5Ob3JtYWxseSwgZm9yIGFwcGxpY2F0aW9ucyAoZS5nLiBCdWlsZGluZyBhdXRvbWF0aW9u IGFuZCBsaWdodGluZykgZ3JvdXBzIGRvIG5lZWQgYSBzdGFibGUgYW5kIG5vbi1yYW5kb20gZ3Jv dXAgSUQsIHRoYXQgaWRlbnRpZmllcyB0aGUgZ3JvdXAgb3ZlciB0aW1lIGV2ZW4gYXMgY2hhbmdl cyBvY2N1ciwgZS5nLiBtZW1iZXJzIGFkZGVkL3JlbW92ZWQuIFRoZSDigJxHaWTigJ0gaW4gdGhl IGRyYWZ0DQogaG93ZXZlciBjaGFuZ2VzLiBUaGVyZSBjb3VsZCBiZSBzb21lIHRleHQgYWRkZWQg dG8gZXhwbGFpbiBob3cgR2lkIGlzIGxpbmtlZCB0byBhIHN0YWJsZSBJRC4gRS5nLiwgdGhpcyBj b3VsZCBiZSBjb25maWd1cmVkIGJ5IHRoZSBHcm91cCBNYW5hZ2VyLiBUaGUgc3RhYmxlIGdyb3Vw IElEIGlzIHRoZW4gbm90IHVzZWQgb3Zlci10aGUtd2lyZSBmb3IgbXVsdGljYXN0IE9TQ09SRS48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1o ZWlnaHQ6MTIwJTtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01UXSBJdCBp cyB0cnVlIHRoYXQgdGhlIEdpZCBpbiB0aGlzIGRyYWZ0IGNoYW5nZXMgb3ZlciB0aW1lLCBlc3Bl Y2lhbGx5IHVwb24gcmVuZXdpbmcgdGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbCwgYW5kIHRoZSBH cm91cCBNYW5hZ2VyIGlzIHRoZSBvbmx5IHJlc3BvbnNpYmxlIGZvciBtYW5hZ2luZyBpdHMgdmFs dWUNCiB1cGRhdGUuIEhvd2V2ZXIsIHRoaXMgR2lkIGhhcyB0byBiZSBpbnRlbmRlZCBhcyB0aGUg aWRlbnRpZmllciBvZiB0aGUgT1NDT1JFIOKAnHNlY3VyaXR5IGdyb3Vw4oCdLCBpbmNsdWRpbmcg YXMgbWVtYmVycyB0aGUgZW5kcG9pbnRzIHRoYXQgc2hhcmUgdGhlIHNhbWUgQ29tbW9uIFNlY3Vy aXR5IENvbnRleHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+W01UXSBBcyB5b3Ugc2F5LCBhcHBsaWNhdGlvbnMgZG8gcmVseSBvbiBhIHN0YWJs ZSBhbmQgbm9uLXJhbmRvbSBncm91cCBJRCwgd2hpY2ggaXMgbm90IHVzZWQgb3Zlci10aGUtd2ly ZSBmb3IgZ3JvdXAgT1NDT1JFLCBhbmQgaW5zdGVhZCBpZGVudGlmaWVzIGFuIOKAnGFwcGxpY2F0 aW9uIGdyb3Vw4oCdIGhhdmluZyBhcw0KIG1lbWJlcnMgdGhlIGVuZHBvaW50cyB0aGF0IHBhcnRp Y2lwYXRlIGluIGEgc2FtZSBncm91cCBhcHBsaWNhdGlvbi4gVGhlcmUgaXMgbm8gcmVsYXRpb24g YmV0d2VlbiB0aGlzIGFwcGxpY2F0aW9uLWxldmVsIGdyb3VwIElEIGFuZCB0aGUgT1NDT1JFIEdp ZCBkZWZpbmVkIGluIHRoaXMgZHJhZnQuIEhvd2V2ZXIsIG9uZSBtYXkgcG9zc2libHkgbWFwIG11 bHRpcGxlIOKAnGFwcGxpY2F0aW9uIGdyb3Vwc+KAnSB0byB0aGUgc2FtZSDigJxzZWN1cml0eSBn cm91cOKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtsaW5lLWhlaWdodDoxMjAlO2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5bTVRdIEluIG9yZGVyIHRvIGNsYXJpZnkgdGhpcyBwb2ludCwgd2UgaW5jbHVkZWQgYWxz byBhIGRlZmluaXRpb24gb2Yg4oCcR3JvdXDigJ0gYW5kIOKAnEdyb3VwIElE4oCdIGluIFNlY3Rp b24gMS4xLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+VGhlcmUgaXMgbm9ybWF0aXZlIHRleHQgaW4gdGhlIEFwcGVuZGljZXM7IGl0 IGNvdWxkIGJlIGNsYXJpZmllZCB3aGF0IHRoZSBzdGF0dXMgb2YgdGhpcyBpcy4gRS5nLiBvbmx5 IG5vcm1hdGl2ZSBpZiBvbmUgY2hvb3NlcyB0byBpbXBsZW1lbnQgdGhlIG9wdGlvbmFsIGVsZW1l bnQgZGVzY3JpYmVkIGluIHRoZSBBcHBlbmRpeD9JIGhhdmUgYSBwcmVmZXJlbmNlIGZvciBhdm9p ZGluZyBub3JtYXRpdmUNCiB0ZXh0IGluIHRoZSBBcHBlbmRpY2VzLCBidXQgSeKAmW0gY3VyaW91 cyB0byBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCltNVF0gV2UgcmVsYXhlZCB0 aGUgdGV4dCBpbiBBcHBlbmRpY2VzIHRvIGF2b2lkIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCB3aXRo IHRoZSBleGNlcHRpb24gb2YgYSDigJxOT1QgUkVDT01NRU5ERUTigJ0gaW4gY3VycmVudCBBcHBl bmRpeCBGIOKAnE5vIFZlcmlmaWNhdGlvbiBvZiBTaWduYXR1cmVz4oCdLjwvc3Bhbj48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzI7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSB0ZXh0IHNvbWV0aW1l cyBzdWdnZXN0cyB0aGF0IGEgc2VjdXJlIGdyb3VwIGNvbnRleHQgaXMgbGlua2VkIHRvIG9uZSBh bmQgb25seSBvbmUgbXVsdGljYXN0IElQIGFkZHJlc3MuIEluIHByYWN0aWNlLCB0aGVyZSBtYXkg YmUgbW9yZSB2YXJpZXR5IOKAkyBlLmcuIG9uZSBtdWx0aWNhc3QgSVAgYWRkcmVzcyBwbHVzIG9u ZSBvciBtb3JlIHVuaWNhc3QgSVAgYWRkcmVzc2VzIHRvIHdoaWNoDQogdGhlIGdyb3VwIG1lc3Nh Z2UgaXMgc3Vic2VxdWVudGx5IGRlbGl2ZXJlZC4gRS5nLiByZXBlYXQgb2YgdGhlIGdyb3VwIG1l c3NhZ2UgdG8gbWVtYmVycyB3aGljaCBkaWQgbm90IGdldCBpdCB5ZXQuIFRoZSBwcm9wb3NlZCBz b2x1dGlvbiBjb3VsZCBiZSByZXZpZXdlZCB3aXRoIHRoYXQgdmlldyBpbiBtaW5kLCB0aGF0IHRo ZXJlIG1heSBiZSBtdWx0aXBsZSAobXVsdGljYXN0L3VuaWNhc3QpIElQIGRlc3RpbmF0aW9uIGFk ZHJlc3NlcyB0byB3aGljaA0KIGEgZ3JvdXAgbWVzc2FnZSB3aWxsIGJlIHNlbnQuIEkgZGlkIG5v dCBkbyB0aGF0IHlldDsgY2FuIGRvIHNvIGluIGEgZnV0dXJlIGluLWRlcHRoIHJldmlldy48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWln aHQ6MTIwJTtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01UXSBUaGFua3Ms IHRoYXTigJlzIGEgdmVyeSBnb29kIGNvbW1lbnQuIFdl4oCZbGwgdGhpbmsgbW9yZSBvbiB0aGUg cG9zc2libGUgdmlldyB5b3UgcHJvcG9zZS4gSXQgc2hvdWxkIGJlIGZpbmUgYXMgbG9uZyBhcyBh IHJlY2lwaWVudCBpcyBhYmxlIHRvIHJldHJpZXZlIHRoZSByaWdodCBncm91cCBTZWN1cml0eSBD b250ZXh0LA0KIGJ5IHVzaW5nIHRoZSBHaWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vj dGlvbiAyLjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgdGhpbmdz IGhlcmUgYXJlIGxpc3RlZCBhcyBvdXQgb2Ygc2NvcGUsIGJ1dCB0aGV5IGRvIGNvbWUgYmFjayBs YXRlciBpbiB0aGUgZG9jIOKAkyBzdWNoIGFzIGZvcndhcmQgc2VjdXJpdHkgYW5kIGJhY2t3YXJk IHNlY3VyaXR5ICwgd2hpY2ggYXJlIGFkZHJlc3NlZCBJIHRoaW5rIOKAkyBjZXJ0YWlubHkgbm90 IG91dCBvZiBzY29wZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+W01UXSBHcm91cCBPU0NPUkUgZG9lcyBub3QgZW5zdXJlIGZvcndhcmQgc2VjdXJpdHkg YW5kIGJhY2t3YXJkIHNlY3VyaXR5IGl0c2VsZi4gSW5zdGVhZCwgdGhleSBhcmUgZW50cnVzdGVk IHRvIHRoZSBzcGVjaWZ5aW5nIGdyb3VwIHJla2V5aW5nIHByb3RvY29sIGVuZm9yY2VkIGJ5IHRo ZSBHcm91cCBNYW5hZ2VyLg0KIFRoZSBzcGVjaWZpYyByZWtleWluZyBwcm90b2NvbCBpZiBvdXQg b2Ygc2NvcGUgZm9yIEdyb3VwIE9TQ09SRSwgd2hpY2ggaG93ZXZlciByZWNvbW1lbmRzIHRoZSB1 c2Ugb2Ygb25lIGFibGUgdG8gZW5zdXJlIGJhY2t3YXJkIGFuZCBmb3J3YXJkIHNlY3VyaXR5IGlu IHRoZSBncm91cC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OyBHaWQgTVVTVCBiZSByYW5kb20gJnF1 b3Q7IC0mZ3Q7IHNlZW1zIHRvIGNvbnRyYWRpY3QgQXBwZW5kaXggQiB3aGljaCB1c2VzIGFuIEVw b2NoIGNvdW50ZXIgaW4gdGhlIEdpZC4mbmJzcDsgU2hvdWxkIGl0IHNheSDigJxNVVNUIGhhdmUg YSByYW5kb20gY29tcG9uZW504oCdID88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+W01UXSBSaWdodCwgbm93IGZpeGVkIChpbiBjdXJyZW50IEFwcGVuZGl4 IEMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFwcGVuZGljZXMgPG86cD48L286cD48L3A+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlk ZGxlIj5BcHBlbmRpeCBCLCBhIGNvbmNyZXRlIGV4YW1wbGUgaW5zdGFuY2UgaXMgbWlzc2luZy4g RS5nLiDigJx3M2ZqOTBmMGFfMDA0MuKAnSBvciBpdHMgYnN0ciBlcXVpdmFsZW50Jm5ic3A7IChq dXN0IGd1ZXNzaW5nIGhlcmUgdG8gdGhlIGZvcm1hdCk8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01UXSBXZSBhZGRlZCBhbiBleGFtcGxlLCBp biBjdXJyZW50IEFwcGVuZGl4IEMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bGlzdDpsNCBsZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVsMSBs Zm8yO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+QXBwZW5kaXggQywgaXMgdGhpcyBhbiBleGFtcGxl IGJsdWVwcmludCBvZiBob3cgdG8gZG8gaXQg4oCTIGZ1bGx5IG9wdGlvbmFsIHRvIGZvbGxvdyBv ciBub3QgZm9sbG93IHRoaXM/PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPltNVF0gV2UgcmVsYXhlZCB0aGUgdGV4dCBpbiBjdXJyZW50IEFwcGVu ZGl4IEQsIGFzIGZvciB0aGUgdGltZSBiZWluZyBpdCBpcyBpbnRlbmRlZCB0byBiZSBhIGd1aWRl bGluZSBleGFtcGxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQg bGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlkZGxlIj48bzpwPiZuYnNwOzwvbzpwPjwvbGk+ PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TWlub3I8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlz dDpsMSBsZXZlbDEgbGZvOCI+bGlndGhpbmcgLSZndDsgbGlnaHRpbmc8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvOCI+ZW5w b2ludCZuYnNwOyAtJmd0OyBlbmRwb2ludDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm84Ij5QZyAyNSAsIFtJLUQuaWV0Zi1h Y2UtZHRscy1hdXRob3JpemVdIHJlZmVyZW5jZSBicmVha3MgYWNyb3NzIGxpbmUgYW5kIGFzIHN1 Y2ggYmVjb21lcyBub24tc2VhcmNoYWJsZSBpbiB0aGUgYnJvd3Nlci4gQW5kIEkgbGlrZSB0aGVz ZSByZWZzIHRvIGJlIHNlYXJjaGFibGUNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODUyMTs8L3NwYW4+PG86cD48L286 cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNy4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBjb3JlIFs8YSBocmVm PSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y29yZS1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFpbWUgSmltw6luZXo8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDIzLCAyMDE3IDE3OjU5PGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4gV0cgKDxhIGhy ZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPikNCjxhIGhyZWY9Im1h aWx0bzpjb3JlQGlldGYub3JnIj4mbHQ7Y29yZUBpZXRmLm9yZyZndDs8L2E+PGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86amkteWUucGFya0B1bmktZHVlLmRlIj5qaS15ZS5wYXJrQHVu aS1kdWUuZGU8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtjb3JlXSA8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjgyNzY7 PC9zcGFuPiBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNh c3Qtb3Njb2FwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFs bCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJh ZnQgb24gJnF1b3Q7U2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24gZm9yIENvQVAmcXVvdDsgKCZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aWxvY2EtY29y ZS1tdWx0aWNhc3Qtb3Njb2FwLyI+ZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcDwv YT4mbmJzcDspIGhhZCBpbiByb29tIGNvbnNlbnN1cyBmb3IgYWRvcHRpb24gZHVyaW5nIElFVEY5 OSBhbHJlYWR5LCBub3cgd2UgYXJlDQogY2xlYXIgdG8gY29uZmlybSBpdCBvbiB0aGUgbWFpbGlu ZyBsaXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21t ZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCZuYnNwO2xpbWl0ZWQgdG8gd2hldGhlciZuYnNw O29yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkm bmJzcDtlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFyZ2V0IHRvIGVuZCB0aGUgV0dBIGlz IDE0dGggb2YgRGVjZW1iZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNpYW8sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIC0gSmFpbWUgSmltw6luZXo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5Ij5U aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZW1haWwgbWF5IGJlIGNvbmZpZGVudGlh bCBhbmQvb3IgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNz YWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91DQogYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0 aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsIGFuZA0KIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3Jp Z2luYWwgZW1haWwuPGJyPg0KPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvcmUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4N CjxwcmU+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmU8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5NYXJjbyBUaWxvY2EsIFBoRDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlc2VhcmNo IEluc3RpdHV0ZXMgb2YgU3dlZGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+UklTRSBJQ1QvU0lD UzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklzYWZqb3Jkc2dhdGFuIDIyIC8gS2lzdGFnw6VuZ2Vu IDE2PG86cD48L286cD48L3ByZT4NCjxwcmU+U0UtMTY0IDQwIEtpc3RhIChTd2VkZW4pPG86cD48 L286cD48L3ByZT4NCjxwcmU+UGhvbmU6ICYjNDM7NDYgKDApNzAgNjAgNDYgNTAxPG86cD48L286 cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuc2ljcy5zZSI+aHR0cHM6Ly93d3cu c2ljcy5zZTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5UaGUgUklTRSBpbnN0aXR1dGVzIElubnZlbnRpYSwgU1AgYW5kIFN3ZWRpc2ggSUNU PG86cD48L286cD48L3ByZT4NCjxwcmU+aGF2ZSBtZXJnZWQgaW4gb3JkZXIgdG8gYmVjb21lIGEg c3Ryb25nZXIgcmVzZWFyY2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW5ub3ZhdGlvbiBw YXJ0bmVyIGZvciBidXNpbmVzc2VzIGFuZCBzb2NpZXR5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNJQ1MgU3dlZGlzaCBJQ1QgQUIsIGhhcyBu b3cgY2hhbmdlZCBuYW1lIHRvIFJJU0UgU0lDUyBBQi48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1P121MB001470B4EE2FE2E26E5E19DB9BD80VI1P121MB0014EURP_-- From nobody Wed Mar 7 00:50:12 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1CB126D3F for ; Wed, 7 Mar 2018 00:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tutfi.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 rL59x520kbmB for ; Wed, 7 Mar 2018 00:50:08 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0125.outbound.protection.outlook.com [104.47.0.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73E1124217 for ; Wed, 7 Mar 2018 00:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tutfi.onmicrosoft.com; s=selector1-tut-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YAajy546nr0iL/cKyamVUsFDYorDyEPPvvSUZ47Cpxc=; b=ZgFVxiM70O2rycsO7ixlncmOS0igkrzHbJ/jswlxhETdPXKiwtZd2RZ1HlzfgdEPIZuNptWx4c/KaidTYQxEeENn7VPeD3458lTfiBkFLN63hjYtWPgucHV5j+iI3EKzGOr0A5Jioy95VpsLu2e4RY9M07gMFdaxVR11JS+EwbM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bilhanan.silverajan@tut.fi; Received: from Bilhanans-MacBook-Pro.local (83.145.195.18) by HE1PR02MB1081.eurprd02.prod.outlook.com (2a01:111:e400:5356::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 7 Mar 2018 08:50:03 +0000 References: <152028354209.31723.8346188604471097377.idtracker@ietfa.amsl.com> To: core@ietf.org From: Bill Silverajan X-Forwarded-Message-Id: <152028354209.31723.8346188604471097377.idtracker@ietfa.amsl.com> Message-ID: <67ed1ae3-2aca-1abd-1f9f-bc0fd279d1d5@tut.fi> Date: Wed, 7 Mar 2018 10:49:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152028354209.31723.8346188604471097377.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------7BD155571E2E296DFE97A831" Content-Language: en-US X-Originating-IP: [83.145.195.18] X-ClientProxiedBy: HE1PR05CA0214.eurprd05.prod.outlook.com (2603:10a6:3:fa::14) To HE1PR02MB1081.eurprd02.prod.outlook.com (2a01:111:e400:5356::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9bd4ed2f-328d-4efd-bf89-08d584086ba1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR02MB1081; X-Microsoft-Exchange-Diagnostics: 1; HE1PR02MB1081; 3:e/gj4cBuQUahyMMvvFP1GFRl69cG41Bl0vUxxBMJIbU6lEJz7J1uI39hxJtqCQyzlzbYuFJfcXg52Vq8lbL47iKR4v3LJ1tV7OKIp7jV8JgWaSAO8yzNBxh9JVYxkU7zwDhcXjdajv0USxGoMDswvmmNnM4z7GJK8xs+PvQS9/5q5tWgjjACXRCLvMz5FSSByhdZ0UlgtRDGnXDgjDghWLuS9khEiyYruyp2+V/nb0+9fy48JwRfZSQLdZz1AI7i; 25:IbjgGigRjqt4ZBdhNSIxA6aZQY0RrN/iHTYuHTVHmc4c1nDkedtQT83VRtuVE9HUh1FccsCNJngpiyZXhWj7uNh2QbF6km+D7VY8Y9jXMsmXY9gcm8OfnBLQsTh6zQ2A0XQ294HvEqn5hwcQAdr4OPJp0WIOkkyAN+aZi+/XSJ+Ys4x5pW1/3BNUHESqoKUTilroZ6B0H97g5mOmvVWmx4R+5WYbQhuv1SM98w6ubMbC7JpO1aDfCApwtJDSSPhFEOfz87ogUuaWADFPbYleGUTzJSTxqr6Nluhg9jOj40XxWZZnSKuWBFjLkHqapH3CCoFAVRUJxvT6oFxqGbVMCg==; 31:sd7ZU617ym8/o65TLKvfl2Xjw4EWaqeW3e6q4cOv3QQqa+KFTrOB3S56N90FzVBJ+QnZ4lHJvYJivEcknD8OGREzrHKz1P0IJpgrom+c62vvPMaxL+Wsr1+fN98mZsVjCSOIJSuTXriKeqQAFbgcSbCgtAXvAI3e2twiDbxNGpJmkIPuZ57RTp3lqmMfHUyaHw6uaX4dv/xfnlSfTkH9OEhyqTONInEplLodALbClZY= X-MS-TrafficTypeDiagnostic: HE1PR02MB1081: X-Microsoft-Exchange-Diagnostics: 1; HE1PR02MB1081; 20:JEJrIYlJF/yKYpGV0Py8vUsnvMYhrvcOZCWlkTHRjCglKuXHkxtVO4Iv/mAKANvqaHeqj0NHViMak7QthEDlBqALpBJUwYmg8+nbLjbwBqsvqq7MpY3mdE8SL/3Wi7nJzV3zio+Cc8yNGIsPrzCjG2vu7zdS254Ln++aroJh0wIRioXvUHTS1oSNybmYcfGa6cN4BQSo65+MnXEAUeZY7FXY8tPGaohjwxA0PyABVWFwUz+YQS/ZHAeof41rs8+CIcCBZWOJeWrgG+KZlaFjiFZJKmcND18V2j3B5V4NOVTvUg6iz6P79B7RAWY+RpgkLRY5nwMxaa7cd8YHURZEHw==; 4:QcHlkbFVvT2Z9wM2fd4yHtF7TOT2rJbjOWlhBhZgq7rGPnQog9O8gMBIEbvzYLwLXz1Kx6uOBuCQpwK4Bnvp5oCn5gc/eyLn7udXnCcYB/iON82iYwjY1x9AM66/dA/fWRk4UpVbe1Ki2wl8ZucvqnLxmfknOtBV9Ud+SVvy97/OSWT4sQPGaFPJqJuH336SFqiZAfJNDHPg+40dmN7Oy46YtxRdWZ5LnMgqspjNrP31/Nv6WAyfawDkfAVekUF0uJewXYe7/B77TU6SPsDy3RhAjUaK2YdNwGvJgjaD+71L+3lQ3iLgtlhwksWADmHdbenMgYJZkYw383GoD3GsFP9BewOzQMLC5XuFrlE1uI4UvA59n3cct9RJAc4ZLN3e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(120809045254105)(35073007944872); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(3002001)(6041288)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR02MB1081; BCL:0; PCL:0; RULEID:; SRVR:HE1PR02MB1081; X-Forefront-PRVS: 0604AFA86B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39850400004)(396003)(39380400002)(366004)(346002)(376002)(189003)(199004)(377424004)(81166006)(81156014)(3846002)(52116002)(8936002)(2906002)(478600001)(270700001)(6486002)(65826007)(6116002)(105586002)(86362001)(606006)(31696002)(16586007)(64126003)(966005)(8676002)(76176011)(37036004)(58126008)(7736002)(84326002)(316002)(6512007)(6506007)(97736004)(68736007)(25786009)(33896004)(54896002)(6306002)(74482002)(186003)(59450400001)(5660300001)(16526019)(786003)(2473003)(386003)(33964004)(36756003)(229853002)(26005)(15650500001)(106356001)(66066001)(236005)(2950100002)(65956001)(65806001)(6916009)(2361001)(53936002)(31686004)(6666003)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR02MB1081; H:Bilhanans-MacBook-Pro.local; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: tut.fi does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR02MB1081; 23:rJlOpLP/tyTjWQGLg4aDvg2XmPued9NHoM7j06wh4?= =?us-ascii?Q?ocNPANP9Wdl9fZRJimkk5Wts1CmEkh+QwX4AOAQSNtNrM0RUOZoMBShqnask?= =?us-ascii?Q?rzaIZak3ExNm1PsPBi63B8j58IoEyrFWCil9doOfGJPAcqIqFS2cDlVMtmd4?= =?us-ascii?Q?B/dV8uQlIEW2u5VxbNYNfg/B8d4qKeL9tV16mh8V6V+dpqiNTqIlddmHkV4v?= =?us-ascii?Q?t18VBxQfLa3YJzDfORvITsFeZp41zMtqaQKSIEltieZ1P9HpDvzIm9vVl6wY?= =?us-ascii?Q?plcLopiaGxYXjiTeISXiUsx0q9CbmRVWlaso/gdnn0ISbMlELMkFNWGR+kK7?= =?us-ascii?Q?sHBnPqbR5Kh4ZXxwyQcU85nI4JCD3SQbRI1X2DCriDmxjaeUK97EeJ8WbeRn?= =?us-ascii?Q?YK+T02r+8p8UMmctuGgvAPQtq3wzif86uHvWsAvJdsT/8+6dPh4MrMX4xLYa?= =?us-ascii?Q?N1loBsSP5TY0197Eh1r9yne0gvSWjYbZeGYtRbPlPgoD3ToMVY90vK/4sGH5?= =?us-ascii?Q?a4qNoRZVP9QNI08+YmBbQd3d+oulIoeYnaWl8ORM1Ynqn07bXLgEyxbSQQaq?= =?us-ascii?Q?peQTroc63AXZaPfxVTigmFUDFh5C2ffnd+3q3isUQwsNOdlhlQb/uWYNaSI/?= =?us-ascii?Q?4RIIa0ZBYLnUyO7+W7ZsmPdlmq86ut5Ht0rl+aLtnt+mJaOdjItc7B9ggQa5?= =?us-ascii?Q?uh37E159nJ1eflIIgTiHuzFTRFTDel7le7qNHelQyitjHlJF0hBzj9hUx9mg?= =?us-ascii?Q?r40dhFY+vi9GS7906GFpNyp3iGOgreiYoxQsayi+M/StDxfcDAJNyfe79tCv?= =?us-ascii?Q?aZOGEt/sb4VIBKyFv+V3DLU3BgwB9YRcRHlRhMGSQ8ISROxIvK8gkxKDOIDN?= =?us-ascii?Q?/9BAWNxoecuLBqM4cVk+mj/mkrSxqyden2HNjM0O4NfPxU4q0nvgvyweIVSA?= =?us-ascii?Q?hKiltXMuWkmhe86woU7I/RZNUHlmrM24IgkErmiG+b3z6Kf1JeA5RFDeDlI5?= =?us-ascii?Q?2jw+d9KK7PQbOzrnzJNREo+PMRTFwrcdlzboTQWm34h1tGXKmt9X7S6eECZc?= =?us-ascii?Q?ALxe4zR3dMMxlo3nth4XC5qxrdwL1YtRSjbjfS6MfkrAZzAyVelYYQrRoF3x?= =?us-ascii?Q?l5ul4oL1GmXZI27vBnf+j7UB+bY4dZch9/JFq38Xu+e3JJe/7EgTRVWsP1TN?= =?us-ascii?Q?EN3hUbgO3izVwZM8RD0ol2vM9sfEJd8BEbCyp0/oDIDvASkrbSLSDjA2gbNr?= =?us-ascii?Q?sCr9e7E9RU86dtHIM9GssxzGWOJHhG6urG0bJ1BcB+odNhtGJAKCW5G/kqUZ?= =?us-ascii?Q?q4hjDVSV8HcE4KPOFli/NA45EBuwGxgH0ywYIO6lE9E6m6w2Z/0EFaImH0LN?= =?us-ascii?Q?C34v4Up6ni03pI1DPzWMnmaU1H24ktg04ugNeSDFPynHguqeniqFiXyuf9j1?= =?us-ascii?Q?ONcU2CXOwLdGoJxsN6eWzZE1VcpNvd+mb49zv3RyMPADIzP5rGtQ6HCbvp7l?= =?us-ascii?Q?UL115BHAd0eRQ=3D=3D?= X-Microsoft-Antispam-Message-Info: qFSx/D4VcK7dLuqNT3qAJJlVyxu5YEEdyPesUCGkeyvEoTAaoBlqeuJJQi6nLqmfVIRxOCQbnkYjTaFOx9ktrqkjqIeKiuuJ266Ik2LLFWbfdXodqIiePxpzBjiLAqgUEVJqQPy0ROA71u1+S+TjjPPciMjWrWXWYmn9WLLwXWysdhpf1O8idLvoQdCV2LtT X-Microsoft-Exchange-Diagnostics: 1; HE1PR02MB1081; 6:w3LWRe9FqHQ1JcgFhP0AuxszWnnTYSmW+1sBqwZroahn/TUA6kgVPOsDqlYofSBltvCd3vQMzdeC7BudkThICpcfP1SEv/xR0BBYTGO60jvHZVo1mb3CLl5f37FRNbw5aGHDCjZS+BT9di6WflhBm5otgoXMp8G2gXMjHfYSxNAqNHVqM/QwdSPkiCYoFhpINlLh2m4jqIaN47LVG6HuqLt3CZyRQ5rG/pgjRmTOfTF5iTdFyhqf2T8rhud5uGOdcTEXJGrEo1A9uyM5C3zzLtQgzm5pnISnyE+IwpuV523FnGBIzEX+DlpOmS0i/ew4IgL0TofOAdIFwovJR1pX6xdGYXYUM92cFiNycd7t8eE=; 5:da161lWqOTOmEWVETcS8g+asNM91LApnK+XSh91fScjzpsQFYDefnk1x2bxLwZtO3eBMvun+vMRokUqF3YMJI5dcEuqY5g8ih5oj5iaMW2mvUePFr1bVxTQrF0Qa0xlqGQR8l8ubONLa3EGVEt0vfZBTnedWiKGJz0XEs5Sfrxs=; 24:iUd1hPZNy/3R3BddWms5ay56JLXXYyv3fNc8bPOEWZwnJfQDFUVMGqN9oo1YPoWewpY/B3vdbw71Bm40NHw3jJ45nCZFXK5kbgwh8C00cT0=; 7:t+i6b4w29wKaPOVddTUR/XNTU4klZHn98u/zwwOksqJ6QGFvocUAmpU8IM91GergxkAfifZRRZ7mVZlI7wJN0frN1mBEQCp/jJ7GRDdzWq3vSLTGHpRhogBSvZqKvSTCZEPEe192zqY71lSIT3OrdRIIGF8CVfJUVTOArsb5xlmq4/Vzv/BjRO3V+c41VdoRh7qbSFlZ7q3r9JrQPTHEx+AH4N5wcDWlmq4ZJ23+iFqJEf5k3jBISxsahtIFD/So SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tut.fi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2018 08:50:03.0503 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9bd4ed2f-328d-4efd-bf89-08d584086ba1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 271a0e2b-2a07-4d45-840b-ca860972fd60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR02MB1081 Archived-At: Subject: [core] Fwd: New Version Notification for draft-silverajan-core-coap-protocol-negotiation-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Mar 2018 08:50:12 -0000 This is a multi-part message in MIME format. --------------7BD155571E2E296DFE97A831 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello CoRE, We submitted version -08 of CoAP Protocol Negotiation on Monday. The version adds to the feedback previously received, and now incorporated good suggestions and feedback from Jaime's and Christian's reviews of -07. More detailed responses to both reviews would follow shortly. Best regards, Bill -------- Forwarded Message -------- Subject: New Version Notification for draft-silverajan-core-coap-protocol-negotiation-08.txt Date: Mon, 5 Mar 2018 12:59:02 -0800 From: internet-drafts@ietf.org To: Mert Ocak , Bill Silverajan A new version of I-D, draft-silverajan-core-coap-protocol-negotiation-08.txt has been successfully submitted by Bilhanan Silverajan and posted to the IETF repository. Name: draft-silverajan-core-coap-protocol-negotiation Revision: 08 Title: CoAP Protocol Negotiation Document date: 2018-03-05 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-silverajan-core-coap-protocol-negotiation-08.txt Status: https://datatracker.ietf.org/doc/draft-silverajan-core-coap-protocol-negotiation/ Htmlized: https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-silverajan-core-coap-protocol-negotiation-08 Diff: https://www.ietf.org/rfcdiff?url2=draft-silverajan-core-coap-protocol-negotiation-08 Abstract: CoAP has been standardised as an application-level REST-based protocol. When multiple transport protocols exist for exchanging CoAP resource representations, this document introduces a way forward for CoAP endpoints as well as intermediaries to agree upon alternate transport and protocol configurations as well as URIs for CoAP messaging. Several mechanisms are proposed: Extending the CoRE Resource Directory with new parameter types, introducing a new CoAP Option with which clients can interact directly with servers without needing the Resource Directory, and finally a new CoRE Link Attribute allowing exposing alternate locations on a per-resource basis. 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. The IETF Secretariat --------------7BD155571E2E296DFE97A831 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hello CoRE,

We submitted version -08 of CoAP Protocol Negotiation on Monday. The version adds to the feedback previously received, and now incorporated good suggestions and feedback from Jaime's and Christian's reviews of -07. More detailed responses to both reviews would follow shortly.

Best regards,
Bill

-------- Forwarded Message --------
Subject: New Version Notification for draft-silverajan-core-coap-protocol-negotiation-08.txt
Date: Mon, 5 Mar 2018 12:59:02 -0800
From: internet-drafts@ietf.org
To: Mert Ocak <mert.ocak@ericsson.com>, Bill Silverajan <Bilhanan.Silverajan@tut.fi> 


A new version of I-D, draft-silverajan-core-coap-protocol-negotiation-08.txt
has been successfully submitted by Bilhanan Silverajan and posted to the
IETF repository.

Name:		draft-silverajan-core-coap-protocol-negotiation
Revision:	08
Title:		CoAP Protocol Negotiation
Document date:	2018-03-05
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-silverajan-core-coap-protocol-negotiation-08.txt
Status:         https://datatracker.ietf.org/doc/draft-silverajan-core-coap-protocol-negotiation/
Htmlized:       https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation-08
Htmlized:       https://datatracker.ietf.org/doc/html/draft-silverajan-core-coap-protocol-negotiation-08
Diff:           https://www.ietf.org/rfcdiff?url2=draft-silverajan-core-coap-protocol-negotiation-08

Abstract:
   CoAP has been standardised as an application-level REST-based
   protocol.  When multiple transport protocols exist for exchanging
   CoAP resource representations, this document introduces a way forward
   for CoAP endpoints as well as intermediaries to agree upon alternate
   transport and protocol configurations as well as URIs for CoAP
   messaging.  Several mechanisms are proposed: Extending the CoRE
   Resource Directory with new parameter types, introducing a new CoAP
   Option with which clients can interact directly with servers without
   needing the Resource Directory, and finally a new CoRE Link Attribute
   allowing exposing alternate locations on a per-resource basis.

                                                                                  


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.

The IETF Secretariat
--------------7BD155571E2E296DFE97A831-- From nobody Wed Mar 7 01:35:40 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FE312DA11 for ; Wed, 7 Mar 2018 01:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 aJuXD8LlPaQ8 for ; Wed, 7 Mar 2018 01:35:23 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 DBA32127AD4 for ; Wed, 7 Mar 2018 01:35:18 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id z9so3349788wmb.3 for ; Wed, 07 Mar 2018 01:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=m/Lc453N61YD/1DEcumQPO+VxDsJU5ob1jYFn7cjG6s=; b=IuYmDf8g/d/kF41/N4B5+FA7A1m24dI1x7ehlXWO3h/bp1FtcQJXcFb3yLmCGmhm1c QMrqPNUZoRWTX6Q8iNhjOdLQhJqw0CH6F0ZUtCCmgZJBhMRugYJSexVpxoDmLDs9QCqb XL137jAQ+CoysazRVJbjoc7X4p8lw8Fcr/Ro3+o34YHcY7ORkBbpy4EUb7wyUjbHInrR v1U+lqIc3SkTYByuNLMU/LeEVptaP90ptPRvBrnY7iekBP5USsIwRyUH73CaIQ/4T8T1 x3OuhCNX2WnYjsdkC3ikiVqt/01tmrkBXsY4f22BZ3Vs030ueJoc7ddM8pahQ1tPDdFc a31Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=m/Lc453N61YD/1DEcumQPO+VxDsJU5ob1jYFn7cjG6s=; b=uJnMcxiSobg5YSf9Yeh+m1XlpMNHIxAyZT3cvjBw+obyC8wg5IaG++jtTJbRwqYYgJ a6uC9nb2N/Aob4VhY6kjwsiz4A8FsZOQhasZnB64Uw+Xmli4mf+YOVGZd/mVl0hX8Exu HZD8tjHxbPBqqZTIUHoq7T0Tw4pJWOFnhm2TK9dvX35EXBLKO9HL6MrMLKgXRUDOa9tw Q+diYFQ2+psKL2yp/4NYJkl5bTt59C+HOg5riJEqEmYyxiTAAUD8KMMKkeeS8VThWq43 ukx0QRmR72yPB6tmzzemmkc143miWbewBLeqf3g4hhrMIsx1tWq6a4ZfdBXNH19PNhVr qqSg== X-Gm-Message-State: AElRT7EIbbbFCJzFajnymR+v7my/OsAxt5GZCWJbyJN5t78LS3476a1K 7JN9Bnwh+BlvugrtYQUZgbFSfTcnnsiLFlNCgoomt5ht X-Google-Smtp-Source: AG47ELu6iov2ATicCNfIU0UN2t95DxWY9F2I7cXkPLJ4CegWeXMaeKCArq8MJGhFpHIHJVsAJf9cwDPBVqoj9jAy0Sc= X-Received: by 10.28.182.139 with SMTP id g133mr12535437wmf.158.1520415317097; Wed, 07 Mar 2018 01:35:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.28.71 with HTTP; Wed, 7 Mar 2018 01:35:16 -0800 (PST) In-Reply-To: <152006273460.8326.14938329610342433374.idtracker@ietfa.amsl.com> References: <152006273460.8326.14938329610342433374.idtracker@ietfa.amsl.com> From: JR Wu Date: Wed, 7 Mar 2018 17:35:16 +0800 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="001a1148f4aee301920566cf4685" Archived-At: Subject: [core] Fwd: New Version Notification for draft-wang-core-opcua-transmission-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Mar 2018 09:35:28 -0000 --001a1148f4aee301920566cf4685 Content-Type: text/plain; charset="UTF-8" Hi CoRE: We have submitted a new version -03 of OPC UA Message Transmission Method over CoAP. We add some use cases to this new version , and modifies the transmission schemes. Please click the following links to see more details if you are interested in this draft. Best regards. Junrui Wu ---------- Forwarded message ---------- From: Date: 2018-03-03 15:38 GMT+08:00 Subject: New Version Notification for draft-wang-core-opcua-transmission-03.txt To: Ping Wang , JUNRUI Wu , " mentospcg@163.com" , Lun Shao , Heng Wang , Jianqiang Hou , " 15023705316@163.com" <15023705316@163.com> A new version of I-D, draft-wang-core-opcua-transmission-03.txt has been successfully submitted by Chenggen Pu and posted to the IETF repository. Name: draft-wang-core-opcua-transmission Revision: 03 Title: OPC UA Message Transmission Method over CoAP Document date: 2018-03-03 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-wang-core-opcua- transmission-03.txt Status: https://datatracker.ietf.org/doc/draft-wang-core-opcua- transmission/ Htmlized: https://tools.ietf.org/html/draft-wang-core-opcua- transmission-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-wang-core- opcua-transmission-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-wang-core-opcua- transmission-03 Abstract: OPC Unified Architecture (OPC UA) is a data exchange specification that provides interoperability in industrial automation. With the arrival of Industry 4.0, it is of great importance to implement the exchange of semantic information utilizing OPC UA Transmitting in CoAP. This document provides some transmission methods for message of OPC UA over CoAP. 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. The IETF Secretariat --001a1148f4aee301920566cf4685 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= CoRE:

We have submitted a new version -03 of OPC UA Message Tra= nsmission Method over CoAP. We add some use cases to this new version , and= modifies the transmission schemes. Please click the following links to see= more details if you are interested in this draft.=C2=A0

Best re= gards.
Junrui Wu

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
D= ate: 2018-03-03 15:38 GMT+08:00
Subject: New Version Notification for dr= aft-wang-core-opcua-transmission-03.txt
To: Ping Wang <wangping@cqupt.edu.cn>, JUNRUI Wu <wjr930914@gmail.com>, "mentospcg@163.com" <mentospcg@163.com>, Lun Shao <yjsslcqupt@163.com>, Heng Wang <wangheng@cqupt.edu.cn>, Jianq= iang Hou <houjianqiang@huawei= .com>, "15023705316@163.= com" <15023705316@163.co= m>



A new version of I-D, draft-wang-core-opcua-transmission-03.txt
has been successfully submitted by Chenggen Pu and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-wang-core-opcua-tr= ansmission
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPC UA Message Transmission Method= over CoAP
Document date:=C2=A0 2018-03-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-wan= g-core-opcua-transmission-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-wang-core-opcua-t= ransmission/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-wang-core-opcua-transmission-0= 3
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-wang-core-opcua-transmission-03
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-core= -opcua-transmission-03

Abstract:
=C2=A0 =C2=A0OPC Unified Architecture (OPC UA) is a data exchange specifica= tion
=C2=A0 =C2=A0that provides interoperability in industrial automation. With = the
=C2=A0 =C2=A0arrival of Industry 4.0, it is of great importance to implemen= t the
=C2=A0 =C2=A0exchange of semantic information utilizing OPC UA Transmitting= in
=C2=A0 =C2=A0CoAP. This document provides some transmission methods for mes= sage
=C2=A0 =C2=A0of OPC UA over CoAP.




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.

The IETF Secretariat


--001a1148f4aee301920566cf4685-- From nobody Wed Mar 7 09:44:35 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6520412711A for ; Wed, 7 Mar 2018 09:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=tutfi.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 YgP7I9a7HZGu for ; Wed, 7 Mar 2018 09:44:30 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0132.outbound.protection.outlook.com [104.47.0.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06F0126D74 for ; Wed, 7 Mar 2018 09:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tutfi.onmicrosoft.com; s=selector1-tut-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ph3GTqUEaktm2+C7xw/GxbLIb6t6LoAYe98agIoAQXU=; b=lMQi/1auRyWJi84nB+L5RaJSm6P54b+R7p2gG3RvlDIyV9rxhBaF5pQfCtBmcoFhccgl6wjNbERu8IQUjCVA19GO1n5JHlkuYA66CJ15IL+1zdbxREuOTDl5wPgZXHC90loPNmCCRNshP3zvEbY6rXD0/LRR4aXjkrzRp3hRd70= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bilhanan.silverajan@tut.fi; Received: from Bilhanans-MacBook-Pro.local (83.145.195.18) by HE1PR02MB1082.eurprd02.prod.outlook.com (2a01:111:e400:5356::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 7 Mar 2018 17:44:25 +0000 To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , Core WG mailing list References: <20180223150833.GA26617@hephaistos.amsuess.com> From: Bill Silverajan Message-ID: Date: Wed, 7 Mar 2018 19:44:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180223150833.GA26617@hephaistos.amsuess.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [83.145.195.18] X-ClientProxiedBy: HE1PR0402CA0040.eurprd04.prod.outlook.com (2603:10a6:7:7c::29) To HE1PR02MB1082.eurprd02.prod.outlook.com (2a01:111:e400:5356::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2fd329c5-fc77-42a0-fb38-08d5845311d8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR02MB1082; X-Microsoft-Exchange-Diagnostics: 1; HE1PR02MB1082; 3:qd6UQxyztQCt5c5+wQyXHeT8iZ6XEjrYeuR2fe/edebM+pF9BfNCJPHbviYENuRh1QNaLG3I9V/dqe2z65yHP8d7r8AEVNc06Nh8PeJ3AzNTx3uUkPywbA2zbpTwOWCeUyJ2/0Px1ZeViCqG+ad/PFbtiKbE4zkV3uEomPy9c7ENvipHhx4we8lKOyt8R+pjYIr6xBsDwur17SR5DGDjHYXPaf0CExwBrCQbptGV6N0Hh6npyyCKv1anmfCznCxI; 25:my/L3lgnvEPWaXnFt5v9plXUgXL52J0zW/f+8XvyPHebJxrXM2iYJCYQUD2K4wO6/cE94IbFgvzoC5eif2L+ESSUveqhVADBGU+SI8ZGjimIIizsxb6SiSU7TimuKQB+Wys8/VeySTLF9p7eKqppwhYPwy7atHnnG1tyzUW/Dsbozu4pGJDtcPs9umJgVbvnOb0vKQaq5mkQiKdoNuyj9qwvGQTlZ+BRmoIFftKz+0L7uf0HCeBCc7yhXz9T5PF6xYkc6JGZeXGKScEaHhANo14khpRsq68ykSb29RyTnIP4mEgPfKLvGizyXVVRFWHhWUe0dzo+7tAfeqmf6MpAzQ==; 31:vrdqBk//WAjjtUAKBdj1DF0Iv4Wls7geNkWW24VwAtDWofAhqWNfmjIAGeL/4LkWqOpMAsAL/KSdDiPb06Rix8FONEvEtYK8HBrFhH5HajenFPsqiQfnUbUC7KHyKmQfGei9PIbZ3bfYwncf1j7ord3+Dmt/assPZs0bd9ZSoijdpJ0KMoOo5ouHGpjyZ1wjrtFn4NAWuqnX1SLB/ZBSYBTNEbxPGAdBKtAFsoOpy78= X-MS-TrafficTypeDiagnostic: HE1PR02MB1082: X-Microsoft-Exchange-Diagnostics: 1; HE1PR02MB1082; 20:lpbHJqB31YHp7Be0tdgfm2rWcvZwM++Qz0615+MxKeNuf6KAwQVwixqeknGbYLPrvt7r1XgZ+W8OTYYhw40CLSozA48PQcxnxoA5Xpa1/Ina7Ifhs8oMWCaMXlSXEeu5SJoogDd5ujBYhkaAcLEvhDJieKLTaocnKMhVTnK1hPYUIwSMztoGf2QdtwlbOjW5Yk4uQRKZklBEAgGqQ/rKRLBGbTxdWEEaQETscl/bKhZ2nvXtezC4mu2HI78xbQ9IWq3RKZ4B1FH3OKkJqMWzQ2VrEGoDZ3gSBCktqPy3w7Rdi3LyVRtE7Qy6j585a4Ytep5XhLBoScW62ezSBUwgyw==; 4:ARjHJr9CbSjsL827zppMG6FdXiit2B7tG+Ys7fF8aaauJtW4ggkHabqT8byUaGoyNzHxXQ5mStJ3yBxTNqWSCJerhH9/13OguvRAjQH5A9EOzJd3tf13uL8Fu8RcPsN8nTx7gaSFqImlUZDBfXtJTHfusJVRigS6EPdTbO8QslcjMBR73fKiUJ8G3dWk41VNm5UBSYsMnfP3EtKQ9fUwdkjjhWcat4zEbe8iLMgTll9TUftmeNU9Ov3yD41nXGhkFfEnrV4nFvEvr2OOwfkKwxligW+fvzOFSwLKljUrEvdAHj5u1O0XqnxUfUj8hU3G X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231220)(944501244)(52105095)(10201501046)(3002001)(6041288)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR02MB1082; BCL:0; PCL:0; RULEID:; SRVR:HE1PR02MB1082; X-Forefront-PRVS: 0604AFA86B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39850400004)(396003)(376002)(346002)(189003)(199004)(51444003)(345774005)(16526019)(2870700001)(97736004)(68736007)(76176011)(6306002)(6512007)(8676002)(6486002)(81166006)(3846002)(2906002)(186003)(966005)(7736002)(305945005)(52116002)(67846002)(105586002)(81156014)(6116002)(8936002)(316002)(478600001)(110136005)(58126008)(786003)(86362001)(47776003)(6246003)(31696002)(65956001)(65806001)(50466002)(19625305001)(6506007)(26005)(66066001)(64126003)(36756003)(33896004)(53936002)(59450400001)(386003)(5660300001)(31686004)(229853002)(106356001)(25786009)(2950100002)(65826007)(23746002)(6666003)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR02MB1082; H:Bilhanans-MacBook-Pro.local; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: tut.fi does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; HE1PR02MB1082; 23:Ma1nGtUm2TQtzi9G6SObTNa4Uc8twpX6Yf9oM?= =?Windows-1252?Q?iGRoSozcsBsXv/GzU5q1aCP8cs7GNMGPB2jKrQSZJmF0z3RLTDea/HGl?= =?Windows-1252?Q?QMwFiQSDTPz2tGTOMc1j6zmK+qZ/2rxwrdgHxn93ZMHomF0M4oL+OT5K?= =?Windows-1252?Q?tD3dpoePEDHa7wUe4/hiGs6ZtmhM8QkpbytYIGsX2kFiu0rJFfg1WV+R?= =?Windows-1252?Q?WgVWg/zkmkhap6Z4hluLNHyud4FVEOITJqJTU4zO+7oiW6LN0ogxGRHY?= =?Windows-1252?Q?PYf1Laq/pPjJyeDggjIjENAxD/N2C/hX7B47pmFTUAc8EO0Se+OQ9q6V?= =?Windows-1252?Q?nJNeC0pw2VCvkAmwQB9tLR+ieqZTRJgAbCleEL6BcTrjoi1fr5biOYTF?= =?Windows-1252?Q?qb0AYZ57nrOzLiwD4BehH/LgHWiyrNXgxTPoYQ92o6A1dJbLggoluV2S?= =?Windows-1252?Q?g5lRMV3QNGheYO/I3GO6mHApZJ2w2WBweVOEfvinvwJ1T4uSPgA2FSnJ?= =?Windows-1252?Q?qZboFInEHUCptBzlnlcuzQ2044qpexbqPQKRC7Akfqut2wEOXNXVcL/B?= =?Windows-1252?Q?cRlGtzVIJlUvfWF10WGVpL62+DRknrQPu8qghTj+nUm0KnAHAKfWWjTk?= =?Windows-1252?Q?+TbVdQfEinFSLajzJdAx2Vx/N5JpZ1uUMjfS4QsT4SqTRlUEtV2ahVO4?= =?Windows-1252?Q?Z32SMuiDvmdzw9HPj2x5WGO5UNrMO0mE/Lx81hQ0YPkZsSKNcYdkRgyH?= =?Windows-1252?Q?vrHzV5O4wOl8R/AQ6Xqh9/Em6E7al5XF7ve93WnO5/C0Fq9/1d0RPr8G?= =?Windows-1252?Q?Hkkwwuz0eH/PabkjyCi4a3tk3N9K7dsX+IK0KlVTsIm1a5TVk0ieusM7?= =?Windows-1252?Q?Bf0/KNoTOSDyJJ67c/VdZ3BKkj5oUQkuv1OrIUeSv7XOSM3gVUjl9Lv0?= =?Windows-1252?Q?EuF3y15ozNZHa+T3k4c4ogL+HSJnSTg7dSbGRwtVhtnOYQAuWIA8Tbt+?= =?Windows-1252?Q?cn6PJcL8jHkNHf4kxE/k40BUlL11fXax1y/2mcJxg92xHIwGVmPRfxVH?= =?Windows-1252?Q?zHvDi4I9StIkHy6mLBAdGpnvjLw4dE9TB+g8UNllYgBGM4UytkUIsnvX?= =?Windows-1252?Q?MmYD2ewUHia+NaTl+igySzEwAZs4gL1t34NmelWYRyIVr56wGqDICFap?= =?Windows-1252?Q?8y2HxQ1SiZdlw1qaaEkLlF1QapbM5dy/+eHLVm3aVJrqJzOqFjrNvZ1G?= =?Windows-1252?Q?v1F31YKdcb1BuFxs53ef+XKd4hOeGnzQf64/dkDgGFiSHFsSs+jTjuiO?= =?Windows-1252?Q?NPwL7R1jSap/gG4JHw2xkCN5zCZrW90+dw5AaS4YIuPnxz2eNrUxhxVp?= =?Windows-1252?Q?fofHaa2njLXUr+VFuYHeo8gU0GdFwfFE02bU3ojPLdSO3lrrthWvdNW4?= =?Windows-1252?Q?AfeIDOIuARjBgQFcAPvfbN2GwalGjIYyH3OvPxKrkDbhLTPRxn7n1H+x?= =?Windows-1252?Q?05nznP5CKxXnWYXWZfWTdtF5S+SOHY/MBEfkLYWuzQ8mIZs1NGog7VFH?= =?Windows-1252?Q?8bFLMtGAcJBKJRpbLmjCnxuzYbbTftgTRF/?= X-Microsoft-Antispam-Message-Info: Mx8Fp4/lJcPfLZsmWdsHTAh+L1XFcSmpc7rXcDsUQRifwMit4ywm1ioJ3VD12UTBzfIMc5zahR6GmWz6lWNQJGbVblKzYpQXBzBN9zcF8q0CuChfgvTGOvm7/8y++WTYzScSetQxIhL41LkMwo/AcFgvoSqrhAA7+Q+z3vkbSIGVjWvL/uiyffMy2CnT7i29 X-Microsoft-Exchange-Diagnostics: 1; HE1PR02MB1082; 6:FAYUB1rIs32vxu3VmgKnwje03HH/ImKp8UBn5bZ9RAWG+FxR8CNjm9RAHLeKDwOGJp4fJk0D9ppjgzKLB3yPuaEo7EyyFcgS2oGTrkzimmH4V8xRw7xHDosfyV6f8PG3ZFlGGjUZyO2SBpXnE/EeBpyFmSo8tZOiU4iWueY/S0S3kw+AO6SIdFvp6dFSIsO5E16QJZYnFfsHiv3BY+fverIIY0dYItq0OMqrNtx27V5lxOYS5c5VYPmG00IByNG3WdkTNFrvBcwv3jc7usAF12GB/U5tnJ0PpEfZR6LsZjF/MqictFaoqY5yR0nA2a6CUWfVnunbXZycypVoPx9ebSLIIdwUSs3usC7cvtgzZ5c=; 5:9TJtCEMXmTOm4Wc2tK+dqzAL1O+bf/YjU9UE9aUI8/Gf/U9jDoX5QPwRLwsaB51zYRWdqpUQBZFSUN8c18CRTX56vApi1xS83mly+aUSytDSl9+29uNErmZJHMgJhCo6aMK1qR+gF3LD31fqZi4//4w641CJClcjsmJoQjPuDyk=; 24:jVcJFBCRz6jSOnNvA+66/8NY8TQI1wXEQcszeYLywYP8I2DBAclrKt7XZgDUsTJM5eaTueNHZaSR28IEsEFTLP6kVzio0fj6W1YHvBGL8YE=; 7:rGfq907n030XG/Bipt6+k7jxrVbYghiQNutjfFp9ff66V8jya6oHS44L/A/NZ1a3QP7T6eOLVMnc5E7Tn8b43l6ZbiOA/14+kkmcj5kg/Nwt75h4mCPAcWAJySBZnXi/SbWqbSoVjHGuhYJX7KpuO0tziPNyquozzegqeJILVoe/FZEPKx6pu2Y9MOJ6XeXZMMaRbM6lOEEQEaJyfhpYAtOQoPMiJOO/lN+5IOB29V3ri9/lcNEeVCidTFbGyThS SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tut.fi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2018 17:44:25.7502 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2fd329c5-fc77-42a0-fb38-08d5845311d8 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 271a0e2b-2a07-4d45-840b-ca860972fd60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR02MB1082 Archived-At: Subject: Re: [core] Review of draft-ietf-core-protocol-negotiation-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Mar 2018 17:44:33 -0000 Hi Christian, I'll respond inline to your comments: Christian Amsss wrote: > Hello protocol-negotiation authors, > hello CoRE group, > > I'd like to offer a review and some suggestions to the document > draft-ietf-core-protocol-negotiation-07. My interest in the document is > both as a potential implementor, and as co-author of resource-directory, > which will in part be judged by whether it easily allows extensions as > suggested in protocol-negotiation. > > * Introduction: It would be helpful to have RFC8323 and > draft-becker-core-coap-sms-gprs-06 referenced to understand how > different transports use CoAP URIs. > * Another document that describes a CoAP scheme is > draft-bormann-t2trg-slipmux-02 ("Hey coap+uart://ttyUSB0/, do you > happen to be available over the network too, just in case you get > unplugged?"). The intro has now been changed and a reference to [1] added, which lists all the alternative transports being used or being considered for use. > > * coap+ws:// does not work like the example with > coap+ws://example.org/ws-endpoint/sensors/temperature suggests any > more. A more suitable example might be an HTTP proxy URI > ('http://proxy.example.org/coap+tcp://eample.org/sensors/temperature'). This is true. One of the original intent of protocol negotiation is to overcome URI aliasing and locater/identifier problems. We did not have a standard way to terminate the ws endpoint but that has been recently solved by RFC 8307 which then paved the way for RFC 8323. However, I'm not confident of addressing the usage of HTTP proxying as a viable use case for multiple transports so it's better to omit the WebSocket example in this section. > > * The example exchange in "Overcoming Middlebox Issues" confuses me: Why > would a client that has already established communication with a > server utilize an external service to discover more addresses? With > the current draft, this calls for the Alternative-Transport option. Thanks, this was a legacy example that we overlooked. It has now been changed to omit the RD, and a new example added to illustrate how an RD can be used to discover non-IP transport endpoints. > > * New Resource Directory Parameters: > > * Why is `at` comma separated rather than a repeated parameter? The > former indicates limitations on the available characters (at least > the comma; is there any other syntax planned a la `;q=0.5`?), and > the latter would IMHO be more straight forward to implement. It was a historic design decision to allow using 'at' as a non-repeating parameter in previous versions of the RD, to keep it consistent with the other non-repeatable parameters in the registration interface. This consequently led to 'at' being a single key-value pair and having a comma-separated list of base URIs. However, now 'at' has been updated as a repeatable parameter after later versions of core-rd introduced extra-attrs*, with which we can (hopefully) extend. > * With changes to the RD in the latest versions, the endpoint lookup > looks a bit different. I've taken the examples of this section and > created some current ones in the upcoming RD draft ([1]). > > Note that at least for the endpoint lookups, the `at` parameter does > not need to be implemented in a PN-aware RD, as it is the default > behavior for unknown RD Parameters to accept them on registration > and show them in an endpoint lookup. > > I think that with the new behavior of the RD, the `tt` parameter > makes more sense in resource lookup than in endpoint lookup; would > you consider specifying it for there too? > > Do the examples align with your ideas of how P-N can would work with > the latest RD? > > [1]: https://core-wg.github.io/resource-directory/draft-ietf-core-resource-directory.html#rfc.appendix.B Thank you, that was really very useful. The examples you provided have now been taken into -08. I think we'd still need to review how usage of 'con' and the anchors as used in the current core-rd specification, can aid with the discovery of multiple transports for CoAP. > * Does `at` mean that *all* URIs on this server can have their > prefixes arbitrarily exchanged, or only the advertised links? > > * Alternative-Transport option: > > * Does this option state that the requested URI is equivalent to the > indicated ones, or all URIs on the host? These 2 comments are related: The prevailing design approach was to register endpoint information per server, and not per resource. Therefore, the URI scheme and authority would differ, but the path is not affected. So they should be regarded as equivalent only in the sense that they should point to the same resource. > * Why is an option used here? The availability of an alternative > transport is a metadatum I think would be very suitable for > inclusion in . Expression as link metadata would > make the unmediated exchange more compatible with the RD-mediated > exchange, which right now look very different. /.well-known/ is the best place for site-wide metadata. The challenge is to find some means of expressing transports available per-server in a way that does not break the per-resource web linking, so I'm not sure if /.well-known/core does that very well. The other way to go if we don't use the Alternative-Transport Option is to define a new resource under /.well-known/ whose representation contains values of available transports. Could that be viable and registered to an RD? > > * The 'ol' CoRE Link Attribute: Did you consider using a link relation > for this? (Ie. there would be a dedicated link from the described > resource to its alternative URIs, rather than the URIs being encoded > in target attributes). The "alternate" or "duplicate" registered > relations seem to already do the required. > > (Admittedly, I don't quite see the use case for individual link > alternative URIs; if the use case you have in mind answers the > question, it might be a good idea to outline that use case.) The per-resource motivation and usage of attributes is to facilitate mapping to OCF's "eps" (described just before section 6.1) > > * "Using CoRE Resource Directory": The example in 6.2 would, on a > lookup in a ol-unaware RD, return as shown here: > > Req: GET coap://rd.example.com/rd-lookup/res?ep=node1 > > Res: 2.05 Content > [...] > ;if="sensor"; > ol="http://[FDFD::123]:61616,coap://server2.example.com" > > If the intention is that the href of the link can be re-interpreted > as a relative reference based on any of the ol values (btw: again, > why comma-separated?), this depends heavily on the serialization and > breaks when the serialization needs to be changed (as in the RD that > needs to return the absolute reference). Thanks, this has now been updated. Also "ol" has been made as a repeatable attribute upon checking guidance from Section 2.2 in RFC 8288 about attribute cardinality. Does the example look better to you? > All things considered, I think that this is a document that should be > adopted by the WG; it covers a relevant topic and provides good starting > points for solving it. > > Thank you, Bill and Mert, for writing this document Thank you for the great review! Best regards, Bill [1] draft-silverajan-core-coap-alternative-transports-11 From nobody Wed Mar 7 09:47:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C675D12E058 for ; Wed, 7 Mar 2018 09:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tutfi.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 Vx0g-SMRTlhJ for ; Wed, 7 Mar 2018 09:47:24 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20095.outbound.protection.outlook.com [40.107.2.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1D712DA12 for ; Wed, 7 Mar 2018 09:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tutfi.onmicrosoft.com; s=selector1-tut-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xITf17mQEHBkj79Z1bJtMC6JQdMFgMeWrCtpkJVYqgM=; b=NUD6QHR39VVYJYkHAbDHhs+t4b3N1ojQwtIwj5ydiC+nXQKT3GH1n/+i4IyAjRQIM3lqimNfSNU00gWXn9XP2QdGmkUbAwvKN4lxZQy55MHNokBGCTlpCchJSqdMQdu/KZ5YroYylFHOUdTJVnnjocs4GHZksOLdEDbDiS0xOP8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bilhanan.silverajan@tut.fi; Received: from Bilhanans-MacBook-Pro.local (83.145.195.18) by VI1PR02MB1087.eurprd02.prod.outlook.com (2a01:111:e400:5343::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 7 Mar 2018 17:47:19 +0000 From: Bill Silverajan To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" References: Message-ID: <8a6073c5-2d36-99e9-582f-5458fd2fd55f@tut.fi> Date: Wed, 7 Mar 2018 19:47:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------20F1774174ED13F1814F76F3" Content-Language: en-US X-Originating-IP: [83.145.195.18] X-ClientProxiedBy: HE1PR0902CA0009.eurprd09.prod.outlook.com (2603:10a6:3:e5::19) To VI1PR02MB1087.eurprd02.prod.outlook.com (2a01:111:e400:5343::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3478f7e9-b6d0-46e2-06a8-08d5845379f2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR02MB1087; X-Microsoft-Exchange-Diagnostics: 1; VI1PR02MB1087; 3:37HcK3etGN1NBS5wtlF7jApsbFigBUAB6JK8W5NZ4fHx1W06oU1Z3AlAzA7R48sGrbRHrcxBzZPPjzE/FY818rb7J+/Xlw4Kv048C8Odu6MHdVnItF1Tp7SSpj8Fj8N82QNBRJQ1BOC/v5ohPGjMzTcg4KgXlfR1Bz+Gx9/zUQ6iMnW7YNlf679yf4wtXoHyN/NjGbk8oc60Xhwz+pYZ88WxzH9ETlUfn19gxIBjbYyIayoiivS9tqq7re8S32Bf; 25:vzLWykWOqsBEI3fwxzjl3vruy5khm4LZGKYBTR5F6QaEtlYVgyv59dpFu4AjzW4QuR/3D7yTiQQsyid7hzUFOKW0jYUzCnEnfDrVedhcQ2mJh0cW4rYd7O1VmDTHT3EkPjv32fIt4VvUm62TOhgaJKO7zPFYpq6evGo6j8MA6RkDpf8vaFLOidJN1H643qOdO3p7Od8RGiMz3jSz37K+x65yDFbuu4KeJ/5hsba/RPZHsgHZld9iF+d+hYegulGY4OGjO39T6oPpaJH8mlo9odGcxOKZLydMzjJDN5q7KiTxsCP+nPa07Gre/13FfXLXbb4m8OzCrwbwe7eL3WO4Bg==; 31:U7bS/JZg8LdJcVhpvRZmuAeWHioPl2P0dvDB2Vw+JMbrDkgHsoehnyJF84VogDO6VMLYsam90L2qBvJUqdGZT3JEBRGHBF0o/ujvO1+8P/C2SrGqocSSJngZVD74dHonDUNBmbZGD1xj+r7SaPpyjuva2V3SnOWLBPHXhKCyZ3NhF55HJR74+b5SFjKn3NAulucKAB8kFklHljBCOlMS2fAVkBS4F5s3usUWliUUNcg= X-MS-TrafficTypeDiagnostic: VI1PR02MB1087: X-Microsoft-Exchange-Diagnostics: 1; VI1PR02MB1087; 20:RK8+vNI46FwMChmXoK615A0iLMQ34inlm/JV5vF9cW36BzPd1PPN9QM1MGGX3z7Jxh4HE8jJvdc/iVCiTV8hDvZhMYGouygBXN/AfcU4qAKh0+INhO9QfqLOgnT98VFRornxMujgQVbXDc7Ukp62/SbyNvlo3cDLQL0M4LV4qJAyYkbaOuD29m2ClLVOTXAsx+bQeZb3Wtjw+BOonFUyN1vhs8x9MX/joQkhi4Aj+6qbEHmlNP1NMpXyf5bwegDECw6mn2wpZLIWv1NQC0A8Tf4VQiDGNtWl6VL6CW+iWfrMAgXzaDbMNJHxCCyP3jogpQVS7wNcZhKHWniwbIbLZA==; 4:Zf9mOSVoovmrXE1ZaSj8GpXLdaFdCLor3UY6eRaoLWoPAiCGE6/ii88ZGS7oNWMPQU5+PJONH97ZOcrL7QBxZXG45tYN+jHa09t1hXt/xXuOvmxdam4iGEesLm9nqppx4DXhHLmtM65Bp9gglMGwS8i/RBzUVpqdR+e5m+WEs2nIhbijlzCjYyNYtZmyS6f4k646LoFTQoKHovIt19yVlPojft+8xlfbAh0LImAbEWl6YLXSxE2MY98fhLMYRtpOpWvV7xHLyI1Qz5ofOjPZ+P1/vGhcQuklog9c3rAiPYXNrvkIsookaaRczfX/TXjESLDr4kImkL57ElhI6RpBg/twMx82CCyMvJ0IBSpqNB1UQIPxgvBR/NYFlyLmfUyzp+B8ywuXWfF/zC+q4k7Q7eljRVUKGTaeNA9yUe4F55Y= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(3002001)(6041288)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR02MB1087; BCL:0; PCL:0; RULEID:; SRVR:VI1PR02MB1087; X-Forefront-PRVS: 0604AFA86B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(39380400002)(376002)(346002)(366004)(189003)(199004)(59450400001)(5660300001)(64126003)(6506007)(31696002)(6666003)(65826007)(478600001)(606006)(6486002)(105586002)(386003)(786003)(316002)(2950100002)(236005)(106356001)(54896002)(6306002)(25786009)(6512007)(65806001)(66066001)(65956001)(53936002)(81156014)(81166006)(31686004)(8676002)(26005)(6246003)(186003)(97736004)(16526019)(8936002)(6116002)(68736007)(58126008)(3846002)(74482002)(86362001)(2906002)(229853002)(16586007)(33896004)(37036004)(966005)(52116002)(7736002)(110136005)(76176011)(84326002)(36756003)(33964004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR02MB1087; H:Bilhanans-MacBook-Pro.local; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: tut.fi does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR02MB1087; 23:NJaD217Dy4td/5owUFt/qOZa7DaNrmpxF/PIZ6LP+?= =?us-ascii?Q?BQ8/ztOIxvzLoPoBlkSK+zCM6t8K14VU/0SNCr0ymJ+dzmoGfEqiKrLu/yCl?= =?us-ascii?Q?ypyNTn8zuYEpKtnl0mtqfXjyHSx1ic1xjkDW4zqUQhiiynM1VYZbpFzrGRvX?= =?us-ascii?Q?2iwdWasFRxXOV+RcIwUb8vjUL70HwoeOOhZqdzs4c7Mfdog6GkknreqnFj0x?= =?us-ascii?Q?TGCagPWeK9yU3WfW9wsfB2XG9CjmBOCUDmQ6+92HBssYsQcV/lkTVYq9bLIX?= =?us-ascii?Q?js/36P+thJLCe8wiaaLu4o1b7Ha6k03vxQDxd1pTJNT7pI3oWKRrDxna/lQW?= =?us-ascii?Q?7BkmWfqHeihltKVoRd0qBM/iZJFENbgD61wDQkejKI8XZvRlM8l/8vwld5Dz?= =?us-ascii?Q?c/B6QIYF9piM3OnUcHMrrWAtVz4Lbh5gXNuXXjEIXzE+BzVCyHaG4oKOxmWs?= =?us-ascii?Q?N1pT7V+kJ/cxZnogyovg25BxjmyN48MCFdwhTq2C9YPkK4Yu/Kex7sZuZmR4?= =?us-ascii?Q?6Vptlw/yuVwkyJ82IagHECtRSkjsqrJ2jLF4BFi/eoopOvX5gYP/ht3KhxB7?= =?us-ascii?Q?MP1qYOnC8Q0xKgFJKE8SMLAlNLKXy+wkFY90fZvP9xTUWdbLmgZowwZmfhK2?= =?us-ascii?Q?nVk905kniTI+S3FB2eIIQ4lu8jfnnpUq0cAaU4T3wN9PieybQfAo60UbrYM7?= =?us-ascii?Q?a7vz3AAhHrD4tFP6y16sVcGIKCgZFGdFarJnULjDJ5IiWTHoliwW5rvJH3+s?= =?us-ascii?Q?4UxFiZgpMWUImZHhyjLRoNGfARzT5/egCZZkcrnIoV3rxhL5u2u+dlgTEjAf?= =?us-ascii?Q?RSXpbdSSQ4vcJmRKIl4Ldx1Gr8NBEQdkYXQhVuPLaPxJkcF19gyaWkj67/KW?= =?us-ascii?Q?JRkXLfdXNeQXA8eiJrBc5D1r8xcTcLnB63+7xHUimnjEicZs8eZN/rmIrJ0w?= =?us-ascii?Q?8vinrnhq9e9NShpjKjL8yODbyXCIFnzEgVBNApP7IMJBtQ51VL4JKMGkzsg9?= =?us-ascii?Q?4Z5KvrlRbpIWqE++SHd6HIkRrG0toAEEVLD0HoQiY7fObNGUjspqHU14xruN?= =?us-ascii?Q?YpOkaOq+KzEe3vnoyqOvVwM4xexuf5TLyV7F7ezUN6YdGKrzHYwgMDdLSC0a?= =?us-ascii?Q?/c8pk6up3SlzuE57Rc/QXiMWC3m4XrSStzK2H4fKmWLOcBdqQgOvpUHMoB7K?= =?us-ascii?Q?GBKb6VGRXH9zxVWnVedSi2BMVcojKUbiq1o60PEGn5C+KN2zZWHS9vCB9Lm4?= =?us-ascii?Q?9Y5HpAgOtz+AteeVZU7oCA0GuwN0NGbDoVgJeod4K0jQKCI5u+bv1Lv6hXN+?= =?us-ascii?Q?vUWEy6XMYNy7Z3dUsB5FEDNNptOeGmgVUoEACLQufQSI1ukwcuqEtukdWOmL?= =?us-ascii?Q?lUgayaUpKFKCtHgOOO5HMILHgQ=3D?= X-Microsoft-Antispam-Message-Info: q6SKQWEUqMpRmoBKD/zBYtZFw67TBoMACnBcFGBuvJvwq/HPyrN5+K1O80a8BqQKOrIdpi56NO+nUerLL4wwXcrBzFrpRixH6GfFaIPdeJukm0HHR5cg7gnDtHZ3PQSnTmhHUkochIPWIxjYk4oj+lQyxLtGJw6ikzLiZHO2SxwHCYmZUfRwB4eq2fW9Z4Ru X-Microsoft-Exchange-Diagnostics: 1; VI1PR02MB1087; 6:HYXrU6hWLOyybnF727aXxxaxfps1E5qGbph+mnWatWyHPpYJAGOETsd2MiknQiSj+aHH4gwYlsPkzCb4nDPxSSXwY3D0jC+xspQeJFobQjy9RkTIDpsX4BbOwTAIOd7SL8AeaPLypROZbQUcMTYoNQiwL6WyBiRjrDD3BgJbxuA3ovn3tSij/AP3q0idGFPP/ROR7nBhtCU8cQnsWmk7hC6kW3gbPJFwSrJu1jEm1PR5nq/2zkhU9ibGA3X0P08tSQUrKIR9NmhgEdQig1GXkWhn2lHgb4GnwTN6bAjfVZmUtmdpxR8z4w3oy8hTMUqua1C2YEmi/YZuQ8sFBDowaDC8GDGE2NaGwaH2T6jRgtA=; 5:LPfutos8jzD3D+Akn0QUKsO51X2sMZ6SR4YaLadyO76zR/fVbs0L6Lp8SrgaSr43aNo/lcUh+k0R0jtjib1Y9hBRiTGT4Dr59e6qCK/Qiaz0D7ZBfNk9/3vR0lYfO9/VLbS2MBmcXLoavfPyHvTMydpuEaPVm/NJAJyWHGRlNuE=; 24:FTmHBw4sU/XoSvsaME8k1rj0+dXQvWBytCIFIienA7mMkV8qBuFCcNy/D7Fdw5Ec7cfsH4A7SiTeDMuF8OB7lXIZK5JRa/mR4z9+hdzMBAE=; 7:8RpfW7m68pHkUpKplSM3cWetCTg3HJn4Liwf1GMcZgGhONihgakK3wErDB/TJllRgU7aGINRL+o3q6ieb1t6UG28orA6UdyRDJ5rJgZMgd3vbF2NgQoDTOL9TKLwlylz8CyvMQfFl5BHr36zJZcKbdZKf+oxIkdUuMa297IBDZrXI1QlVTUfvnRHo7OhvoH4L+k+8x4TR0CtWkR5HugcfAbmVQcSbPVor3PtE5pO83PTOOahBWLuLXrnddm64IUL SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tut.fi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2018 17:47:19.7568 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3478f7e9-b6d0-46e2-06a8-08d5845379f2 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 271a0e2b-2a07-4d45-840b-ca860972fd60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB1087 Archived-At: Subject: Re: [core] Review of draft-silverajan-core-coap-protocol-negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Mar 2018 17:47:43 -0000 This is a multi-part message in MIME format. --------------20F1774174ED13F1814F76F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jaime, Thanks for reviewing the document! Below are responses to what you wrote: Jaime Jiménez wrote: > Dear authors, > > I had some time to review > draft-silverajan-core-coap-protocol-negotiation-07, below is the feedback. > > * The RD option: > - have you thought about using this mechanism as a NAT traversal tool? It potentially can, if the RD is reachable by both client and server, and there is some sort of keep-alive mechanism at the NAT. There was also a discussion about a potential "coap+at", or an "all-transports" happy eyeballs approach based on Thin ICE which might also help. > - what happens if any of the context on “at” is different than the one > used to register the endpoint. If you're referring to the usage of "at" to the use of "con", it's specifically because we wanted to avoid overloading the semantics of "con", which can be used by commissioning tools. So, you can have both parameters present. > - is the lifetime of the registration also carried to the other > transport (is the ep being registered on both transports)? In short, yes. We thought of introducing lifetime per transport but it turned out to make it more complicated. The current approach allows the server to update the "at" list every time it sends a registration update on RD. This way, transports discovered from RD are always available. > - are security associations between client and server reset when > switching transport? Currently, yes. There are no session resumption/information exchanged between transports defined yet. > - I think the lookup example could benefit from a more complex lookup, > for instance using “rt” or “et” with “tt”. That's a good idea and we introduced that now in version -08 > > * Alternative transports option: > - I’m not sure about this but wouldn’t this force to mandate specific > CoAP ports per transport? Yes they should be standard, but the idea was also to show non-standard ports as there will always be endpoints exposing transports on different ports than the standard ones > - How large can the payload get? How many alternative transports are > there? Can’t we assume that we keep the scheme and simply answer with > the transport supported? > We can't do that all the time and elide the authority. For example supporting sms, you'd have a different authority. There could also be many alternative transports available, e.g. exposing on different ports. > * “ol” attribute: > - typo: availabilty Thanks, fixed. > - this option, with no comment to how the context should be the same > can redirect a client to another server, right? Is that what we want? Not necessarily to another server but to another location, could be hosted on the same server. Obviously, if the authority changes, the security considerations for these kinds of alternate endpoints (that OCF also proposed) should be looked at more carefully. > - OCF uses a similar link attribute called “eps”. The idea was to align "ol" with OCF's "eps" so that per-resource alternate locations can also be supported. This came from Dave's slides in IETF 99. See slide 19: https://datatracker.ietf.org/meeting/99/materials/slides-99-core-consolidated-slides/ > - there should at least exist an informative ref to core-link format. I missed this comment for -08, sorry. Will be added for -09. > > The security considerations part will require quite a bit of work. Particularly for alternate locations, agree on this. > Implications on ETCH? Did you mean using FETCH to request for alternate locations? That would work as a substitute for the Alternative-transports Option, if we can devise a CoRE link that can express alternate transport endpoints on a server. > This draft is intended as informational, however at some point we > should have some normative text too for implementors, right? > That would be great. Also for some feedback from implementers! Best regards, Bill --------------20F1774174ED13F1814F76F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Jaime,

Thanks for reviewing the document! Below are responses to what you wrote:


Jaime Jiménez wrote:
Dear authors,

I had some time to review draft-silverajan-core-coap-protocol-negotiation-07, below is the feedback.

* The RD option: 
- have you thought about using this mechanism as a NAT traversal tool?
It potentially can, if the RD is reachable by both client and server, and there is some sort of keep-alive mechanism at the NAT. There was also a discussion about a potential "coap+at", or an "all-transports" happy eyeballs approach based on Thin ICE which might also help.
- what happens if any of the context on “at” is different than the one used to register the endpoint.
If you're referring to the usage of "at" to the use of "con", it's specifically because we wanted to avoid overloading the semantics of "con", which can be used by commissioning tools. So, you can have both parameters present.
- is the lifetime of the registration also carried to the other transport (is the ep being registered on both transports)?
In short, yes. We thought of introducing lifetime per transport but it turned out to make it more complicated. The current approach allows the server to update the "at" list every time it sends a registration update on RD. This way, transports discovered from RD are always available.
- are security associations between client and server reset when switching transport?
Currently, yes. There are no session resumption/information exchanged between transports defined yet.
- I think the lookup example could benefit from a more complex lookup, for instance using “rt” or “et” with “tt”.
That's a good idea and we introduced that now in version -08

* Alternative transports option:
- I’m not sure about this but wouldn’t this force to mandate specific CoAP ports per transport?
Yes they should be standard, but the idea was also to show non-standard ports as there will always be endpoints exposing transports on different ports than the standard ones
- How large can the payload get? How many alternative transports are there? Can’t we assume that we keep the scheme and simply answer with the transport supported?

We can't do that all the time and elide the authority. For example supporting sms, you'd have a different authority. There could also be many alternative transports available, e.g. exposing on different ports.
* “ol” attribute:
- typo: availabilty
Thanks, fixed.
- this option, with no comment to how the context should be the same can redirect a client to another server, right? Is that what we want?
Not necessarily to another server but to another location, could be hosted on the same server. Obviously, if the authority changes, the security considerations for these kinds of alternate endpoints (that OCF also proposed) should be looked at more carefully.
- OCF uses a similar link attribute called “eps”.
The idea was to align "ol" with OCF's "eps" so that per-resource alternate locations can also be supported. This came from Dave's slides in IETF 99. See slide 19: https://datatracker.ietf.org/meeting/99/materials/slides-99-core-consolidated-slides/

- there should at least exist an informative ref to core-link format.
I missed this comment for -08, sorry. Will be added for -09.

The security considerations part will require quite a bit of work.
Particularly for alternate locations, agree on this.
Implications on ETCH?
Did you mean using FETCH to request for alternate locations? That would work as a substitute for the Alternative-transports Option, if we can devise a CoRE link that can express alternate transport endpoints on a server.
This draft is intended as informational, however at some point we should have some normative text too for implementors, right?

That would be great. Also for some feedback from implementers!

Best regards,
Bill
--------------20F1774174ED13F1814F76F3-- From nobody Wed Mar 7 16:24:11 2018 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 BB55C12008A; Wed, 7 Mar 2018 16:24:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-core-object-security@ietf.org, Carsten Bormann , jaime.jimenez@ericsson.com, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152046864475.21252.16737523649312416693.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2018 16:24:04 -0800 Archived-At: Subject: [core] Ben Campbell's Yes on draft-ietf-core-object-security-09: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 00:24:05 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-object-security-09: Yes 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-object-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I’m balloting “yes”, but I have a few very minor comments: Substantive Comments: §4.2.2, last paragraph: Why not specify that directly, rather than put a normative requirements on new specifications? Editorial and Nits: §4.2.3.1, 2nd to last paragraph: Last sentence is hard to parse. §5, third paragraph: I don’t think that spec claims “plaintext” means “data that is encrypted and integrity protected”. I think it means “ the clear text input that will be encrypted and integrity protected” (This could probably be fixed by changing “data that is” to “data to be”.) §8.1, last paragraph: The SHALL seems more like a statement of fact than a requirement. From nobody Wed Mar 7 18:58:50 2018 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 E4FF4120227; Wed, 7 Mar 2018 18:58:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-core-object-security@ietf.org, Carsten Bormann , jaime.jimenez@ericsson.com, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2018 18:58:42 -0800 Archived-At: Subject: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 02:58:43 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-core-object-security-09: Discuss 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-object-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- https://mozphab-ietf.devsvcdev.mozaws.net/D3075 DISCUSS My overall concern with this document is that I am unable to evaluate the security properties of the system. I have described a number of issues below, but the basic problem is that this sort of partial protection is extremely hard to reason about and the security considerations do not do an adequate job of evaluating the impact of proxies modifying these values. I am similarly concerned about the HTTP mapping and link section which seems extremely sketchy and has essentially no security analysis, and yet potentially have a lot of landmines. At minimum, this document needs to walk through the implications of modifications by the proxy to every unprotected field in the pure CoAP context as well as the HTTP context (if you want to retain that binding). are given in Appendix A. OSCORE does not depend on underlying layers, and can be used anywhere where CoAP or HTTP can be used, including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]). IMPORTANT: This document claims to be applicable to protocols other than COAP, in particular HTTP. Has this been reviewed by the HTTP working group? Martin Thomson's review suggests that this is out of step with HTTP practice. IDs MUST be long uniformly random distributed byte strings such that the probability of collisions is negligible. IMPORTANT: I don't understand how this paragraph and the previous paragraph interact. You say that the maximum length is 7 octets in the previous paragraph, which I don't think qualifies as "long". | 1 | If-Match | x | | | 3 | Uri-Host | | x | | 4 | ETag | x | | IMPORTANT: Why do you think that it's not important to have integrity protection for Uri-Host and Uri-port? Outer option message fields (Class U or I) are used to support proxy operations. IMPORTANT: This seems problematic because the proxy cannot verify class I fields. layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so fields such as Type and Message ID are not protected with OSCORE. IMPORTANT: This seems extremely hard to reason about. What are the implications of the proxy being able to change these? o request_piv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5). IMPORTANT: I think what I am getting here is that the request_piv is used to verify that the request and response match. However, I do not see this explicitly stated anywhere, and it's not clear to me how the client is supposed to recover the request_piv and the text is pretty unclear here? Is the external_aad carried somewhere in the message? Am I supposed to reconstruct it from the message id? For responses, the message binding guarantees that a response is not older than its request. For responses without Observe, this gives IMPORTANT: I am not sure that this is true. What happens of the counterparty lies? What is your threat model? An extension of OSCORE may also be used to protect group communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use of OSCORE does not affect the URI scheme and OSCORE can therefore be used with any URI scheme defined for CoAP or HTTP. The application decides the conditions for which OSCORE is required. This is pretty surprising to just drop in here. Multicast has totally different security properties from non-multicast. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- but is also able to eavesdrop on, or manipulate any part of the message payload and metadata, in transit between the endpoints. The proxy can also inject, delete, or reorder packets since they are no Nit: you want "eavesdrop on, or manipulate any part of, the message payload and metadata in transit" I.e., move the second comma the endpoints, and those are therefore processed as defined in [RFC7252]. Additionally, since the message formats for CoAP over unreliable transport [RFC7252] and for CoAP over reliable transport Nit: "OSCORE protects neither .... nor...." Salt. Length is determined by the AEAD Algorithm. Its value is > immutable once the security context is established. Nit: you might just say above or below this list that all the values are immutable, different operations. One mechanism enabling this is specified in [I-D.ietf-core-echo-request-tag]. Is this a security condition? of [RFC7252], where the delta is the difference to the previously included class I option. Is the delta here the previously included Class I option or the previously included instance of the same option, as it appears to say in S 3.1. compressed COSE object. The values n = 6 and n = 7 are reserved. How can Partial IV not be present? it's the sequence number. Is the answer that it is the 0 value? response. The server therefore needs to store the kid and Partial IV of the request until all responses have been sent. It was my understanding that the kid was needed to look up the key. Why are kid substitution attacks an issue? The maximum Sender Sequence Number is algorithm dependent (see Section 11), and no greater than 2^40 - 1. If the Sender Sequence Number exceeds the maximum, the endpoint MUST NOT process any more If you take my suggestion about removing senderID from the nonce you will be able to relax this. After boot, an endpoint MAY reject to use existing security contexts from before it booted and MAY establish a new security context with Nit: this is ungrammatical included in the message. If the AEAD nonce from the request was used, the Partial IV MUST NOT be included in the message. IMPORTANT: You are now violating the invariant of using the same nonce twice. That's fine in this case, because you have per-sender keys but it demonstrates that it is unnecessary to encode the sender_id in the nonce field. Security level here means that an attacker can recover one of the m keys with complexity 2^(k + n) / m. Protection against such attacks can be provided by increasing the size of the keys or the entropy of This paragraph is extremely hard to follow but I am not persuaded that it is correct. Do you have a citation for the claim that you can add the key entropy and the nonce entropy like this. style of padding means that all values need to be padded. Similar arguments apply to other message fields such as resource names. The PKCS#7 padding scheme at minimum has potential timing channels The server verifies that the Partial IV has not been received before. The client verifies that the response is bound to the request. How does the client verify this Partial IV (in network byte order) with zeroes to exactly nonce length - 6 bytes, IMPORTANT: I don't understand the reason for this construction. You already require that the key be derived via HKDF from the |master key| and |sender ID| therefore, it is not necessarily to separately encode the sender ID in the nonce. This would ordinarily not be a large issue, but as it requires very extreme restrictions on the sender ID (and essentially precludes random sender IDs) I believe it is worth considering changing, but it's ultimately a WG decision, hence not in my discuss. From nobody Wed Mar 7 23:38:42 2018 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 5DCC612426E; Wed, 7 Mar 2018 23:38:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-object-security@ietf.org, Carsten Bormann , jaime.jimenez@ericsson.com, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152049472037.21279.9230006306360711031.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2018 23:38:40 -0800 Archived-At: Subject: [core] Adam Roach's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 07:38:40 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-object-security-09: Discuss 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-object-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- §5 contains the following uses of "SHOULD NOT": > * The 'Partial IV' parameter. The value is set to the Sender > Sequence Number. All leading zeroes SHALL be removed when > encoding the Partial IV. The value 0 encodes to the byte > string 0x00. This parameter SHALL be present in requests. In > case of Observe (Section 4.2.3.4) the Partial IV SHALL be > present in responses, and otherwise the Partial IV SHOULD NOT > be present in responses. (A non-Observe example where the > Partial IV is included in a response is provided in > Section 7.5.2.) > > * The 'kid' parameter. The value is set to the Sender ID. This > parameter SHALL be present in requests and SHOULD NOT be > present in responses. An example where the Sender ID is > included in a response is the extension of OSCORE to group > communication [I-D.tiloca-core-multicast-oscoap]. As far as I can tell, both "SHOULD NOT" instances describe behavior that is unnecessary but benign. This usage is inconsistent with the definition of "SHOULD NOT" in RFC 2119: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. If the implications are simply "this is unnecessary but benign," then implementors have no real implications to weigh, and the described behavior doesn't rise to the level of "SHOULD NOT". If the implications are stronger than that, then *this* document doesn't contain enough information for implementors to perform such an evaluation. In the former case, you can clear this discuss by changing "SHOULD NOT" to "will not typically". In the latter case, you can clear this discuss by adding enough information for implementors to be able to make an educated weighing of implications. I'm also open to other proposals that remedy this use of 2119 language. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support EKR's DISCUSS. Martin Thompson raises a number of fairly important points in his review (see ). I recognize that many of these are fundamental to the design in the document. It is still worthwhile thinking through them and trying to suss out whether a redesign by the working group is warranted. I do want to put a little more meat on Martin's assertion "This doesn't appear to have any supporting security analysis," as this was something I was going to highlight myself (and this is related to EKR's DISCUSS as well). Given that this document seems to be putting together security primitives in a de novo fashion, I would expect to see something equivalent to draft-ietf-tls-tls13's Appendix E. Specific comments follow. --------------------------------------------------------------------------- §1: > ([RFC6347]) for security. CoAP and HTTP proxies require (D)TLS to be > terminated at the proxy Presumably, this means "CoAP-to-HTTP proxies"? Otherwise, the assertion is wrong: HTTP proxies do not terminate TLS connections. --------------------------------------------------------------------------- §1: > An implementation supporting this specification MAY only implement > the client part, MAY only implement the server part, or MAY only > implement one of the proxy parts Replace "MAY only implement" with "MAY implement only" (in three places) --------------------------------------------------------------------------- §1.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. These > words may also appear in this document in lowercase, absent their > normative meanings. This is almost, but not quite, the RFC 8174 boilerplate. Please fix it to match RFC 8174. --------------------------------------------------------------------------- §2: > +-----+---+---+---+---+-----------------+--------+--------+---------+ > | No. | C | U | N | R | Name | Format | Length | Default | > +-----+---+---+---+---+-----------------+--------+--------+---------+ > | TBD | x | | | | Object-Security | (*) | 0-255 | (none) | > +-----+---+---+---+---+-----------------+--------+--------+---------+ > C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable > (*) See below. > > Figure 3: The Object-Security Option I get the impression that this is supposed to be extending a table that already exists somewhere. This document should say which table. --------------------------------------------------------------------------- §4.1: > The CoAP Payload, if present in the original CoAP message, SHALL be > encrypted and integrity protected and is thus an Inner message field. > See Figure 5. > > +------------------+---+---+ > | Field | E | U | > +------------------+---+---+ > | Payload | x | | > +------------------+---+---+ > > E = Encrypt and Integrity Protect (Inner) > U = Unprotected (Outer) > > Figure 5: Protection of CoAP Payload The figure adds nothing to the prose; and is, in fact, harder to understand than the prose. I would recommend removing it. --------------------------------------------------------------------------- §4.3: > The other CoAP Header fields are Unprotected (Class U). Presumably this should say "The other currently defined CoAP Header fields...", right? --------------------------------------------------------------------------- §5: > As specified in [RFC5116], plaintext denotes the data that is > encrypted and integrity protected... Traditionally, data that is encrypted is called "cipher text." I gather from context that this should probably say "...the data that is to be encrypted...", right? --------------------------------------------------------------------------- §5.2: > responses, which reduces the size. For processing instructions (see > Section 8). This final fragment can be turned into a sentence by removing the parentheses. --------------------------------------------------------------------------- §6 and its subsections: The use of a bespoke profile of COSE adds implementation complexity to ostenstibly resource-limited device for what appears to be very little gain. In the examples given, savings of 4 to 7 bytes are demonstrated, which seems to hardly warrant the addition of this mechanism. These do not appear to be degenerate cases, so I can't imagine that compression performance under real-world conditions would be much better. Was there an explicit discussion in the working group regarding this complexity/wire-size trade-off? --------------------------------------------------------------------------- §6.3.1: > 1. Request with kid = 25 and Partial IV = 5 The base of the numbers above isn't indicated, and the reasonable reader may take it to be 10. Please either change the above line to "...kid = 0x25...", or change the hex encodings in the examples to h'19'. --------------------------------------------------------------------------- §7.3: > For requests, OSCORE provides weak absolute freshness as the only The meaning of "weak absolute freshness" doesn't appear to be given anywhere, and is not evident by combining the normal meanings of those three words. Please describe the property of "weak absolute freshness" in more detail (or, if this is a term of art defined elsewhere, a citation would be sufficient). -------------------------------------------------------------------------- §10.3: > o "" (empty string) if the CoAP Object-Security option is empty, or Which is it? Is this an empty string on the wire, or is it a string consisting of "" (that is, the two-byte sequence 0x22 0x22)? --------------------------------------------------------------------------- §10.3: >[HTTP request -- Before client object security processing] This line should be indented to match the rest of the example. --------------------------------------------------------------------------- §10.3: > o the value of the CoAP Object-Security option (Section 6.1) in > base64url encoding (Section 5 of [RFC4648]) without padding (see > [RFC7515] Appendix C for implementation notes for this encoding). ... > POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1 > Content-Type: application/oscore > CoAP-Object-Security: 09 25 The first block of text defines CoAP-Object-Security as a Base64 string. The second shows an example string of hex digits. Please either redefine the syntax in the first block, or show a matching syntax in the examples. This comment applies to §10.4 also. From nobody Thu Mar 8 04:42:51 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACDF126CE8 for ; Thu, 8 Mar 2018 04:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 WHm8Al1XWadV for ; Thu, 8 Mar 2018 04:42:46 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 4CC02126CD6 for ; Thu, 8 Mar 2018 04:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520512964; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XNsYp38XHFZ2E0abULczX/TktEjxyZbeSAGMEaz1JF8=; b=PnUZhQQwYJGktv9Nqx1eA03XksJqjL4dfrAhuheBg2XZiNxwmMl7WO+QzWa3V99s c0nRywjlrSXaKHRfkD8M9uyDs60rOt14vtUNP4OC3FwMGDyUIRu6dpfTpx0r9dmB mT91R2jTeCnCN2DzBdM8juiSRb6xKNnv811P5kg9PjU=; X-AuditID: c1b4fb2d-87c029c000005540-ee-5aa12fc4a91b Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DD.FC.21824.4CF21AA5; Thu, 8 Mar 2018 13:42:44 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 13:42:41 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Klaus Hartke CC: core Thread-Topic: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) Thread-Index: AQHTtJGG4yfbagWGT0GjW2g7xPGgz6PBwoqAgAR5dIA= Date: Thu, 8 Mar 2018 12:42:41 +0000 Message-ID: <4B71C39D-7D53-4B86-8C96-2D7FE4A5DA00@ericsson.com> References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7tO4R/YVRBvNuCVvse7ue2eLN/ttM DkweS5b8ZPJ48aGdMYApissmJTUnsyy1SN8ugSujY8VH5oIP7hVnTv5naWBsceti5OSQEDCR uPb7MFMXIxeHkMBhRolZs9exQziLGCW2N0xkBKliE7CVeNK6jxXEFhHQkDg8/SYLiM0sICFx duVhsLiwQI5E672vLBA1uRJPe2ZA2VYSnS3/mEFsFgEViUl/+4AWcHDwCthL/HlnALHrNKPE zemTwOZwCgRKXL89B2wvo4CYxPdTa5ggdolL3HoynwniagGJJXvOM0PYohIvH/9jhbDlJWac vcUEMp9ZQFNi/S59iFZriXc3TzND2IoSU7ofsoPYvAKCEidnPmGZwCg2C8mGWQjds5B0z0LS PQtJ9wJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF1cMtv3R2Mq187HmIU4GBU4uGd oLcwSog1say4MvcQowQHs5IIbwAwJoV4UxIrq1KL8uOLSnNSiw8xSnOwKInznvTkjRISSE8s Sc1OTS1ILYLJMnFwSjUwLtxlbOLo8/GMP5/Ig/aQp/OuzVBWjoh6mn5qulJJneDmpxMWTPsZ HOn02sq4hmmOdK+0X3XQJPvTelFyRUuXP5OJWe83tfb2BvcVr9lTj07y/pgl41iZl5KRpmKg en1/xTtulz7Lj7w1l8N+6jw6/lgthH3RNqM/bcllLzNeXqlqmCBZsOWoEktxRqKhFnNRcSIA rDVWzaYCAAA= Archived-At: Subject: Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 12:42:49 -0000 SGkgS2xhdXMsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBjb21tZW50cyEgU2VlIGlubGlu ZS4NCg0KPiBPbiA1IE1hciAyMDE4LCBhdCAxOC4yMiwgS2xhdXMgSGFydGtlIDxoYXJ0a2VAcHJv amVjdGNvb2wuZGU+IHdyb3RlOg0KPiANCj4gSGkgQXJpLA0KPiANCj4+IFRCRDogSWYgYSBzZXJ2 ZXIgY2hvb3NlcyB0byAobm90KWFjY2VwdCBhIHJlcXVlc3QgYmFzZWQgb24gdGhlDQo+PiBtZXRo b2QvcmVzb3VyY2UsIGhvdyBzaG91bGQgdGhpcyBiZSBpbmRpY2F0ZWQgaW4gdGhlIHJlcGx5Pw0K Pj4gDQo+PiBUQkQ6IHdoYXQga2luZCBvZiByZXF1ZXN0cyBhcmUgKG5vdCkgT0sgZHVyaW5nIHRo ZSBNYXgtQWdlPyAgRm9yDQo+PiBleGFtcGxlOiB0aGUgY2xpZW50IE1BWSBzZW5kIGEgZGlmZmVy ZW50IHJlcXVlc3QsIGluIHBhcnRpY3VsYXIgaWYNCj4+IHRoZSBleHBlY3RlZCBsb2FkIGZvciB0 aGUgc2VydmVyIGlzIHNtYWxsZXIgd2l0aCB0aGF0IHJlcXVlc3Q/DQo+IA0KPiBJIGd1ZXNzIHRo ZSByZXNwb25zZSBjb2RlIGNvdWxkIGJlIHVzZWQgaW4gYSBudW1iZXIgb2Ygd2F5cywgZS5nLjoN Cj4gDQo+IEE6DQo+ICAgIDEuIGlmIG5vdCByZXNvdXJjZSBleGlzdHM6IHJldHVybiA0LjA0DQo+ ICAgIDIuIGlmIHRvbyBtYW55IHJlcXVlc3RzOiByZXR1cm4gNC4yOQ0KPiAgICAzLiBpZiBub3Qg bWV0aG9kIHN1cHBvcnRlZDogcmV0dXJuIDQuMDUNCj4gICAgNC4gcHJvY2VzcyByZXF1ZXN0DQo+ IA0KPiBCOg0KPiAgICAxLiBpZiBub3QgcmVzb3VyY2UgZXhpc3RzOiByZXR1cm4gNC4wNA0KPiAg ICAyLiBpZiBub3QgbWV0aG9kIHN1cHBvcnRlZDogcmV0dXJuIDQuMDUNCj4gICAgMy4gaWYgdG9v IG1hbnkgcmVxdWVzdHM6IHJldHVybiA0LjI5DQo+ICAgIDQuIHByb2Nlc3MgcmVxdWVzdA0KPiAN Cj4gQzoNCj4gICAgMS4gaWYgdG9vIG1hbnkgcmVxdWVzdHM6IHJldHVybiA0LjI5DQo+ICAgIDIu IGlmIG5vdCByZXNvdXJjZSBleGlzdHM6IHJldHVybiA0LjA0DQo+ICAgIDMuIGlmIG5vdCBtZXRo b2Qgc3VwcG9ydGVkOiByZXR1cm4gNC4wNQ0KPiAgICA0LiBwcm9jZXNzIHJlcXVlc3QNCj4gDQo+ ICdBJyBzZWVtcyB0byBtYWtlIHNlbnNlIGlmIHRoZSByZXF1ZXN0IHJhdGUgaXMgbGltaXRlZCBw ZXINCj4gY2xpZW50L3Jlc291cmNlIHBhaXI7ICdCJyBpZiB0aGUgcmVxdWVzdCByYXRlIGlzIGxp bWl0ZWQgcGVyDQo+IGNsaWVudC9yZXNvdXJjZS9tZXRob2QgdHJpcGxlOyBhbmQgJ0MnIGlmIHRo ZSByZXF1ZXN0IHJhdGUgaXMgbGltaXRlZA0KPiBwZXIgY2xpZW50IG9ubHkuDQo+IA0KPiBJcyBp dCBpbXBvcnRhbnQgdGhhdCBhIGNsaWVudCBjYW4gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGVzZSB0 aHJlZSBtb2Rlcz8NCg0KSSBndWVzcyBpdCBkZXBlbmRzIG9uIHRoZSB1c2UgY2FzZSBhbmQgaG93 IG11Y2ggbG9naWMgd2Ugd291bGQgaGF2ZSBpbiB0aGUgY2xpZW50LiBGb3IgbWFueSBjYXNlcyBq dXN0IGJhY2tpbmctb2ZmIGlzIHByb2JhYmx5IGVub3VnaC4gQnV0IGZvciBleGFtcGxlIGZvciBh IGNhc2Ugd2hlcmUgc2hvb3RpbmcgbWVhc3VyZW1lbnQgZGF0YSBhdCBoaWdoIHNwZWVkIGlzIGNh dXNpbmcgb3ZlcmxvYWQgYnV0IHVwZGF0aW5nIFJEIHJlZ2lzdHJhdGlvbiB3b3VsZCBiZSBmaW5l LCBtYWtpbmcgYSBkaWZmZXJlbmNlIGJldHdlZW4gQyBhbmQgQSZCIGNvdWxkIGJlIHVzZWZ1bC4N Cg0KPiBTaG91bGQgYWxsIG9mIHRoZW0gYmUgc3VwcG9ydGVkIG9yIHdvdWxkIGl0IGJlIG9rIHRv IG1hbmRhdGUgb25lIG9mIHRoZW0/DQoNClByb2JhYmx5IHF1aXRlIHVzZSBjYXNlIGRlcGVuZGVu dCBzbyBub3Qgc3VyZSBob3cgbXVjaCB3ZSBjYW4gbWFuZGF0ZSBoZXJlLg0KDQo+IFJGQyA2NTg1 IHNlZW1zIHRvIGxlYXZlIGFsbCBkZXRhaWxzIHRvIGltcGxlbWVudGF0aW9ucy4NCg0KSW5kZWVk OyBub3QgbXVjaCBndWlkYW5jZSB0aGVyZS4NCg0KPiBRdWljaywgcGVkYW50aWMgcmV2aWV3IG9m IEtFWVdPUkRTOg0KPiANCj4+ICBJZiBhIENvQVAgc2VydmVyIGlzIHVuYWJsZSB0byBzZXJ2ZSBh IGNsaWVudCB0aGF0IGlzIHNlbmRpbmcgQ29BUA0KPj4gIHJlcXVlc3QgbWVzc2FnZXMgbW9yZSBv ZnRlbiB0aGFuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvciB3aWxsaW5nIHRvDQo+PiAgaGFuZGxl LCB0aGUgc2VydmVyIFNIT1VMRCByZXNwb25kIHRvIHRoZSByZXF1ZXN0KHMpIHdpdGggdGhlIFJl c3BvbnNlDQo+PiAgQ29kZSA0LjI5LCAiVG9vIE1hbnkgUmVxdWVzdHMiLg0KPiANCj4gVGhpcyAi U0hPVUxEIiBpcyBoYXJkIHRvIHNhdGlzZnkgc2luY2Ugbm90IGFsbCBpbXBsZW1lbnRlcnMgbWln aHQgYmUNCj4gYXdhcmUgdGhhdCB0aGlzIHJlc3BvbnNlIGNvZGUgZXhpc3RzLg0KPiANCj4gLS0+ ICJBIHNlcnZlciBNQVkgcmV0dXJuIGEgNC4yOSAoVG9vIE1hbnkgUmVxdWVzdHMpIHJlc3BvbnNl IGlmIGEgQ29BUA0KPiBjbGllbnQgcmVxdWVzdCBtZXNzYWdlcyBtb3JlIG9mdGVuIHRoYW4gdGhl IHNlcnZlciBpcyBjYXBhYmxlIG9yDQo+IHdpbGxpbmcgdG8gaGFuZGxlLiINCg0KVGhlIFNIT1VM RCBvZiBjb3Vyc2Ugb25seSBhcHBsaWVzIHRvIHdobyBldmVyIGhhcyBpbXBsZW1lbnRlZCB0aGlz IHNwZWMuIFRoZSBtYWluIGNhc2UgSSBoYWQgaW4gbWluZCB3aGVyZSB0aGlzIFNIT1VMRCB3b3Vs ZCBub3QgYmUgZm9sbG93ZWQgaXMgdGhlIHBvdGVudGlhbCBEb1MgY2FzZSBkZXNjcmliZWQgaW4g dGhlIHNlY3VyaXR5IHNlY3Rpb24uDQoNCj4+ICBUaGUgc2VydmVyIE1BWSBpbmNsdWRlIGluIHRo ZQ0KPj4gIHJlc3BvbnNlIGEgTWF4LUFnZSBvcHRpb24gaW5kaWNhdGluZyB0aGUgbnVtYmVyIG9m IHNlY29uZHMgYWZ0ZXINCj4+ICB3aGljaCB0aGUgc2VydmVyIGFzc3VtZXMgaXQgaXMgT0sgZm9y IHRoZSBjbGllbnQgdG8gcmV0cnkgdGhlDQo+PiAgcmVxdWVzdC4NCj4gDQo+IFRob3Ugc2hhbHQg bm90IG1ha2Ugbm9ybWF0aXZlIHN0YXRlbWVudHMgdGhhdCByZXBlYXQgb3IgY29udHJhZGljdCBS RkMgNzI1Mi4NCj4gDQo+IEV2ZXJ5IDQueHggcmVzcG9uc2UgaGFzIGEgTWF4LUFnZSBvcHRpb24g KHdoaWNoIG1heSBiZSBlZmZpY2llbnRseQ0KPiBlbmNvZGVkIHdpdGggMCBieXRlcyBpZiB0aGUg dmFsdWUgZXF1YWxzIHRoZSBkZWZhdWx0IHZhbHVlLCBidXQgaXMNCj4gdGVjaG5pY2FsbHkgc3Rp bGwgdGhlcmUpLg0KPiANCj4gLS0+ICJUaGUgTWF4LUFnZSBPcHRpb24gaXMgdXNlZCB0byBpbmRp Y2F0ZSB0aGUgbnVtYmVyIG9mIHNlY29uZHMNCj4gYWZ0ZXIgd2hpY2ggdG8gcmV0cnkuIg0KDQpH b29kIHBvaW50LiBXaWxsIGZpeCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQo+PiAgSWYgYSBjbGll bnQgcmVjZWl2ZXMgdGhlIDQuMjkgUmVzcG9uc2UgQ29kZSBmcm9tIGEgQ29BUCBzZXJ2ZXIgdG8g YQ0KPj4gIHJlcXVlc3QsIGl0IFNIT1VMRCBOT1Qgc2VuZCB0aGUgc2FtZSByZXF1ZXN0IHRvIHRo ZSBzZXJ2ZXIgYmVmb3JlIHRoZQ0KPj4gIHRpbWUgaW5kaWNhdGVkIGluIHRoZSBNYXgtQWdlIG9w dGlvbiBoYXMgcGFzc2VkLg0KPiANCj4gTm90IHN1cmUgaWYgdGhpcyBjYW4gYmUgcmVxdWlyZWQu IEl0J3MgbW9yZSBsaWtlIHRoZSBjbGllbnQgaXMNCj4gZW5jb3VyYWdlZCB0byBub3QgcmV0cnkg YmVmb3JlIE1heC1BZ2UgZXhwaXJlcy4NCg0KRG8geW91IG1lYW4gaXQgY2FuJ3QgYmUgcmVxdWly ZWQgZm9yIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvbid0IHVuZGVyc3RhbmQgdGhlIGNvZGUgb3Ig aW4gZ2VuZXJhbD8NCg0KPj4gIElmIHRoZSByZXNwb25zZQ0KPj4gIGRvZXMgbm90IGNvbnRhaW4g TWF4LUFnZSBvcHRpb24sIHRoZSBjbGllbnQgU0hPVUxEIHdhaXQgZm9yIHRoZSBNYXgtDQo+PiAg QWdlIGRlZmF1bHQgdmFsdWUsIDYwIHNlY29uZHMuDQo+IA0KPiBUaG91IHNoYWx0IG5vdCBtYWtl IG5vcm1hdGl2ZSBzdGF0ZW1lbnRzIHRoYXQgcmVwZWF0IG9yIGNvbnRyYWRpY3QgUkZDIDcyNTIu DQo+IA0KPiBUaGUgZGVmYXVsdCB2YWx1ZSBvZiA2MCBzZWNvbmRzIGlzIGFscmVhZHkgc3BlY2lm aWVkLg0KDQpHb29kIHBvaW50OyB3aWxsIGZpeCB0b28gKEkgYWN0dWFsbHkgY29waWVkIHRoZSA2 MCBzZWNvbmRzIGZyb20gNzI1MiwgYnV0IHlvdSBoYXZlIGEgdmFsaWQgcG9pbnQgYWJvdXQgbm90 IHJlcGVhdGluZyBub3JtYXRpdmUgdGV4dCkuDQoNCj4gUmV2aWV3IHN1bW1hcnk6IFJlYWR5IGZv ciBXRyBhZG9wdGlvbi4gKEFyZSB0aGVyZSBhbnkgb3RoZXIgcHJvcG9zZWQNCj4gQ29BUCBjb2Rl cyB0aGF0IGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoaXMgZG9jdW1lbnQgdG8gc3RyZWFtbGluZQ0K PiByZWdpc3RyYXRpb24/KQ0KDQpUaGFua3MhDQoNCk1pY2hhZWwgcG9pbnRlZCBvdXQgdGhlIG90 aGVyIG9uZSB0aGF0IHdlIG1heSB3YW50IHRvIGNvbnNpZGVyOyBsZXQncyBjb250aW51ZSB0aGUg ZGlzY3Vzc2lvbiBpbiB0aGF0IHBhcnQgb2YgdGhlIHRocmVhZC4NCg0KDQpDaGVlcnMsDQpBcmkN Cg0KPiBLbGF1cw0KPiANCj4gDQo+IE9uIDUgTWFyY2ggMjAxOCBhdCAxNTo1MiwgQXJpIEtlcsOk bmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gSGkgYWxsLA0KPj4gDQo+ PiBJIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhYm91dCB0aGUgIlRvbyBNYW55IFJlcXVlc3RzIiBD b0FQIFJlc3BvbnNlIENvZGUgKHNlZSBkZXRhaWxzIGJlbG93KS4gVGhpcyB3YXMgcGFydCBvZiB0 aGUgQ29BUCBwdWIvc3ViIGRyYWZ0IGJlZm9yZSwgYnV0IGFzIGRpc2N1c3NlZCBpbiB0aGUgcHJl dmlvdXMgbWVldGluZywgdGhlcmUncyBhbHNvIG1vcmUgd2lkZXIgdXNlIGZvciB0aGlzIHJlc3Bv bnNlIGNvZGUgc28gaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBhIHNlcGFyYXRlIGRyYWZ0IGFib3V0 IGl0Lg0KPj4gDQo+PiBXaGlsZSB0aGlua2luZyBhYm91dCB0aGUgZGV0YWlscywgSSBkaWQgcmVh bGl6ZSB0aGF0IHdlIG1heSB3YW50IHRvIGFsc28gZGVmaW5lIHdheXMgZm9yIHRoZSBzZXJ2ZXIg dG8gaW5kaWNhdGUgd2hhdCBraW5kIG9mIHJlcXVlc3RzIGFyZSBPSywgb3Igbm90IE9LLiBIb3dl dmVyLCB0aGF0IHRvcGljIG1heSBhbHNvIGJlIGFwcGxpY2FibGUgYmV5b25kIHRoaXMgUmVzcG9u c2UgQ29kZSBzbyBJIGRpZG4ndCB5ZXQgcHV0IGFueSBkZXRhaWxzIGhlcmUsIGp1c3QgVEJEIG1h cmtlcnMuIFBlcmhhcHMgdGhhdCdzIGFsc28gc29tZXRoaW5nIHRvIGRpc2N1c3MgYXQgdGhlIExv bmRvbiBtZWV0aW5nLg0KPj4gDQo+PiANCj4+IENoZWVycywNCj4+IEFyaQ0KPj4gDQo+Pj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWtlcmFuZW4tY29yZS10b28tbWFueS1yZXFzLTAwLnR4 dA0KPj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQXJpIEtlcmFuZW4gYW5k IHBvc3RlZCB0byB0aGUNCj4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+Pj4gDQo+Pj4gTmFtZTogICAg ICAgICBkcmFmdC1rZXJhbmVuLWNvcmUtdG9vLW1hbnktcmVxcw0KPj4+IFJldmlzaW9uOiAgICAg MDANCj4+PiBUaXRsZTogICAgICAgICAgICAgICAgVG9vIE1hbnkgUmVxdWVzdHMgUmVzcG9uc2Ug Q29kZSBmb3IgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sDQo+Pj4gRG9jdW1l bnQgZGF0ZTogICAgICAgIDIwMTgtMDMtMDUNCj4+PiBHcm91cDogICAgICAgICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+Pj4gUGFnZXM6ICAgICAgICAgICAgICAgIDQNCj4+PiBVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtl cmFuZW4tY29yZS10b28tbWFueS1yZXFzLTAwLnR4dA0KPj4+IFN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rZXJhbmVuLWNvcmUtdG9vLW1hbnkt cmVxcy8NCj4+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWtlcmFuZW4tY29yZS10b28tbWFueS1yZXFzLTAwDQo+Pj4gSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQta2VyYW5lbi1jb3JlLXRv by1tYW55LXJlcXMtMDANCj4+PiANCj4+PiANCj4+PiBBYnN0cmFjdDoNCj4+PiAgQSBDb25zdHJh aW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgc2VydmVyIGNhbiBleHBlcmllbmNlDQo+ Pj4gIHRlbXBvcmFyeSBvdmVybG9hZCBiZWNhdXNlIG9uZSBvciBtb3JlIGNsaWVudHMgYXJlIHNl bmRpbmcgcmVxdWVzdHMNCj4+PiAgdG8gdGhlIHNlcnZlciBhdCBhIGhpZ2hlciByYXRlIHRoYW4g dGhlIHNlcnZlciBpcyBjYXBhYmxlIG9yIHdpbGxpbmcNCj4+PiAgdG8gaGFuZGxlLiAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgbmV3IENvQVAgUmVzcG9uc2UgQ29kZSBmb3IgYQ0KPj4+ICBzZXJ2 ZXIgdG8gaW5kaWNhdGUgdGhhdCBhIGNsaWVudCBzaG91bGQgcmVkdWNlIHRoZSByYXRlIG9mIHJl cXVlc3RzLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N Cj4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPj4+IA0KPj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Mar 8 05:06:34 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400B0126CE8 for ; Thu, 8 Mar 2018 05:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DcQ9UcA4pKEq for ; Thu, 8 Mar 2018 05:06:26 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 33C25126CD6 for ; Thu, 8 Mar 2018 05:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520514384; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3IRF6lvpc9vgIYjUmhjkfSFqiM04lTWt5dMgeNe16J0=; b=EqxSArJesfXb+mFykAHJwziYSJpq0tVHybI4qpuqKdUrBNvhSK0MOjOyiwawjztd 2M2XKoj7/eaf2ybLE4yL3kwGG41lDM4UvossiS+BjvSCVVBHm4uSNPiLghuvXRcm 5Xbmfkl8jmesYrmqN2FQrzp510aFNbNXCvAIJjbjWFo=; X-AuditID: c1b4fb25-44ba69c000002d5f-91-5aa135507c2f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.DC.11615.05531AA5; Thu, 8 Mar 2018 14:06:24 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 14:05:22 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Klaus Hartke CC: Michael Koster , core Thread-Topic: "No Content" CoAP option (was Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)) Thread-Index: AQHTtt4dttxtKX0IgU+ewEr/qg/bDw== Date: Thu, 8 Mar 2018 13:05:22 +0000 Message-ID: <753934EB-16DB-4AD9-915E-1A9298FAA1A1@ericsson.com> References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> <2599BFCF-9A26-40BE-95E1-FBFF6B1ECDD4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <199131956D0DFC46A7C9318279D94CDF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2J7oG6A6cIog3s94hb73q5ntniz/zaT xbT28+wOzB47Z91l91iy5CeTx4sP7YwBzFFcNimpOZllqUX6dglcGXtvWxTc5q641zSTuYFx DWcXIyeHhICJRMvl5cxdjFwcQgKHGSX6G/cwQjiLGCW6L59hBqliE7CXmLzmIyOILSKgIXF4 +k0WEJtZwE2iYXkbC0iDsEA3o8Sj9i1gjojABEaJX2v3skN06ElsW/EcrINFQEVi+9UesKm8 QFPb1/8BmyokcJRJYuaZOBCbUyBQYlvHVFYQm1FATOL7qTVMENvEJW49mc8EcbeAxJI955kh bFGJl4//sULY8hIzzt6CqteTuDF1ChuEbS3Rd+89M4StLbFs4WuoGwQlTs58wjKBUWwWkhWz kLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtvBLb9VdzBefuN4 iFGAg1GJh9dfb2GUEGtiWXFl7iFGCQ5mJRHeAH2gEG9KYmVValF+fFFpTmrxIUZpDhYlcd45 wu1RQgLpiSWp2ampBalFMFkmDk6pBkbX5fy1b/+cPbmb+Zdq7z+XEAXeX+0qKUopwZOWdlRN Lds4wfIwqyb//swLfI9eRcQv+yPdKckuWGTRarmrqsfGsTbi6Pub675X2Z/wnRj7JusOm7zX pedGfaHyKf6POopfCe8y0OP+dK9vw79ddtwFP/4vOHnlqerv28eCWzhOTfv59ezS2AtKLMUZ iYZazEXFiQAe2BR7swIAAA== Archived-At: Subject: [core] "No Content" CoAP option (was Re: "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 13:06:33 -0000 > On 5 Mar 2018, at 19.51, Klaus Hartke wrote: >=20 > Michael Koster wrote: >> We are proposing a code in Pub/Sub for the case of a broker where the to= pic >> exists but there is not a valid data value. >=20 > This sounds strangely familiar: > https://tools.ietf.org/html/draft-hartke-core-pending-02 The 2.05 "Content Pending" has indeed quite similar semantics to our propos= al and should work for pub/sub too. But the dual use of the "X" vs. "X pending" was a bit unclear in the draft = now. Maybe it's worth clarifying already in the intro that it's the new pay= load format that indicates this difference. Could also mention explicitly t= hat these are not new Response Codes, since that's probably what most reade= rs would expect this draft to specify. >> We thought that an equivalent to the HTTP 204 "No Content" could be used= but >> the code conflicts with 2.04 in CoAP, so we propose 2.07 >=20 > We had that in the -01 version of the draft, but that didn't seem to > gain traction, so we've switched to a new content-format to indicate > this status. Would this work for pub/sub? Do you remember what was the reason for lack of traction?=20 Implementation-wise it seems slightly simpler to handle different "error/pe= nding" cases just by looking at the response code and not having to bother = about the payload type, but I don't have a strong opinion on this (or an im= plementation, at least yet). Cheers, Ari = From nobody Thu Mar 8 05:33:55 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90851126CE8; Thu, 8 Mar 2018 05:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=GiVihpOP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f0ElIKcK 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 pGxN9goDDWI3; Thu, 8 Mar 2018 05:33:45 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E0B126CD6; Thu, 8 Mar 2018 05:33:45 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9461420EA6; Thu, 8 Mar 2018 08:33:44 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 08 Mar 2018 08:33:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=7SVgAdg6THFhL2AD1nC+JG9qUIUCd PfEd3ehO9xc3c4=; b=GiVihpOPpG0yk34cdo/fgkdsJhgi5KXNzQPXDzceJCkVb KYZaNjYCntjpXs4fo3f7/keZarUf2RXbbLtKmIDwfkIgpVyjE4Thg82RxeNfm7fc 6LbagILk/yM+f3BZ8Aw+VJhbD6GNMhoH7KgTYZbgspy6Ap5ZJwVVFlh+03thLq01 AYl+SOI7K3ZJf4yHm7MLQD/IIK5ZIszFYhgyocVWJR/C0imG53CWP9HmqcNWg/ur FQ7SDNq0PaT1Wzq2qGOdEyYZo7Baih+hsd5K48BZHNkcNknEBhiAHSQtLPhlMMiB vY+4MgQ5dWHSbcp0rFBTaakt2nqUB+TRNUY9Blz0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7SVgAd g6THFhL2AD1nC+JG9qUIUCdPfEd3ehO9xc3c4=; b=f0ElIKcKD6v7g4a2Fse1So hCo640MRfbJxekkHbKhVrsMXIhUWgLKJWkgUb/S447F+7u1Cn/A3UqvaNqxcKbfC kRTt0iZCCa2N6EasJZ7EePaJBjQlM16Ng1BRFLcY+fNfwx+to/A0zT8Ze7q7rtjf kQgycrfyj9khfg4HnsEGCe1OXvM5+6T77GykKEKCDXhAHHyAnfVWRod93r23x13k 3oHyNfDJ6tOsF2Qj55UonPAyNUHVOXXVyioep/CkB4M87w97Xw6z54Q+ZTNv5LFm rqjHjAhe2BBFv5WDXR24H+zFW9oIajFpXmTFI0d2CWqv1Yj7zuHNtDaGJtx05/+g == X-ME-Sender: Received: from [10.19.234.245] (unknown [128.107.241.170]) by mail.messagingengine.com (Postfix) with ESMTPA id 4DABE7E539; Thu, 8 Mar 2018 08:33:43 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Thu, 8 Mar 2018 08:33:41 -0500 Cc: =?utf-8?Q?G=C3=B6ran_Selander?= , "gen-art@ietf.org" , "draft-ietf-core-object-security.all@ietf.org" , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <151927150372.21177.1992679615718735268@ietfa.amsl.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 13:33:48 -0000 Joel, thanks for your review. G=C3=B6ran, thanks for addressing Joel=E2=80= =99s comment. Unfortunately I ran out of time to review this document = before the telechat. Alissa > On Feb 23, 2018, at 9:40 AM, Joel M. Halpern = wrote: >=20 > Yes, that is what I was looking for. > Thank you, > Joel >=20 > On 2/23/18 9:38 AM, G=C3=B6ran Selander wrote: >> How about this (see the last and third to last edit): >> https://github.com/core-wg/oscoap/commit/8f277d83 >> where the reference is made to COSE instead of AEAD? >> Best >> G=C3=B6ran >> On 2018-02-23 15:32, "Joel Halpern Direct" = >> wrote: >>> I guess it is up to you. Personally, I like the idea of the verify >>> description including some reference to how one actually does = verify. >>> I will leave it to the authors and WG to decide what degree of = clarity >>> is called for here. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 2/23/18 9:30 AM, G=C3=B6ran Selander wrote: >>>> Hi Joel, >>>>=20 >>>> Thanks for quick feedback, inline. >>>>=20 >>>> On 2018-02-23 14:59, "Joel M. Halpern" wrote: >>>>=20 >>>>> In terms of my concerns, if Step 7 said "Verify and Decrypt the = COSE >>>>> object using the Recipient Key as per RFC 5116 Section 2.2" that = would >>>>> fill in the confusion for this reader. >>>>=20 >>>> Since the AEAD is used throughout the draft, in particular in other >>>> parts >>>> of this section I=E2=80=99m thinking that maybe we should add RFC = 5116 to the >>>> list >>>> of specifications following "Readers are expected to be familiar = with=E2=80=9D >>>> in >>>> Section 1.1. Would that address your comment? >>>>=20 >>>> Thanks >>>> G=C3=B6ran >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 2/23/18 5:26 AM, G=C3=B6ran Selander wrote: >>>>>> Hi Joel, >>>>>>=20 >>>>>> Thanks for your review. Comments inline. >>>>>>=20 >>>>>>=20 >>>>>> On 2018-02-22 04:51, "Joel Halpern" wrote: >>>>>>=20 >>>>>>> Reviewer: Joel Halpern >>>>>>> Review result: Ready with Nits >>>>>>>=20 >>>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>>> by the IESG for the IETF Chair. Please treat these comments = just >>>>>>> like any other last call comments. >>>>>>>=20 >>>>>>> For more information, please see the FAQ at >>>>>>>=20 >>>>>>> . >>>>>>>=20 >>>>>>> Document: draft-ietf-core-object-security-08 >>>>>>> Reviewer: Joel Halpern >>>>>>> Review Date: 2018-02-21 >>>>>>> IETF LC End Date: 2018-03-02 >>>>>>> IESG Telechat date: 2018-03-08 >>>>>>>=20 >>>>>>> Summary: This document is ready for publication as a Proposed >>>>>>> Standard >>>>>>> RFC >>>>>>>=20 >>>>>>> Major issues: N/A >>>>>>>=20 >>>>>>> Minor issues: >>>>>>> In section 8.2 on verifying the request, step 5 says to >>>>>>> "compose" >>>>>>> the >>>>>>> Additional Authentication Data. I would have expected it = to be >>>>>>> "verify" >>>>>>> the Additional Authentication Data. I could imagine that = the >>>>>>> verification >>>>>>> consists of composing what it should be, and then comparing = with >>>>>>> what >>>>>>> is >>>>>>> received. But I do not see the comparison step. is it >>>>>>> implicit in >>>>>>> some >>>>>>> other step? This occurs again in 8.4, so I presume I am = simply >>>>>>> missing >>>>>>> something. This may suggest some clarification could be = useful. >>>>>>=20 >>>>>> The AAD is indeed =E2=80=9Ccomposed" both on encrypting and = decrypting side >>>>>> from >>>>>> data which needs to be known to the endpoint at the time when the = AEAD >>>>>> operation is performed. The authenticated decryption process is >>>>>> described >>>>>> in: >>>>>>=20 >>>>>> https://tools.ietf.org/html/rfc5116#section-2.2 >>>>>>=20 >>>>>> So the verification consists of feeding the input, including the = AAD, >>>>>> to >>>>>> the authenticated decryption which calculates the plain text or = FAIL, >>>>>> and >>>>>> a failure may be - but is not necessarily - caused by wrong AAD. >>>>>>=20 >>>>>> The AD review also indicated that we should move the reference to = RFC >>>>>> 5116 >>>>>> to an early section in the draft and that change is already = included >>>>>> in >>>>>> the latest version on the CoRE WG Github. >>>>>>=20 >>>>>>=20 >>>>>> Best regards >>>>>> G=C3=B6ran >>>>>>=20 >>>>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Mar 8 06:33:48 2018 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 57A8B1241F8; Thu, 8 Mar 2018 06:33:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-core-object-security@ietf.org, Carsten Bormann , jaime.jimenez@ericsson.com, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152051962735.13922.9383105410719725254.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2018 06:33:47 -0800 Archived-At: Subject: [core] Kathleen Moriarty's Yes on draft-ietf-core-object-security-09: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 14:33:47 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-core-object-security-09: Yes 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-object-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I strongly support an object level security solution to provide end-to-end security when traffic traverses proxies or is relayed in the case of many IoT scenarios. There are billions of devices in the IoT space with different constraints and operating requirements. As such, I support and appreciate your work on this draft. I had already known that this work was decoupled from EDHOC and appreciate that it can now be used either with TLS, EDHOC, or some other transport security protocol to offer object level security and protection in transit for data. Thanks for addressing the OpsDir review a couple of weeks ago that pointed out where the work for provisioning the master secret, use of pre-shared keys in some scenarios, the use of profiles for algorithm agility, and the candidate key exchange protocols are done and other questions on security considerations and MTI. Since EKR's review pointed some of these same things out, having the pointers more clearly stated in the draft would be beneficial to the reader and implementer. Perhaps a longer discussion is needed in the draft. Where there are still multiple candidate drafts, you may not want to name one yet, but rather point to existing work. Thanks again! From nobody Thu Mar 8 06:59:45 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A12120713 for ; Thu, 8 Mar 2018 06:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 amUsiYewatGw for ; Thu, 8 Mar 2018 06:59:38 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 A07B21241F8 for ; Thu, 8 Mar 2018 06:59:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520521173; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TWQz6hxgN3LOxsAdA6hgljBRRgPyWMoQZMx2nGFjKMA=; b=RgQBGf+sFy1kgD+O41cN2ptxVex/0M/dztpcdrhHTkAjUMEGJhCvIALkgo+RMn7v Qz4E2XIpHy+BpUFB+sBRzlitxbKawELsTSUrKf/U0XWdffikf8wjGPLJvW5Vntex 1t4u/BlSGkdFRAObnoJzWidxR4SqMJ3v78LspjVrUfc=; X-AuditID: c1b4fb30-399ff70000004778-0c-5aa14fd46764 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.5A.18296.4DF41AA5; Thu, 8 Mar 2018 15:59:32 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.88]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 15:59:32 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eric Rescorla , The IESG CC: "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) Thread-Index: AQHTtolfO1SWXHzYR0WCPxFNrQ+jVKPGbw+A Date: Thu, 8 Mar 2018 14:59:31 +0000 Message-ID: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> In-Reply-To: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: text/plain; charset="utf-8" Content-ID: <5D57A2E1F6F9F949A92B45E794B28C9F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7ru4V/4VRBh3vrS2OTLnLarFt4wU2 i31v1zNbTPt3hsVixetz7BYz/kxkdmDzWLLkJ5PH5MdtzB7TFmUGMEdx2aSk5mSWpRbp2yVw ZZzu/MBecCGvYtbBBtYGxifZXYycHBICJhIH7zxh7GLk4hASOMwosXh2FytIQkhgEaPEl/Yc EJtNwEXiQcMjJhBbRMBK4tXvaywgDcwCE5gkflxYxQ6SEBbIkGh/84oRoihT4une9awQtpHE gr8NYDaLgIrE64l3mbsYOTh4BSwkDtxghtjlK3HlYTOYzSngJ/Fj1hqwckYBMYnvp9aA7WUW EJe49WQ+E8TRAhJL9pxnhrBFJV4+/gdWLyqgJ7G3p50NZLyEgJJEzwYpEJNZQFNi/S59iCnW Ei8fdbBB2IoSU7ofgh3PKyAocXLmE5YJjOKzkCybhdA9C0n3LCTds5B0L2BkXcUoWpxanJSb bmSkl1qUmVxcnJ+nl5dasokRGJkHt/w22MH48rnjIUYBDkYlHl5pp4VRQqyJZcWVuYcYJTiY lUR4A/SBQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqemFqQWwWSZODilGhhZ jN2yD9qpXPZfc/gmQ01DeGKWzsTfq7KE6vcmMZ112PMkLc026b0F/z3na2ufsffyqcvO6bh1 vXyWk4DBapOiZb1zHvEuCOVdXq+SKt2UGHJ0568J35I9fadtv+716++0Wm/hAMV5VxcKvTsv slNY+5iu1AkOj+0TUzljVnpuFZ79SKLzMYcSS3FGoqEWc1FxIgClt8v0yAIAAA== Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 14:59:40 -0000 SGkgRXJpYyBhbmQgb3RoZXJzIHdobyBwcm92aWRlZCByZXZpZXcgY29tbWVudHMsDQoNClRoYW5r cyBmb3IgeW91ciByZXZpZXdzLiBXZSB3aWxsIGdldCBiYWNrIHdpdGggbW9yZSBkZXRhaWxlZCBh bnN3ZXJzLCBidXQNCmp1c3Qgc29tZSByZW1hcmtzIG9uIHJlY3VycmluZyBjb21tZW50cy4NCg0K VGhlIHJlYXNvbiBmb3IgaW5jbHVkaW5nIENvQVAtbWFwcGFibGUgSFRUUCBpcyB0byBoYW5kbGUg c2V0dGluZ3MgbGlrZQ0KSFRUUCBjbGllbnQgdG8gQ29BUCBzZXJ2ZXIgb3Igdi52LiBUaGVyZSBh cmUgYSBudW1iZXIgb2YgdXNlIGNhc2VzIGZvcg0KdGhpcy4gT0NGL0RhdmUgVGhhbGVyIGhhcyBy ZXF1ZXN0ZWQgdGhpcyBmdW5jdGlvbmFsaXR5IGZvciB0aGVpcg0KZW5kLXRvLWVuZCBSRVNUIGZ1 bmN0aW9uYWxpdHkuIEEgcmVjZW50IGV4YW1wbGUgaXMgcHJvdmlkZWQgYnk6DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2UtY29hcC1lc3QtMDAjc2VjdGlvbi02DQpB ZG1pdHRlZGx5LCB0aGUgY3VycmVudCB0ZXh0IGRvZXMgbm90IHN1ZmZpY2llbnRseSB3ZWxsIHNj b3BlIHRvIHRoaXMNCnNldHRpbmcgYW5kIHdlIHdpbGwgY2hhbmdlIHRoYXQgaW4gYWRkaXRpb24g dG8gYWRkcmVzc2luZyB0aGUgb3RoZXINCmRldGFpbGVkIGNvbW1lbnRzIGFib3V0IEhUVFAuDQoN CkFub3RoZXIgcmVjdXJyaW5nIGNvbW1lbnQgaXMgdGhlIGltcGFjdCBvZiBhIHByb3h5IGNoYW5n aW5nIGNlcnRhaW4gQ29BUA0KbWVzc2FnZSBmaWVsZHMgbGlrZSBlLmcuIE1lc3NhZ2UgSUQsIFRv a2VuIG9yIFVyaS1Ib3N0LiBTaW5jZSBDb0FQIGRlZmluZXMNCmxlZ2l0aW1hdGUgcHJveHkgb3Bl cmF0aW9ucywgdGhlc2UgbWVzc2FnZSBmaWVsZHMgY2Fubm90IGJlIGludGVncml0eQ0KcHJvdGVj dGVkIGVuZC10by1lbmQuIEN1cnJlbnQgc2VjdXJpdHkgc29sdXRpb25zIGVpdGhlciBkb2VzIG5v dCBhbGxvdw0KcHJveHkgb3BlcmF0aW9ucyBvciBsZWF2ZSBhbGwgbWVzc2FnZSBmaWVsZHMgdW5w cm90ZWN0ZWQgaW4gdGhlIHByb3h5LiBXZQ0Kd2lsbCB0cnkgdG8gbWFrZSB0aGlzIG1vcmUgY2xl YXIuDQoNCkEgdGhpcmQgdGhpbmcgaW4gRXJpY+KAmXMgcmV2aWV3IGlzIHRoZSBjb25zdHJ1Y3Rp b24gb2YgdGhlIG5vbmNlIHdoZXJlIHRoZQ0KSUQgaXMgaW5jbHVkZWQuIFRoZSByZWFzb24gZm9y IHRoaXMgaXMgdG8gaGFuZGxlIGVuZHBvaW50cyBzd2l0Y2hpbmcgcm9sZXMNCihDb0FQIGNsaWVu dCA8LT4gQ29BUCBzZXJ2ZXIpICB3aGljaCBpcyBzdXBwb3J0ZWQgYnkgQ29BUCwgYW5kIGluDQpw YXJ0aWN1bGFyIA0KZ3JvdXAgY29tbXVuaWNhdGlvbnMgd2l0aCBvbmUgc2VuZGVyIGFuZCBtdWx0 aXBsZSByZWNpcGllbnRzLiBXaGlsZSB0aGUNCmxhdHRlciBpcyB0aGUgdG9waWMgb2YgYSBzZXBh cmF0ZSBkcmFmdA0KKGRyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXApIGFuZCB0aGUg cHJvcGVydGllcyBpbiB0aGF0IHNldHRpbmcgaXMNCm91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0 LCB3ZSB3aWxsIGFkZCBtb3JlIGV4cGxhbmF0aW9uIHRvIHRoZSBzZWN1cml0eQ0KZGVzaWduIGFu ZCB0aGUgdW5pY2FzdCBzZWN1cml0eSBwcm9wZXJ0aWVzIGluIGdlbmVyYWwgdG8gdGhpcyBkcmFm dC4NCg0KDQpNb3JlIGxhdGVyLg0KDQpHw7ZyYW4NCg0KDQoNCg0KT24gMjAxOC0wMy0wOCAwMzo1 OCwgIkVyaWMgUmVzY29ybGEiIDxla3JAcnRmbS5jb20+IHdyb3RlOg0KDQo+RXJpYyBSZXNjb3Js YSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj5kcmFmdC1p ZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTA5OiBEaXNjdXNzDQo+DQo+V2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXMNCj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4NCj4N Cj5QbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQo+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4NCj4NCj5UaGUgZG9jdW1lbnQsIGFsb25nIHdp dGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS8N Cj4NCj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+RElTQ1VTUzoNCj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+ aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDMwNzUNCj4NCj5ESVND VVNTDQo+TXkgb3ZlcmFsbCBjb25jZXJuIHdpdGggdGhpcyBkb2N1bWVudCBpcyB0aGF0IEkgYW0g dW5hYmxlIHRvIGV2YWx1YXRlDQo+dGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhlIHN5c3Rl bS4gSSBoYXZlIGRlc2NyaWJlZCBhIG51bWJlciBvZg0KPmlzc3VlcyBiZWxvdywgYnV0IHRoZSBi YXNpYyBwcm9ibGVtIGlzIHRoYXQgdGhpcyBzb3J0IG9mIHBhcnRpYWwNCj5wcm90ZWN0aW9uIGlz IGV4dHJlbWVseSBoYXJkIHRvIHJlYXNvbiBhYm91dCBhbmQgdGhlIHNlY3VyaXR5DQo+Y29uc2lk ZXJhdGlvbnMgZG8gbm90IGRvIGFuIGFkZXF1YXRlIGpvYiBvZiBldmFsdWF0aW5nIHRoZSBpbXBh Y3Qgb2YNCj5wcm94aWVzIG1vZGlmeWluZyB0aGVzZSB2YWx1ZXMuIEkgYW0gc2ltaWxhcmx5IGNv bmNlcm5lZCBhYm91dCB0aGUNCj5IVFRQIG1hcHBpbmcgYW5kIGxpbmsgc2VjdGlvbiB3aGljaCBz ZWVtcyBleHRyZW1lbHkgc2tldGNoeSBhbmQgaGFzDQo+ZXNzZW50aWFsbHkgbm8gc2VjdXJpdHkg YW5hbHlzaXMsIGFuZCB5ZXQgcG90ZW50aWFsbHkgaGF2ZSBhIGxvdA0KPm9mIGxhbmRtaW5lcy4N Cj4NCj5BdCBtaW5pbXVtLCB0aGlzIGRvY3VtZW50IG5lZWRzIHRvIHdhbGsgdGhyb3VnaCB0aGUg aW1wbGljYXRpb25zDQo+b2YgbW9kaWZpY2F0aW9ucyBieSB0aGUgcHJveHkgdG8gZXZlcnkgdW5w cm90ZWN0ZWQgZmllbGQgaW4NCj50aGUgcHVyZSBDb0FQIGNvbnRleHQgYXMgd2VsbCBhcyB0aGUg SFRUUCBjb250ZXh0IChpZiB5b3Ugd2FudA0KPnRvIHJldGFpbiB0aGF0IGJpbmRpbmcpLg0KPg0K PiAgIGFyZSBnaXZlbiBpbiBBcHBlbmRpeCBBLiAgT1NDT1JFIGRvZXMgbm90IGRlcGVuZCBvbiB1 bmRlcmx5aW5nDQo+ICAgbGF5ZXJzLCBhbmQgY2FuIGJlIHVzZWQgYW55d2hlcmUgd2hlcmUgQ29B UCBvciBIVFRQIGNhbiBiZSB1c2VkLA0KPiAgIGluY2x1ZGluZyBub24tSVAgdHJhbnNwb3J0cyAo ZS5nLiwgW0ktRC5ib3JtYW5uLTZsby1jb2FwLTgwMi0xNS1pZV0pLg0KPg0KPklNUE9SVEFOVDog VGhpcyBkb2N1bWVudCBjbGFpbXMgdG8gYmUgYXBwbGljYWJsZSB0byBwcm90b2NvbHMgb3RoZXIN Cj50aGFuIENPQVAsIGluIHBhcnRpY3VsYXIgSFRUUC4gSGFzIHRoaXMgYmVlbiByZXZpZXdlZCBi eSB0aGUgSFRUUA0KPndvcmtpbmcgZ3JvdXA/IE1hcnRpbiBUaG9tc29uJ3MgcmV2aWV3IHN1Z2dl c3RzIHRoYXQgdGhpcyBpcyBvdXQgb2YNCj5zdGVwIHdpdGggSFRUUCBwcmFjdGljZS4NCj4NCj4g ICBJRHMgTVVTVCBiZSBsb25nIHVuaWZvcm1seSByYW5kb20gZGlzdHJpYnV0ZWQgYnl0ZSBzdHJp bmdzIHN1Y2ggdGhhdA0KPiAgIHRoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb25zIGlzIG5lZ2xp Z2libGUuDQo+DQo+SU1QT1JUQU5UOiBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoaXMgcGFyYWdy YXBoIGFuZCB0aGUgcHJldmlvdXMNCj5wYXJhZ3JhcGggaW50ZXJhY3QuIFlvdSBzYXkgdGhhdCB0 aGUgbWF4aW11bSBsZW5ndGggaXMgNyBvY3RldHMgaW4gdGhlDQo+cHJldmlvdXMgcGFyYWdyYXBo LCB3aGljaCBJIGRvbid0IHRoaW5rIHF1YWxpZmllcyBhcyAibG9uZyIuDQo+DQo+ICAgICAgICAg ICAgICAgICAgICAgfCAgIDEgfCBJZi1NYXRjaCAgICAgICAgfCB4IHwgICB8DQo+ICAgICAgICAg ICAgICAgICAgICAgfCAgIDMgfCBVcmktSG9zdCAgICAgICAgfCAgIHwgeCB8DQo+ICAgICAgICAg ICAgICAgICAgICAgfCAgIDQgfCBFVGFnICAgICAgICAgICAgfCB4IHwgICB8DQo+SU1QT1JUQU5U OiBXaHkgZG8geW91IHRoaW5rIHRoYXQgaXQncyBub3QgaW1wb3J0YW50IHRvIGhhdmUgaW50ZWdy aXR5DQo+cHJvdGVjdGlvbiBmb3IgVXJpLUhvc3QgYW5kIFVyaS1wb3J0Pw0KPg0KPiAgIE91dGVy IG9wdGlvbiBtZXNzYWdlIGZpZWxkcyAoQ2xhc3MgVSBvciBJKSBhcmUgdXNlZCB0byBzdXBwb3J0 IHByb3h5DQo+ICAgb3BlcmF0aW9ucy4NCj5JTVBPUlRBTlQ6IFRoaXMgc2VlbXMgcHJvYmxlbWF0 aWMgYmVjYXVzZSB0aGUgcHJveHkgY2Fubm90IHZlcmlmeSBjbGFzcyBJDQo+ZmllbGRzLg0KPg0K PiAgIGxheWVyIG9ubHksIGFuZCBub3QgdGhlIE1lc3NhZ2luZyBMYXllciAoU2VjdGlvbiAyIG9m IFtSRkM3MjUyXSksIHNvDQo+ICAgZmllbGRzIHN1Y2ggYXMgVHlwZSBhbmQgTWVzc2FnZSBJRCBh cmUgbm90IHByb3RlY3RlZCB3aXRoIE9TQ09SRS4NCj4NCj5JTVBPUlRBTlQ6IFRoaXMgc2VlbXMg ZXh0cmVtZWx5IGhhcmQgdG8gcmVhc29uIGFib3V0LiBXaGF0IGFyZSB0aGUNCj5pbXBsaWNhdGlv bnMgb2YgdGhlIHByb3h5IGJlaW5nIGFibGUgdG8gY2hhbmdlIHRoZXNlPw0KPg0KPiAgIG8gIHJl cXVlc3RfcGl2OiBjb250YWlucyB0aGUgdmFsdWUgb2YgdGhlICdQYXJ0aWFsIElWJyBpbiB0aGUg Q09TRQ0KPiAgICAgIG9iamVjdCBvZiB0aGUgcmVxdWVzdCAoc2VlIFNlY3Rpb24gNSkuDQo+DQo+ SU1QT1JUQU5UOiBJIHRoaW5rIHdoYXQgSSBhbSBnZXR0aW5nIGhlcmUgaXMgdGhhdCB0aGUgcmVx dWVzdF9waXYgaXMNCj51c2VkIHRvIHZlcmlmeSB0aGF0IHRoZSByZXF1ZXN0IGFuZCByZXNwb25z ZSBtYXRjaC4gSG93ZXZlciwgSSBkbyBub3QNCj5zZWUgdGhpcyBleHBsaWNpdGx5IHN0YXRlZCBh bnl3aGVyZSwgYW5kIGl0J3Mgbm90IGNsZWFyIHRvIG1lIGhvdyB0aGUNCj5jbGllbnQgaXMgc3Vw cG9zZWQgdG8gcmVjb3ZlciB0aGUgcmVxdWVzdF9waXYgYW5kIHRoZSB0ZXh0IGlzIHByZXR0eQ0K PnVuY2xlYXIgaGVyZT8gSXMgdGhlIGV4dGVybmFsX2FhZCBjYXJyaWVkIHNvbWV3aGVyZSBpbiB0 aGUgbWVzc2FnZT8gQW0NCj5JIHN1cHBvc2VkIHRvIHJlY29uc3RydWN0IGl0IGZyb20gdGhlIG1l c3NhZ2UgaWQ/DQo+DQo+ICAgRm9yIHJlc3BvbnNlcywgdGhlIG1lc3NhZ2UgYmluZGluZyBndWFy YW50ZWVzIHRoYXQgYSByZXNwb25zZSBpcyBub3QNCj4gICBvbGRlciB0aGFuIGl0cyByZXF1ZXN0 LiAgRm9yIHJlc3BvbnNlcyB3aXRob3V0IE9ic2VydmUsIHRoaXMgZ2l2ZXMNCj4NCj5JTVBPUlRB TlQ6IEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIGlzIHRydWUuIFdoYXQgaGFwcGVucyBvZiB0aGUN Cj5jb3VudGVycGFydHkgbGllcz8gV2hhdCBpcyB5b3VyIHRocmVhdCBtb2RlbD8NCj4NCj4gICBB biBleHRlbnNpb24gb2YgT1NDT1JFIG1heSBhbHNvIGJlIHVzZWQgdG8gcHJvdGVjdCBncm91cA0K PiAgIGNvbW11bmljYXRpb24gZm9yIENvQVAgW0ktRC50aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Nj b2FwXS4gIFRoZSB1c2UNCj4gICBvZiBPU0NPUkUgZG9lcyBub3QgYWZmZWN0IHRoZSBVUkkgc2No ZW1lIGFuZCBPU0NPUkUgY2FuIHRoZXJlZm9yZSBiZQ0KPiAgIHVzZWQgd2l0aCBhbnkgVVJJIHNj aGVtZSBkZWZpbmVkIGZvciBDb0FQIG9yIEhUVFAuICBUaGUgYXBwbGljYXRpb24NCj4gICBkZWNp ZGVzIHRoZSBjb25kaXRpb25zIGZvciB3aGljaCBPU0NPUkUgaXMgcmVxdWlyZWQuDQo+DQo+VGhp cyBpcyBwcmV0dHkgc3VycHJpc2luZyB0byBqdXN0IGRyb3AgaW4gaGVyZS4gTXVsdGljYXN0IGhh cyB0b3RhbGx5DQo+ZGlmZmVyZW50DQo+c2VjdXJpdHkgcHJvcGVydGllcyBmcm9tIG5vbi1tdWx0 aWNhc3QuDQo+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPg0KPg0KPiAgIGJ1dCBpcyBhbHNvIGFibGUgdG8gZWF2ZXNkcm9wIG9uLCBvciBtYW5pcHVs YXRlIGFueSBwYXJ0IG9mIHRoZQ0KPiAgIG1lc3NhZ2UgcGF5bG9hZCBhbmQgbWV0YWRhdGEsIGlu IHRyYW5zaXQgYmV0d2VlbiB0aGUgZW5kcG9pbnRzLiAgVGhlDQo+ICAgcHJveHkgY2FuIGFsc28g aW5qZWN0LCBkZWxldGUsIG9yIHJlb3JkZXIgcGFja2V0cyBzaW5jZSB0aGV5IGFyZSBubw0KPk5p dDogeW91IHdhbnQNCj4iZWF2ZXNkcm9wIG9uLCBvciBtYW5pcHVsYXRlIGFueSBwYXJ0IG9mLCB0 aGUgbWVzc2FnZSBwYXlsb2FkIGFuZA0KPm1ldGFkYXRhIGluDQo+dHJhbnNpdCINCj4NCj5JLmUu LCBtb3ZlIHRoZSBzZWNvbmQgY29tbWENCj4NCj4gICB0aGUgZW5kcG9pbnRzLCBhbmQgdGhvc2Ug YXJlIHRoZXJlZm9yZSBwcm9jZXNzZWQgYXMgZGVmaW5lZCBpbg0KPiAgIFtSRkM3MjUyXS4gIEFk ZGl0aW9uYWxseSwgc2luY2UgdGhlIG1lc3NhZ2UgZm9ybWF0cyBmb3IgQ29BUCBvdmVyDQo+ICAg dW5yZWxpYWJsZSB0cmFuc3BvcnQgW1JGQzcyNTJdIGFuZCBmb3IgQ29BUCBvdmVyIHJlbGlhYmxl IHRyYW5zcG9ydA0KPk5pdDogIk9TQ09SRSBwcm90ZWN0cyBuZWl0aGVyIC4uLi4gbm9yLi4uLiIN Cj4NCj4gICAgICBTYWx0LiAgTGVuZ3RoIGlzIGRldGVybWluZWQgYnkgdGhlIEFFQUQgQWxnb3Jp dGhtLiAgSXRzIHZhbHVlIGlzDQo+PiAgICAgIGltbXV0YWJsZSBvbmNlIHRoZSBzZWN1cml0eSBj b250ZXh0IGlzIGVzdGFibGlzaGVkLg0KPk5pdDogeW91IG1pZ2h0IGp1c3Qgc2F5IGFib3ZlIG9y IGJlbG93IHRoaXMgbGlzdCB0aGF0IGFsbCB0aGUgdmFsdWVzIGFyZQ0KPmltbXV0YWJsZSwNCj4N Cj4gICBkaWZmZXJlbnQgb3BlcmF0aW9ucy4gIE9uZSBtZWNoYW5pc20gZW5hYmxpbmcgdGhpcyBp cyBzcGVjaWZpZWQgaW4NCj4gICBbSS1ELmlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnXS4NCj5J cyB0aGlzIGEgc2VjdXJpdHkgY29uZGl0aW9uPw0KPg0KPiAgICAgIG9mIFtSRkM3MjUyXSwgd2hl cmUgdGhlIGRlbHRhIGlzIHRoZSBkaWZmZXJlbmNlIHRvIHRoZSBwcmV2aW91c2x5DQo+ICAgICAg aW5jbHVkZWQgY2xhc3MgSSBvcHRpb24uDQo+SXMgdGhlIGRlbHRhIGhlcmUgdGhlIHByZXZpb3Vz bHkgaW5jbHVkZWQgQ2xhc3MgSSBvcHRpb24gb3IgdGhlIHByZXZpb3VzbHkNCj5pbmNsdWRlZCBp bnN0YW5jZSBvZiB0aGUgc2FtZSBvcHRpb24sIGFzIGl0IGFwcGVhcnMgdG8gc2F5IGluIFMgMy4x Lg0KPg0KPiAgICAgICAgIGNvbXByZXNzZWQgQ09TRSBvYmplY3QuICBUaGUgdmFsdWVzIG4gPSA2 IGFuZCBuID0gNyBhcmUNCj4gICAgICAgICByZXNlcnZlZC4NCj5Ib3cgY2FuIFBhcnRpYWwgSVYg bm90IGJlIHByZXNlbnQ/IGl0J3MgdGhlIHNlcXVlbmNlIG51bWJlci4gSXMgdGhlDQo+YW5zd2Vy IHRoYXQNCj5pdCBpcyB0aGUgMCB2YWx1ZT8NCj4NCj4gICByZXNwb25zZS4gIFRoZSBzZXJ2ZXIg dGhlcmVmb3JlIG5lZWRzIHRvIHN0b3JlIHRoZSBraWQgYW5kIFBhcnRpYWwgSVYNCj4gICBvZiB0 aGUgcmVxdWVzdCB1bnRpbCBhbGwgcmVzcG9uc2VzIGhhdmUgYmVlbiBzZW50Lg0KPkl0IHdhcyBt eSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGtpZCB3YXMgbmVlZGVkIHRvIGxvb2sgdXAgdGhlIGtl eS4gV2h5DQo+YXJlIGtpZA0KPnN1YnN0aXR1dGlvbiBhdHRhY2tzIGFuIGlzc3VlPw0KPg0KPiAg IFRoZSBtYXhpbXVtIFNlbmRlciBTZXF1ZW5jZSBOdW1iZXIgaXMgYWxnb3JpdGhtIGRlcGVuZGVu dCAoc2VlDQo+ICAgU2VjdGlvbiAxMSksIGFuZCBubyBncmVhdGVyIHRoYW4gMl40MCAtIDEuICBJ ZiB0aGUgU2VuZGVyIFNlcXVlbmNlDQo+ICAgTnVtYmVyIGV4Y2VlZHMgdGhlIG1heGltdW0sIHRo ZSBlbmRwb2ludCBNVVNUIE5PVCBwcm9jZXNzIGFueSBtb3JlDQo+SWYgeW91IHRha2UgbXkgc3Vn Z2VzdGlvbiBhYm91dCByZW1vdmluZyBzZW5kZXJJRCBmcm9tIHRoZSBub25jZSB5b3Ugd2lsbA0K PmJlDQo+YWJsZSB0byByZWxheCB0aGlzLg0KPg0KPiAgIEFmdGVyIGJvb3QsIGFuIGVuZHBvaW50 IE1BWSByZWplY3QgdG8gdXNlIGV4aXN0aW5nIHNlY3VyaXR5IGNvbnRleHRzDQo+ICAgZnJvbSBi ZWZvcmUgaXQgYm9vdGVkIGFuZCBNQVkgZXN0YWJsaXNoIGEgbmV3IHNlY3VyaXR5IGNvbnRleHQg d2l0aA0KPk5pdDogdGhpcyBpcyB1bmdyYW1tYXRpY2FsDQo+DQo+ICAgICAgIGluY2x1ZGVkIGlu IHRoZSBtZXNzYWdlLiAgSWYgdGhlIEFFQUQgbm9uY2UgZnJvbSB0aGUgcmVxdWVzdCB3YXMNCj4g ICAgICAgdXNlZCwgdGhlIFBhcnRpYWwgSVYgTVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4gdGhlIG1l c3NhZ2UuDQo+SU1QT1JUQU5UOiBZb3UgYXJlIG5vdyB2aW9sYXRpbmcgdGhlIGludmFyaWFudCBv ZiB1c2luZyB0aGUgc2FtZSBub25jZQ0KPnR3aWNlLg0KPlRoYXQncyBmaW5lIGluIHRoaXMgY2Fz ZSwgYmVjYXVzZSB5b3UgaGF2ZSBwZXItc2VuZGVyIGtleXMgYnV0IGl0DQo+ZGVtb25zdHJhdGVz DQo+dGhhdCBpdCBpcyB1bm5lY2Vzc2FyeSB0byBlbmNvZGUgdGhlIHNlbmRlcl9pZCBpbiB0aGUg bm9uY2UgZmllbGQuDQo+DQo+ICAgU2VjdXJpdHkgbGV2ZWwgaGVyZSBtZWFucyB0aGF0IGFuIGF0 dGFja2VyIGNhbiByZWNvdmVyIG9uZSBvZiB0aGUgbQ0KPiAgIGtleXMgd2l0aCBjb21wbGV4aXR5 IDJeKGsgKyBuKSAvIG0uICBQcm90ZWN0aW9uIGFnYWluc3Qgc3VjaCBhdHRhY2tzDQo+ICAgY2Fu IGJlIHByb3ZpZGVkIGJ5IGluY3JlYXNpbmcgdGhlIHNpemUgb2YgdGhlIGtleXMgb3IgdGhlIGVu dHJvcHkgb2YNCj5UaGlzIHBhcmFncmFwaCBpcyBleHRyZW1lbHkgaGFyZCB0byBmb2xsb3cgYnV0 IEkgYW0gbm90IHBlcnN1YWRlZCB0aGF0IGl0DQo+aXMNCj5jb3JyZWN0LiBEbyB5b3UgaGF2ZSBh IGNpdGF0aW9uIGZvciB0aGUgY2xhaW0gdGhhdCB5b3UgY2FuIGFkZCB0aGUga2V5DQo+ZW50cm9w eQ0KPmFuZCB0aGUgbm9uY2UgZW50cm9weSBsaWtlIHRoaXMuDQo+DQo+ICAgc3R5bGUgb2YgcGFk ZGluZyBtZWFucyB0aGF0IGFsbCB2YWx1ZXMgbmVlZCB0byBiZSBwYWRkZWQuICBTaW1pbGFyDQo+ ICAgYXJndW1lbnRzIGFwcGx5IHRvIG90aGVyIG1lc3NhZ2UgZmllbGRzIHN1Y2ggYXMgcmVzb3Vy Y2UgbmFtZXMuDQo+VGhlIFBLQ1MjNyBwYWRkaW5nIHNjaGVtZSBhdCBtaW5pbXVtIGhhcyBwb3Rl bnRpYWwgdGltaW5nIGNoYW5uZWxzDQo+DQo+ICAgVGhlIHNlcnZlciB2ZXJpZmllcyB0aGF0IHRo ZSBQYXJ0aWFsIElWIGhhcyBub3QgYmVlbiByZWNlaXZlZCBiZWZvcmUuDQo+ICAgVGhlIGNsaWVu dCB2ZXJpZmllcyB0aGF0IHRoZSByZXNwb25zZSBpcyBib3VuZCB0byB0aGUgcmVxdWVzdC4NCj5I b3cgZG9lcyB0aGUgY2xpZW50IHZlcmlmeSB0aGlzDQo+DQo+ICAgICAgIFBhcnRpYWwgSVYgKGlu IG5ldHdvcmsgYnl0ZSBvcmRlcikgd2l0aCB6ZXJvZXMgdG8gZXhhY3RseSBub25jZQ0KPiAgICAg ICBsZW5ndGggLSA2IGJ5dGVzLA0KPg0KPklNUE9SVEFOVDogSSBkb24ndCB1bmRlcnN0YW5kIHRo ZSByZWFzb24gZm9yIHRoaXMgY29uc3RydWN0aW9uLiBZb3UNCj5hbHJlYWR5IHJlcXVpcmUgdGhh dCB0aGUga2V5IGJlIGRlcml2ZWQgdmlhIEhLREYgZnJvbSB0aGUgfG1hc3RlciBrZXl8DQo+YW5k IHxzZW5kZXIgSUR8IHRoZXJlZm9yZSwgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IHRvIHNlcGFyYXRl bHkgZW5jb2RlDQo+dGhlIHNlbmRlciBJRCBpbiB0aGUgbm9uY2UuIFRoaXMgd291bGQgb3JkaW5h cmlseSBub3QgYmUgYSBsYXJnZQ0KPmlzc3VlLCBidXQgYXMgaXQgcmVxdWlyZXMgdmVyeSBleHRy ZW1lIHJlc3RyaWN0aW9ucyBvbiB0aGUgc2VuZGVyIElEDQo+KGFuZCBlc3NlbnRpYWxseSBwcmVj bHVkZXMgcmFuZG9tIHNlbmRlciBJRHMpIEkgYmVsaWV2ZSBpdCBpcyB3b3J0aA0KPmNvbnNpZGVy aW5nIGNoYW5naW5nLCBidXQgaXQncyB1bHRpbWF0ZWx5IGEgV0cgZGVjaXNpb24sIGhlbmNlIG5v dA0KPmluIG15IGRpc2N1c3MuDQo+DQo+DQoNCg== From nobody Thu Mar 8 07:07:41 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBDB127023 for ; Thu, 8 Mar 2018 07:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 7zK-fK1AHnYO for ; Thu, 8 Mar 2018 07:07:35 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 26964126CD6 for ; Thu, 8 Mar 2018 07:07:32 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id c7so7054479qtn.3 for ; Thu, 08 Mar 2018 07:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NUaAi6n0ZxtMYz5q8LajEvwB5piVDxwoefSANAcPSk0=; b=gxrMkW2DuE+DxxNW4NSG+w1/5HT4671gLGRatUUSEzONALEJF//KdjYrtHaAK38Bu1 u5b4fK/VT3uBuR85d4rpSSs712vJGsEbtllVfaq8wWhPADUfYmm+/VontEkMkYbK8qxL QmWVJ26gp3lho0HQs3/3vgCPE+UHPgWNUIY3m3/1MRSV9+Gb78XmUoqXZctxG7UbINPh Wvd6O7lsaN/RmSH7YCRwP6onb34MhEvDzCL8w9DbM0tecx+eOjkPrHf7hTOJA13BgquD jHr5SJzPJVEb913kh8rtiL8R6OXn1gQiphzA5NV4H7WbGy9/4TjOsvFT1gT1yoBxo1E0 xKmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NUaAi6n0ZxtMYz5q8LajEvwB5piVDxwoefSANAcPSk0=; b=KsLlGGi/Ikcn//gnmRm2I47sP3pjPLH1NKQysFM2oMah4tRUCy5qvCNIe6eIr1BDlf XS9VEXko8X1oLhnSKxrSLj5BYAw3Jl9E+5R7ZADmrdDRjPt9VpfiZdyx33lbze438HEG Wy0oQtPDdykVDJT1bOqYODuKI6pQw+384h+9iwuaxu3L7vhS2Fv4MsIeXUNakj0YI/G7 oAVjj/g7phv73jLICieXcpE+ynIC+xbMewoTwYjIprMqIqIc3sO9TJMuLfmPw3DCvr9+ u/0UQaeyMd3LO96BynfdA2C9mep/kthGJ8SMipmtT7VhPaHEtdBYL28PUKTtxRiBcl1p EBMg== X-Gm-Message-State: AElRT7HhQ/4EaMxKMiwvwjdTr9gGU0/kNBdXm1W9bYyt7sxK0k9+fqxx 7NRmKdwP1iQKIYGVi4/dRkuCR1L16PQ6zSCJKmMw/Q== X-Google-Smtp-Source: AG47ELuxXotURCYP8dd8QklHuSBKNRDITHHeiP2+z4S+SN6QrPimgXqtp97QLXHllROQWpbG50ib7eglzhjnXjXM9wY= X-Received: by 10.237.61.112 with SMTP id h45mr40426954qtf.225.1520521651059; Thu, 08 Mar 2018 07:07:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Thu, 8 Mar 2018 07:06:50 -0800 (PST) In-Reply-To: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 8 Mar 2018 07:06:50 -0800 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: The IESG , "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , "core-chairs@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="001a113520e0e297510566e80860" Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 15:07:38 -0000 --001a113520e0e297510566e80860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 8, 2018 at 6:59 AM, G=C3=B6ran Selander wrote: > Another recurring comment is the impact of a proxy changing certain CoAP > message fields like e.g. Message ID, Token or Uri-Host. Since CoAP define= s > legitimate proxy operations, these message fields cannot be integrity > protected end-to-end. Current security solutions either does not allow > proxy operations or leave all message fields unprotected in the proxy. We > will try to make this more clear. > The question is what the security impact of these is. > A third thing in Eric=E2=80=99s review is the construction of the nonce w= here the > ID is included. The reason for this is to handle endpoints switching role= s > (CoAP client <-> CoAP server) which is supported by CoAP, and in > particular > group communications with one sender and multiple recipients I don't see how that is relevant, given that you already have key separatio= n for the sender key, what separate information is there in the nonce? -Ekr > . While the > latter is the topic of a separate draft > (draft-tiloca-core-multicast-oscoap) and the properties in that setting i= s > out of scope of this draft, we will add more explanation to the security > design and the unicast security properties in general to this draft. > > > More later. > > G=C3=B6ran > > > > > On 2018-03-08 03:58, "Eric Rescorla" wrote: > > >Eric Rescorla has entered the following ballot position for > >draft-ietf-core-object-security-09: Discuss > > > >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.htm= l > >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-object-security/ > > > > > > > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >https://mozphab-ietf.devsvcdev.mozaws.net/D3075 > > > >DISCUSS > >My overall concern with this document is that I am unable to evaluate > >the security properties of the system. I have described a number of > >issues below, but the basic problem is that this sort of partial > >protection is extremely hard to reason about and the security > >considerations do not do an adequate job of evaluating the impact of > >proxies modifying these values. I am similarly concerned about the > >HTTP mapping and link section which seems extremely sketchy and has > >essentially no security analysis, and yet potentially have a lot > >of landmines. > > > >At minimum, this document needs to walk through the implications > >of modifications by the proxy to every unprotected field in > >the pure CoAP context as well as the HTTP context (if you want > >to retain that binding). > > > > are given in Appendix A. OSCORE does not depend on underlying > > layers, and can be used anywhere where CoAP or HTTP can be used, > > including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]). > > > >IMPORTANT: This document claims to be applicable to protocols other > >than COAP, in particular HTTP. Has this been reviewed by the HTTP > >working group? Martin Thomson's review suggests that this is out of > >step with HTTP practice. > > > > IDs MUST be long uniformly random distributed byte strings such that > > the probability of collisions is negligible. > > > >IMPORTANT: I don't understand how this paragraph and the previous > >paragraph interact. You say that the maximum length is 7 octets in the > >previous paragraph, which I don't think qualifies as "long". > > > > | 1 | If-Match | x | | > > | 3 | Uri-Host | | x | > > | 4 | ETag | x | | > >IMPORTANT: Why do you think that it's not important to have integrity > >protection for Uri-Host and Uri-port? > > > > Outer option message fields (Class U or I) are used to support proxy > > operations. > >IMPORTANT: This seems problematic because the proxy cannot verify class = I > >fields. > > > > layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so > > fields such as Type and Message ID are not protected with OSCORE. > > > >IMPORTANT: This seems extremely hard to reason about. What are the > >implications of the proxy being able to change these? > > > > o request_piv: contains the value of the 'Partial IV' in the COSE > > object of the request (see Section 5). > > > >IMPORTANT: I think what I am getting here is that the request_piv is > >used to verify that the request and response match. However, I do not > >see this explicitly stated anywhere, and it's not clear to me how the > >client is supposed to recover the request_piv and the text is pretty > >unclear here? Is the external_aad carried somewhere in the message? Am > >I supposed to reconstruct it from the message id? > > > > For responses, the message binding guarantees that a response is not > > older than its request. For responses without Observe, this gives > > > >IMPORTANT: I am not sure that this is true. What happens of the > >counterparty lies? What is your threat model? > > > > An extension of OSCORE may also be used to protect group > > communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use > > of OSCORE does not affect the URI scheme and OSCORE can therefore be > > used with any URI scheme defined for CoAP or HTTP. The application > > decides the conditions for which OSCORE is required. > > > >This is pretty surprising to just drop in here. Multicast has totally > >different > >security properties from non-multicast. > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > > > > > > but is also able to eavesdrop on, or manipulate any part of the > > message payload and metadata, in transit between the endpoints. The > > proxy can also inject, delete, or reorder packets since they are no > >Nit: you want > >"eavesdrop on, or manipulate any part of, the message payload and > >metadata in > >transit" > > > >I.e., move the second comma > > > > the endpoints, and those are therefore processed as defined in > > [RFC7252]. Additionally, since the message formats for CoAP over > > unreliable transport [RFC7252] and for CoAP over reliable transport > >Nit: "OSCORE protects neither .... nor...." > > > > Salt. Length is determined by the AEAD Algorithm. Its value is > >> immutable once the security context is established. > >Nit: you might just say above or below this list that all the values are > >immutable, > > > > different operations. One mechanism enabling this is specified in > > [I-D.ietf-core-echo-request-tag]. > >Is this a security condition? > > > > of [RFC7252], where the delta is the difference to the previously > > included class I option. > >Is the delta here the previously included Class I option or the previous= ly > >included instance of the same option, as it appears to say in S 3.1. > > > > compressed COSE object. The values n =3D 6 and n =3D 7 are > > reserved. > >How can Partial IV not be present? it's the sequence number. Is the > >answer that > >it is the 0 value? > > > > response. The server therefore needs to store the kid and Partial IV > > of the request until all responses have been sent. > >It was my understanding that the kid was needed to look up the key. Why > >are kid > >substitution attacks an issue? > > > > The maximum Sender Sequence Number is algorithm dependent (see > > Section 11), and no greater than 2^40 - 1. If the Sender Sequence > > Number exceeds the maximum, the endpoint MUST NOT process any more > >If you take my suggestion about removing senderID from the nonce you wil= l > >be > >able to relax this. > > > > After boot, an endpoint MAY reject to use existing security contexts > > from before it booted and MAY establish a new security context with > >Nit: this is ungrammatical > > > > included in the message. If the AEAD nonce from the request was > > used, the Partial IV MUST NOT be included in the message. > >IMPORTANT: You are now violating the invariant of using the same nonce > >twice. > >That's fine in this case, because you have per-sender keys but it > >demonstrates > >that it is unnecessary to encode the sender_id in the nonce field. > > > > Security level here means that an attacker can recover one of the m > > keys with complexity 2^(k + n) / m. Protection against such attacks > > can be provided by increasing the size of the keys or the entropy of > >This paragraph is extremely hard to follow but I am not persuaded that i= t > >is > >correct. Do you have a citation for the claim that you can add the key > >entropy > >and the nonce entropy like this. > > > > style of padding means that all values need to be padded. Similar > > arguments apply to other message fields such as resource names. > >The PKCS#7 padding scheme at minimum has potential timing channels > > > > The server verifies that the Partial IV has not been received before. > > The client verifies that the response is bound to the request. > >How does the client verify this > > > > Partial IV (in network byte order) with zeroes to exactly nonce > > length - 6 bytes, > > > >IMPORTANT: I don't understand the reason for this construction. You > >already require that the key be derived via HKDF from the |master key| > >and |sender ID| therefore, it is not necessarily to separately encode > >the sender ID in the nonce. This would ordinarily not be a large > >issue, but as it requires very extreme restrictions on the sender ID > >(and essentially precludes random sender IDs) I believe it is worth > >considering changing, but it's ultimately a WG decision, hence not > >in my discuss. > > > > > > --001a113520e0e297510566e80860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 8, 2018 at 6:59 AM, G=C3=B6ran Selander &= lt;goran.s= elander@ericsson.com> wrote:
A third thing in Eric=E2=80=99s review is the construction of the nonce whe= re the
ID is included. The reason for this is to handle endpoints switching roles<= br> (CoAP client <-> CoAP server)=C2=A0 which is supported by CoAP, and i= n
particular
group communications with one sender and multiple recipients

I don't see how that is relevant, given that you alre= ady have key separation
for the sender key, what separate informa= tion is there in the nonce?

-Ekr

=C2=A0
. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that settin= g is
out of scope of this draft, we will add more explanation to the security design and the unicast security properties in general to this draft.


More later.

G=C3=B6ran




On 2018-03-08 03:58, "Eric Rescorla" <ekr@rtfm.com> wrote:

>Eric Rescorla has entered the following ballot position for
>draft-ietf-core-object-security-09: Discuss
>
>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/ie= sg/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-object-security/
>
>
>
>-------------------------------------------------------------= ---------
>DISCUSS:
>-------------------------------------------------------------= ---------
>
>https://mozphab-ietf.devsvcdev.mozaws.net/D3= 075
>
>DISCUSS
>My overall concern with this document is that I am unable to evaluate >the security properties of the system. I have described a number of
>issues below, but the basic problem is that this sort of partial
>protection is extremely hard to reason about and the security
>considerations do not do an adequate job of evaluating the impact of >proxies modifying these values. I am similarly concerned about the
>HTTP mapping and link section which seems extremely sketchy and has
>essentially no security analysis, and yet potentially have a lot
>of landmines.
>
>At minimum, this document needs to walk through the implications
>of modifications by the proxy to every unprotected field in
>the pure CoAP context as well as the HTTP context (if you want
>to retain that binding).
>
>=C2=A0 =C2=A0are given in Appendix A.=C2=A0 OSCORE does not depend on u= nderlying
>=C2=A0 =C2=A0layers, and can be used anywhere where CoAP or HTTP can be= used,
>=C2=A0 =C2=A0including non-IP transports (e.g., [I-D.bormann-6lo-coap-8= 02-15-ie]).
>
>IMPORTANT: This document claims to be applicable to protocols other
>than COAP, in particular HTTP. Has this been reviewed by the HTTP
>working group? Martin Thomson's review suggests that this is out of=
>step with HTTP practice.
>
>=C2=A0 =C2=A0IDs MUST be long uniformly random distributed byte strings= such that
>=C2=A0 =C2=A0the probability of collisions is negligible.
>
>IMPORTANT: I don't understand how this paragraph and the previous >paragraph interact. You say that the maximum length is 7 octets in the<= br> >previous paragraph, which I don't think qualifies as "long&quo= t;.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A01 | If-Match=C2=A0 =C2=A0 =C2=A0 =C2=A0 | x |=C2=A0 =C2= =A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A03 | Uri-Host=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|= x |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A04 | ETag=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x |= =C2=A0 =C2=A0|
>IMPORTANT: Why do you think that it's not important to have integri= ty
>protection for Uri-Host and Uri-port?
>
>=C2=A0 =C2=A0Outer option message fields (Class U or I) are used to sup= port proxy
>=C2=A0 =C2=A0operations.
>IMPORTANT: This seems problematic because the proxy cannot verify class= I
>fields.
>
>=C2=A0 =C2=A0layer only, and not the Messaging Layer (Section 2 of [RFC= 7252]), so
>=C2=A0 =C2=A0fields such as Type and Message ID are not protected with = OSCORE.
>
>IMPORTANT: This seems extremely hard to reason about. What are the
>implications of the proxy being able to change these?
>
>=C2=A0 =C2=A0o=C2=A0 request_piv: contains the value of the 'Partia= l IV' in the COSE
>=C2=A0 =C2=A0 =C2=A0 object of the request (see Section 5).
>
>IMPORTANT: I think what I am getting here is that the request_piv is >used to verify that the request and response match. However, I do not >see this explicitly stated anywhere, and it's not clear to me how t= he
>client is supposed to recover the request_piv and the text is pretty >unclear here? Is the external_aad carried somewhere in the message? Am<= br> >I supposed to reconstruct it from the message id?
>
>=C2=A0 =C2=A0For responses, the message binding guarantees that a respo= nse is not
>=C2=A0 =C2=A0older than its request.=C2=A0 For responses without Observ= e, this gives
>
>IMPORTANT: I am not sure that this is true. What happens of the
>counterparty lies? What is your threat model?
>
>=C2=A0 =C2=A0An extension of OSCORE may also be used to protect group >=C2=A0 =C2=A0communication for CoAP [I-D.tiloca-core-multicast-osc= oap].=C2=A0 The use
>=C2=A0 =C2=A0of OSCORE does not affect the URI scheme and OSCORE can th= erefore be
>=C2=A0 =C2=A0used with any URI scheme defined for CoAP or HTTP.=C2=A0 T= he application
>=C2=A0 =C2=A0decides the conditions for which OSCORE is required.
>
>This is pretty surprising to just drop in here. Multicast has totally >different
>security properties from non-multicast.
>
>
>-------------------------------------------------------------= ---------
>COMMENT:
>-------------------------------------------------------------= ---------
>
>
>
>=C2=A0 =C2=A0but is also able to eavesdrop on, or manipulate any part o= f the
>=C2=A0 =C2=A0message payload and metadata, in transit between the endpo= ints.=C2=A0 The
>=C2=A0 =C2=A0proxy can also inject, delete, or reorder packets since th= ey are no
>Nit: you want
>"eavesdrop on, or manipulate any part of, the message payload and<= br> >metadata in
>transit"
>
>I.e., move the second comma
>
>=C2=A0 =C2=A0the endpoints, and those are therefore processed as define= d in
>=C2=A0 =C2=A0[RFC7252].=C2=A0 Additionally, since the message formats f= or CoAP over
>=C2=A0 =C2=A0unreliable transport [RFC7252] and for CoAP over reliable = transport
>Nit: "OSCORE protects neither .... nor...."
>
>=C2=A0 =C2=A0 =C2=A0 Salt.=C2=A0 Length is determined by the AEAD Algor= ithm.=C2=A0 Its value is
>>=C2=A0 =C2=A0 =C2=A0 immutable once the security context is establi= shed.
>Nit: you might just say above or below this list that all the values ar= e
>immutable,
>
>=C2=A0 =C2=A0different operations.=C2=A0 One mechanism enabling this is= specified in
>=C2=A0 =C2=A0[I-D.ietf-core-echo-request-tag].
>Is this a security condition?
>
>=C2=A0 =C2=A0 =C2=A0 of [RFC7252], where the delta is the difference to= the previously
>=C2=A0 =C2=A0 =C2=A0 included class I option.
>Is the delta here the previously included Class I option or the previou= sly
>included instance of the same option, as it appears to say in S 3.1. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compressed COSE object.=C2=A0 The val= ues n =3D 6 and n =3D 7 are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reserved.
>How can Partial IV not be present? it's the sequence number. Is the=
>answer that
>it is the 0 value?
>
>=C2=A0 =C2=A0response.=C2=A0 The server therefore needs to store the ki= d and Partial IV
>=C2=A0 =C2=A0of the request until all responses have been sent.
>It was my understanding that the kid was needed to look up the key. Why=
>are kid
>substitution attacks an issue?
>
>=C2=A0 =C2=A0The maximum Sender Sequence Number is algorithm dependent = (see
>=C2=A0 =C2=A0Section 11), and no greater than 2^40 - 1.=C2=A0 If the Se= nder Sequence
>=C2=A0 =C2=A0Number exceeds the maximum, the endpoint MUST NOT process = any more
>If you take my suggestion about removing senderID from the nonce you wi= ll
>be
>able to relax this.
>
>=C2=A0 =C2=A0After boot, an endpoint MAY reject to use existing securit= y contexts
>=C2=A0 =C2=A0from before it booted and MAY establish a new security con= text with
>Nit: this is ungrammatical
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0included in the message.=C2=A0 If the AEAD n= once from the request was
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used, the Partial IV MUST NOT be included in= the message.
>IMPORTANT: You are now violating the invariant of using the same nonce<= br> >twice.
>That's fine in this case, because you have per-sender keys but it >demonstrates
>that it is unnecessary to encode the sender_id in the nonce field.
>
>=C2=A0 =C2=A0Security level here means that an attacker can recover one= of the m
>=C2=A0 =C2=A0keys with complexity 2^(k + n) / m.=C2=A0 Protection again= st such attacks
>=C2=A0 =C2=A0can be provided by increasing the size of the keys or the = entropy of
>This paragraph is extremely hard to follow but I am not persuaded that = it
>is
>correct. Do you have a citation for the claim that you can add the key<= br> >entropy
>and the nonce entropy like this.
>
>=C2=A0 =C2=A0style of padding means that all values need to be padded.= =C2=A0 Similar
>=C2=A0 =C2=A0arguments apply to other message fields such as resource n= ames.
>The PKCS#7 padding scheme at minimum has potential timing channels
>
>=C2=A0 =C2=A0The server verifies that the Partial IV has not been recei= ved before.
>=C2=A0 =C2=A0The client verifies that the response is bound to the requ= est.
>How does the client verify this
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partial IV (in network byte order) with zero= es to exactly nonce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0length - 6 bytes,
>
>IMPORTANT: I don't understand the reason for this construction. You=
>already require that the key be derived via HKDF from the |master key|<= br> >and |sender ID| therefore, it is not necessarily to separately encode >the sender ID in the nonce. This would ordinarily not be a large
>issue, but as it requires very extreme restrictions on the sender ID >(and essentially precludes random sender IDs) I believe it is worth
>considering changing, but it's ultimately a WG decision, hence not<= br> >in my discuss.
>
>


--001a113520e0e297510566e80860-- From nobody Thu Mar 8 07:23:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43499127275 for ; Thu, 8 Mar 2018 07:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Hp722h21nZxp for ; Thu, 8 Mar 2018 07:23:31 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 839AA12704A for ; Thu, 8 Mar 2018 07:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520522601; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g/GeSAnuBPwTWy4LjVigHo6BOH/E4Qm8PPn6obCv9fw=; b=BK0fu/he8QLIZhZJVkv/6VFrjx6WabUGUlhlxugu01jtHulcDK9tb16lmQT59S/1 KafY9SjHsjgCEEpveXlJnVX9r3mptJ7Pjru2Cu9CVVKL96fOQF3Bz5pBHXYmX//D owZEFvSxNYdS3DLLzavOxQT3rpE+riSaGSVjjJ0rrzU=; X-AuditID: c1b4fb30-799639c000004778-e3-5aa15569e13e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F7.2F.18296.96551AA5; Thu, 8 Mar 2018 16:23:21 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.88]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 16:23:20 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eric Rescorla CC: The IESG , "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) Thread-Index: AQHTtolfO1SWXHzYR0WCPxFNrQ+jVKPGbw+A///xRQCAABVjAA== Date: Thu, 8 Mar 2018 15:23:20 +0000 Message-ID: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: multipart/alternative; boundary="_000_D6C710F5A15D5goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyM2K7lm5m6MIog0/79CyOTLnLarFt4wU2 i31v1zNbTPt3hsVixetz7BYz/kxkdmDzWLLkJ5PH5MdtzB7TFmUGMEdx2aSk5mSWpRbp2yVw ZSy7Ooel4P86pooJM9axNDC2LGfqYuTkkBAwkeh4tpuxi5GLQ0jgMKPEz19H2SGcRYwSc1f3 s4NUsQm4SDxoeATWISKgIPHrzwkWkCJmgVVMEj8PrGMDSQgLZEi0v3nFCFGUKfF073pWCNtJ 4tL6T8wgNouAisS/PR9YQGxeAQuJ5p1PmOFWf+5ZALaNUyBQYu2jp2ANjAJiEt9PrQHbzCwg LnHryXyouwUkluw5zwxhi0q8fPwPbJmogJ7E3p52oIM4gOJKEj0bpCBaYyW2rf3KCLFXUOLk zCcsExhFZyGZOgtJ2SwkZbOAJjELaEqs36UPUaIoMaX7ITuErSHROmculG0tMftrMyOymgWM HKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAqP34JbfBjsYXz53PMQowMGoxMMr7bQwSog1 say4MvcQowQHs5IIb4A+UIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILU IpgsEwenVAPj+ptrrbfcUuh6tfpE9FmH3jO985RjFlms1t1VKzZDe9U+rvVXdt/foXBrdsTP T2FsX+alGE9YavHq8eWVezZ89RbXfWqiIlf98p7f3TW+E2I8rsrKxsl+szPjDd4r6/zKu4/T QvcIc7zuHmeX9+8mveHtz579QT/9cNSU6PMy72aapXrdmsB7UImlOCPRUIu5qDgRAKJwYAXa AgAA Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 15:23:33 -0000 --_000_D6C710F5A15D5goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29t Pj4NCkRhdGU6IFRodXJzZGF5IDggTWFyY2ggMjAxOCBhdCAxNjowNg0KVG86IEfDtnJhbiBTZWxh bmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb20+Pg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGll dGYub3JnPj4sICJkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPiIgPGRyYWZ0LWlldGYt Y29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHlAaWV0Zi5vcmc+PiwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFp bHRvOmNhYm9AdHppLm9yZz4+LCBKYWltZSBKaW3DqW5leiA8amFpbWUuamltZW5lekBlcmljc3Nv bi5jb208bWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPj4sICJjb3JlLWNoYWlyc0Bp ZXRmLm9yZzxtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmc+IiA8Y29yZS1jaGFpcnNAaWV0Zi5v cmc8bWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnPj4sICJjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPiIgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHktMDk6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCg0KDQpPbiBUaHUs IE1hciA4LCAyMDE4IGF0IDY6NTkgQU0sIEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+PiB3cm90ZToN CkFub3RoZXIgcmVjdXJyaW5nIGNvbW1lbnQgaXMgdGhlIGltcGFjdCBvZiBhIHByb3h5IGNoYW5n aW5nIGNlcnRhaW4gQ29BUA0KbWVzc2FnZSBmaWVsZHMgbGlrZSBlLmcuIE1lc3NhZ2UgSUQsIFRv a2VuIG9yIFVyaS1Ib3N0LiBTaW5jZSBDb0FQIGRlZmluZXMNCmxlZ2l0aW1hdGUgcHJveHkgb3Bl cmF0aW9ucywgdGhlc2UgbWVzc2FnZSBmaWVsZHMgY2Fubm90IGJlIGludGVncml0eQ0KcHJvdGVj dGVkIGVuZC10by1lbmQuIEN1cnJlbnQgc2VjdXJpdHkgc29sdXRpb25zIGVpdGhlciBkb2VzIG5v dCBhbGxvdw0KcHJveHkgb3BlcmF0aW9ucyBvciBsZWF2ZSBhbGwgbWVzc2FnZSBmaWVsZHMgdW5w cm90ZWN0ZWQgaW4gdGhlIHByb3h5LiBXZQ0Kd2lsbCB0cnkgdG8gbWFrZSB0aGlzIG1vcmUgY2xl YXIuDQoNClRoZSBxdWVzdGlvbiBpcyB3aGF0IHRoZSBzZWN1cml0eSBpbXBhY3Qgb2YgdGhlc2Ug aXMuDQoNClllcywgYW5kIHdlIHdpbGwgdHJ5IHRvIGFkZHJlc3MgdGhpcy4gQnV0IGl0IGlzIGEg Z2VuZXJhbCBwcm9wZXJ0eSBvZiBDb0FQIHdoZW4gcHJveGllcyBhcmUgdXNlZC4NCg0KDQoNCkEg dGhpcmQgdGhpbmcgaW4gRXJpY+KAmXMgcmV2aWV3IGlzIHRoZSBjb25zdHJ1Y3Rpb24gb2YgdGhl IG5vbmNlIHdoZXJlIHRoZQ0KSUQgaXMgaW5jbHVkZWQuIFRoZSByZWFzb24gZm9yIHRoaXMgaXMg dG8gaGFuZGxlIGVuZHBvaW50cyBzd2l0Y2hpbmcgcm9sZXMNCihDb0FQIGNsaWVudCA8LT4gQ29B UCBzZXJ2ZXIpICB3aGljaCBpcyBzdXBwb3J0ZWQgYnkgQ29BUCwgYW5kIGluDQpwYXJ0aWN1bGFy DQpncm91cCBjb21tdW5pY2F0aW9ucyB3aXRoIG9uZSBzZW5kZXIgYW5kIG11bHRpcGxlIHJlY2lw aWVudHMNCg0KSSBkb24ndCBzZWUgaG93IHRoYXQgaXMgcmVsZXZhbnQsIGdpdmVuIHRoYXQgeW91 IGFscmVhZHkgaGF2ZSBrZXkgc2VwYXJhdGlvbg0KZm9yIHRoZSBzZW5kZXIga2V5LCB3aGF0IHNl cGFyYXRlIGluZm9ybWF0aW9uIGlzIHRoZXJlIGluIHRoZSBub25jZT8NCg0KVGhlIHNlbmRlciBr ZXkgaXMgdXNlZCBib3RoIGluIHRoZSByb2xlIG9mIGNsaWVudCBtYWtpbmcgYSByZXF1ZXN0ICh3 aXRoIG93biBwYXJ0aWFsIElWKSBhbmQgaW4gdGhlIHJvbGUgb2Ygc2VydmVyIHJlc3BvbmRpbmcg dG8gYSByZXF1ZXN0ICh3aXRoIHRoZSBvdGhlciBlbmRwb2ludOKAmXMgcGFydGlhbCBJVikuDQoN CkfDtnJhbg0KDQoNCi1Fa3INCg0KDQouIFdoaWxlIHRoZQ0KbGF0dGVyIGlzIHRoZSB0b3BpYyBv ZiBhIHNlcGFyYXRlIGRyYWZ0DQooZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcCkg YW5kIHRoZSBwcm9wZXJ0aWVzIGluIHRoYXQgc2V0dGluZyBpcw0Kb3V0IG9mIHNjb3BlIG9mIHRo aXMgZHJhZnQsIHdlIHdpbGwgYWRkIG1vcmUgZXhwbGFuYXRpb24gdG8gdGhlIHNlY3VyaXR5DQpk ZXNpZ24gYW5kIHRoZSB1bmljYXN0IHNlY3VyaXR5IHByb3BlcnRpZXMgaW4gZ2VuZXJhbCB0byB0 aGlzIGRyYWZ0Lg0KDQoNCk1vcmUgbGF0ZXIuDQoNCkfDtnJhbg0KDQoNCg0KDQpPbiAyMDE4LTAz LTA4IDAzOjU4LCAiRXJpYyBSZXNjb3JsYSIgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0u Y29tPj4gd3JvdGU6DQoNCj5FcmljIFJlc2NvcmxhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDk6 IERpc2N1c3MNCj4NCj5XaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj5lbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPmludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0KPlBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj5mb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K Pg0KPg0KPlRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZToNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5Lw0KPg0KPg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5E SVNDVVNTOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5odHRwczovL21venBoYWItaWV0Zi5kZXZzdmNk ZXYubW96YXdzLm5ldC9EMzA3NQ0KPg0KPkRJU0NVU1MNCj5NeSBvdmVyYWxsIGNvbmNlcm4gd2l0 aCB0aGlzIGRvY3VtZW50IGlzIHRoYXQgSSBhbSB1bmFibGUgdG8gZXZhbHVhdGUNCj50aGUgc2Vj dXJpdHkgcHJvcGVydGllcyBvZiB0aGUgc3lzdGVtLiBJIGhhdmUgZGVzY3JpYmVkIGEgbnVtYmVy IG9mDQo+aXNzdWVzIGJlbG93LCBidXQgdGhlIGJhc2ljIHByb2JsZW0gaXMgdGhhdCB0aGlzIHNv cnQgb2YgcGFydGlhbA0KPnByb3RlY3Rpb24gaXMgZXh0cmVtZWx5IGhhcmQgdG8gcmVhc29uIGFi b3V0IGFuZCB0aGUgc2VjdXJpdHkNCj5jb25zaWRlcmF0aW9ucyBkbyBub3QgZG8gYW4gYWRlcXVh dGUgam9iIG9mIGV2YWx1YXRpbmcgdGhlIGltcGFjdCBvZg0KPnByb3hpZXMgbW9kaWZ5aW5nIHRo ZXNlIHZhbHVlcy4gSSBhbSBzaW1pbGFybHkgY29uY2VybmVkIGFib3V0IHRoZQ0KPkhUVFAgbWFw cGluZyBhbmQgbGluayBzZWN0aW9uIHdoaWNoIHNlZW1zIGV4dHJlbWVseSBza2V0Y2h5IGFuZCBo YXMNCj5lc3NlbnRpYWxseSBubyBzZWN1cml0eSBhbmFseXNpcywgYW5kIHlldCBwb3RlbnRpYWxs eSBoYXZlIGEgbG90DQo+b2YgbGFuZG1pbmVzLg0KPg0KPkF0IG1pbmltdW0sIHRoaXMgZG9jdW1l bnQgbmVlZHMgdG8gd2FsayB0aHJvdWdoIHRoZSBpbXBsaWNhdGlvbnMNCj5vZiBtb2RpZmljYXRp b25zIGJ5IHRoZSBwcm94eSB0byBldmVyeSB1bnByb3RlY3RlZCBmaWVsZCBpbg0KPnRoZSBwdXJl IENvQVAgY29udGV4dCBhcyB3ZWxsIGFzIHRoZSBIVFRQIGNvbnRleHQgKGlmIHlvdSB3YW50DQo+ dG8gcmV0YWluIHRoYXQgYmluZGluZykuDQo+DQo+ICAgYXJlIGdpdmVuIGluIEFwcGVuZGl4IEEu ICBPU0NPUkUgZG9lcyBub3QgZGVwZW5kIG9uIHVuZGVybHlpbmcNCj4gICBsYXllcnMsIGFuZCBj YW4gYmUgdXNlZCBhbnl3aGVyZSB3aGVyZSBDb0FQIG9yIEhUVFAgY2FuIGJlIHVzZWQsDQo+ICAg aW5jbHVkaW5nIG5vbi1JUCB0cmFuc3BvcnRzIChlLmcuLCBbSS1ELmJvcm1hbm4tNmxvLWNvYXAt ODAyLTE1LWllXSkuDQo+DQo+SU1QT1JUQU5UOiBUaGlzIGRvY3VtZW50IGNsYWltcyB0byBiZSBh cHBsaWNhYmxlIHRvIHByb3RvY29scyBvdGhlcg0KPnRoYW4gQ09BUCwgaW4gcGFydGljdWxhciBI VFRQLiBIYXMgdGhpcyBiZWVuIHJldmlld2VkIGJ5IHRoZSBIVFRQDQo+d29ya2luZyBncm91cD8g TWFydGluIFRob21zb24ncyByZXZpZXcgc3VnZ2VzdHMgdGhhdCB0aGlzIGlzIG91dCBvZg0KPnN0 ZXAgd2l0aCBIVFRQIHByYWN0aWNlLg0KPg0KPiAgIElEcyBNVVNUIGJlIGxvbmcgdW5pZm9ybWx5 IHJhbmRvbSBkaXN0cmlidXRlZCBieXRlIHN0cmluZ3Mgc3VjaCB0aGF0DQo+ICAgdGhlIHByb2Jh YmlsaXR5IG9mIGNvbGxpc2lvbnMgaXMgbmVnbGlnaWJsZS4NCj4NCj5JTVBPUlRBTlQ6IEkgZG9u J3QgdW5kZXJzdGFuZCBob3cgdGhpcyBwYXJhZ3JhcGggYW5kIHRoZSBwcmV2aW91cw0KPnBhcmFn cmFwaCBpbnRlcmFjdC4gWW91IHNheSB0aGF0IHRoZSBtYXhpbXVtIGxlbmd0aCBpcyA3IG9jdGV0 cyBpbiB0aGUNCj5wcmV2aW91cyBwYXJhZ3JhcGgsIHdoaWNoIEkgZG9uJ3QgdGhpbmsgcXVhbGlm aWVzIGFzICJsb25nIi4NCj4NCj4gICAgICAgICAgICAgICAgICAgICB8ICAgMSB8IElmLU1hdGNo ICAgICAgICB8IHggfCAgIHwNCj4gICAgICAgICAgICAgICAgICAgICB8ICAgMyB8IFVyaS1Ib3N0 ICAgICAgICB8ICAgfCB4IHwNCj4gICAgICAgICAgICAgICAgICAgICB8ICAgNCB8IEVUYWcgICAg ICAgICAgICB8IHggfCAgIHwNCj5JTVBPUlRBTlQ6IFdoeSBkbyB5b3UgdGhpbmsgdGhhdCBpdCdz IG5vdCBpbXBvcnRhbnQgdG8gaGF2ZSBpbnRlZ3JpdHkNCj5wcm90ZWN0aW9uIGZvciBVcmktSG9z dCBhbmQgVXJpLXBvcnQ/DQo+DQo+ICAgT3V0ZXIgb3B0aW9uIG1lc3NhZ2UgZmllbGRzIChDbGFz cyBVIG9yIEkpIGFyZSB1c2VkIHRvIHN1cHBvcnQgcHJveHkNCj4gICBvcGVyYXRpb25zLg0KPklN UE9SVEFOVDogVGhpcyBzZWVtcyBwcm9ibGVtYXRpYyBiZWNhdXNlIHRoZSBwcm94eSBjYW5ub3Qg dmVyaWZ5IGNsYXNzIEkNCj5maWVsZHMuDQo+DQo+ICAgbGF5ZXIgb25seSwgYW5kIG5vdCB0aGUg TWVzc2FnaW5nIExheWVyIChTZWN0aW9uIDIgb2YgW1JGQzcyNTJdKSwgc28NCj4gICBmaWVsZHMg c3VjaCBhcyBUeXBlIGFuZCBNZXNzYWdlIElEIGFyZSBub3QgcHJvdGVjdGVkIHdpdGggT1NDT1JF Lg0KPg0KPklNUE9SVEFOVDogVGhpcyBzZWVtcyBleHRyZW1lbHkgaGFyZCB0byByZWFzb24gYWJv dXQuIFdoYXQgYXJlIHRoZQ0KPmltcGxpY2F0aW9ucyBvZiB0aGUgcHJveHkgYmVpbmcgYWJsZSB0 byBjaGFuZ2UgdGhlc2U/DQo+DQo+ICAgbyAgcmVxdWVzdF9waXY6IGNvbnRhaW5zIHRoZSB2YWx1 ZSBvZiB0aGUgJ1BhcnRpYWwgSVYnIGluIHRoZSBDT1NFDQo+ICAgICAgb2JqZWN0IG9mIHRoZSBy ZXF1ZXN0IChzZWUgU2VjdGlvbiA1KS4NCj4NCj5JTVBPUlRBTlQ6IEkgdGhpbmsgd2hhdCBJIGFt IGdldHRpbmcgaGVyZSBpcyB0aGF0IHRoZSByZXF1ZXN0X3BpdiBpcw0KPnVzZWQgdG8gdmVyaWZ5 IHRoYXQgdGhlIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1hdGNoLiBIb3dldmVyLCBJIGRvIG5vdA0K PnNlZSB0aGlzIGV4cGxpY2l0bHkgc3RhdGVkIGFueXdoZXJlLCBhbmQgaXQncyBub3QgY2xlYXIg dG8gbWUgaG93IHRoZQ0KPmNsaWVudCBpcyBzdXBwb3NlZCB0byByZWNvdmVyIHRoZSByZXF1ZXN0 X3BpdiBhbmQgdGhlIHRleHQgaXMgcHJldHR5DQo+dW5jbGVhciBoZXJlPyBJcyB0aGUgZXh0ZXJu YWxfYWFkIGNhcnJpZWQgc29tZXdoZXJlIGluIHRoZSBtZXNzYWdlPyBBbQ0KPkkgc3VwcG9zZWQg dG8gcmVjb25zdHJ1Y3QgaXQgZnJvbSB0aGUgbWVzc2FnZSBpZD8NCj4NCj4gICBGb3IgcmVzcG9u c2VzLCB0aGUgbWVzc2FnZSBiaW5kaW5nIGd1YXJhbnRlZXMgdGhhdCBhIHJlc3BvbnNlIGlzIG5v dA0KPiAgIG9sZGVyIHRoYW4gaXRzIHJlcXVlc3QuICBGb3IgcmVzcG9uc2VzIHdpdGhvdXQgT2Jz ZXJ2ZSwgdGhpcyBnaXZlcw0KPg0KPklNUE9SVEFOVDogSSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMg aXMgdHJ1ZS4gV2hhdCBoYXBwZW5zIG9mIHRoZQ0KPmNvdW50ZXJwYXJ0eSBsaWVzPyBXaGF0IGlz IHlvdXIgdGhyZWF0IG1vZGVsPw0KPg0KPiAgIEFuIGV4dGVuc2lvbiBvZiBPU0NPUkUgbWF5IGFs c28gYmUgdXNlZCB0byBwcm90ZWN0IGdyb3VwDQo+ICAgY29tbXVuaWNhdGlvbiBmb3IgQ29BUCBb SS1ELnRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXBdLiAgVGhlIHVzZQ0KPiAgIG9mIE9TQ09S RSBkb2VzIG5vdCBhZmZlY3QgdGhlIFVSSSBzY2hlbWUgYW5kIE9TQ09SRSBjYW4gdGhlcmVmb3Jl IGJlDQo+ICAgdXNlZCB3aXRoIGFueSBVUkkgc2NoZW1lIGRlZmluZWQgZm9yIENvQVAgb3IgSFRU UC4gIFRoZSBhcHBsaWNhdGlvbg0KPiAgIGRlY2lkZXMgdGhlIGNvbmRpdGlvbnMgZm9yIHdoaWNo IE9TQ09SRSBpcyByZXF1aXJlZC4NCj4NCj5UaGlzIGlzIHByZXR0eSBzdXJwcmlzaW5nIHRvIGp1 c3QgZHJvcCBpbiBoZXJlLiBNdWx0aWNhc3QgaGFzIHRvdGFsbHkNCj5kaWZmZXJlbnQNCj5zZWN1 cml0eSBwcm9wZXJ0aWVzIGZyb20gbm9uLW11bHRpY2FzdC4NCj4NCj4NCj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Q09NTUVOVDoNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+DQo+ICAgYnV0IGlzIGFsc28gYWJs ZSB0byBlYXZlc2Ryb3Agb24sIG9yIG1hbmlwdWxhdGUgYW55IHBhcnQgb2YgdGhlDQo+ICAgbWVz c2FnZSBwYXlsb2FkIGFuZCBtZXRhZGF0YSwgaW4gdHJhbnNpdCBiZXR3ZWVuIHRoZSBlbmRwb2lu dHMuICBUaGUNCj4gICBwcm94eSBjYW4gYWxzbyBpbmplY3QsIGRlbGV0ZSwgb3IgcmVvcmRlciBw YWNrZXRzIHNpbmNlIHRoZXkgYXJlIG5vDQo+Tml0OiB5b3Ugd2FudA0KPiJlYXZlc2Ryb3Agb24s IG9yIG1hbmlwdWxhdGUgYW55IHBhcnQgb2YsIHRoZSBtZXNzYWdlIHBheWxvYWQgYW5kDQo+bWV0 YWRhdGEgaW4NCj50cmFuc2l0Ig0KPg0KPkkuZS4sIG1vdmUgdGhlIHNlY29uZCBjb21tYQ0KPg0K PiAgIHRoZSBlbmRwb2ludHMsIGFuZCB0aG9zZSBhcmUgdGhlcmVmb3JlIHByb2Nlc3NlZCBhcyBk ZWZpbmVkIGluDQo+ICAgW1JGQzcyNTJdLiAgQWRkaXRpb25hbGx5LCBzaW5jZSB0aGUgbWVzc2Fn ZSBmb3JtYXRzIGZvciBDb0FQIG92ZXINCj4gICB1bnJlbGlhYmxlIHRyYW5zcG9ydCBbUkZDNzI1 Ml0gYW5kIGZvciBDb0FQIG92ZXIgcmVsaWFibGUgdHJhbnNwb3J0DQo+Tml0OiAiT1NDT1JFIHBy b3RlY3RzIG5laXRoZXIgLi4uLiBub3IuLi4uIg0KPg0KPiAgICAgIFNhbHQuICBMZW5ndGggaXMg ZGV0ZXJtaW5lZCBieSB0aGUgQUVBRCBBbGdvcml0aG0uICBJdHMgdmFsdWUgaXMNCj4+ICAgICAg aW1tdXRhYmxlIG9uY2UgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgZXN0YWJsaXNoZWQuDQo+Tml0 OiB5b3UgbWlnaHQganVzdCBzYXkgYWJvdmUgb3IgYmVsb3cgdGhpcyBsaXN0IHRoYXQgYWxsIHRo ZSB2YWx1ZXMgYXJlDQo+aW1tdXRhYmxlLA0KPg0KPiAgIGRpZmZlcmVudCBvcGVyYXRpb25zLiAg T25lIG1lY2hhbmlzbSBlbmFibGluZyB0aGlzIGlzIHNwZWNpZmllZCBpbg0KPiAgIFtJLUQuaWV0 Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWddLg0KPklzIHRoaXMgYSBzZWN1cml0eSBjb25kaXRpb24/ DQo+DQo+ICAgICAgb2YgW1JGQzcyNTJdLCB3aGVyZSB0aGUgZGVsdGEgaXMgdGhlIGRpZmZlcmVu Y2UgdG8gdGhlIHByZXZpb3VzbHkNCj4gICAgICBpbmNsdWRlZCBjbGFzcyBJIG9wdGlvbi4NCj5J cyB0aGUgZGVsdGEgaGVyZSB0aGUgcHJldmlvdXNseSBpbmNsdWRlZCBDbGFzcyBJIG9wdGlvbiBv ciB0aGUgcHJldmlvdXNseQ0KPmluY2x1ZGVkIGluc3RhbmNlIG9mIHRoZSBzYW1lIG9wdGlvbiwg YXMgaXQgYXBwZWFycyB0byBzYXkgaW4gUyAzLjEuDQo+DQo+ICAgICAgICAgY29tcHJlc3NlZCBD T1NFIG9iamVjdC4gIFRoZSB2YWx1ZXMgbiA9IDYgYW5kIG4gPSA3IGFyZQ0KPiAgICAgICAgIHJl c2VydmVkLg0KPkhvdyBjYW4gUGFydGlhbCBJViBub3QgYmUgcHJlc2VudD8gaXQncyB0aGUgc2Vx dWVuY2UgbnVtYmVyLiBJcyB0aGUNCj5hbnN3ZXIgdGhhdA0KPml0IGlzIHRoZSAwIHZhbHVlPw0K Pg0KPiAgIHJlc3BvbnNlLiAgVGhlIHNlcnZlciB0aGVyZWZvcmUgbmVlZHMgdG8gc3RvcmUgdGhl IGtpZCBhbmQgUGFydGlhbCBJVg0KPiAgIG9mIHRoZSByZXF1ZXN0IHVudGlsIGFsbCByZXNwb25z ZXMgaGF2ZSBiZWVuIHNlbnQuDQo+SXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUga2lk IHdhcyBuZWVkZWQgdG8gbG9vayB1cCB0aGUga2V5LiBXaHkNCj5hcmUga2lkDQo+c3Vic3RpdHV0 aW9uIGF0dGFja3MgYW4gaXNzdWU/DQo+DQo+ICAgVGhlIG1heGltdW0gU2VuZGVyIFNlcXVlbmNl IE51bWJlciBpcyBhbGdvcml0aG0gZGVwZW5kZW50IChzZWUNCj4gICBTZWN0aW9uIDExKSwgYW5k IG5vIGdyZWF0ZXIgdGhhbiAyXjQwIC0gMS4gIElmIHRoZSBTZW5kZXIgU2VxdWVuY2UNCj4gICBO dW1iZXIgZXhjZWVkcyB0aGUgbWF4aW11bSwgdGhlIGVuZHBvaW50IE1VU1QgTk9UIHByb2Nlc3Mg YW55IG1vcmUNCj5JZiB5b3UgdGFrZSBteSBzdWdnZXN0aW9uIGFib3V0IHJlbW92aW5nIHNlbmRl cklEIGZyb20gdGhlIG5vbmNlIHlvdSB3aWxsDQo+YmUNCj5hYmxlIHRvIHJlbGF4IHRoaXMuDQo+ DQo+ICAgQWZ0ZXIgYm9vdCwgYW4gZW5kcG9pbnQgTUFZIHJlamVjdCB0byB1c2UgZXhpc3Rpbmcg c2VjdXJpdHkgY29udGV4dHMNCj4gICBmcm9tIGJlZm9yZSBpdCBib290ZWQgYW5kIE1BWSBlc3Rh Ymxpc2ggYSBuZXcgc2VjdXJpdHkgY29udGV4dCB3aXRoDQo+Tml0OiB0aGlzIGlzIHVuZ3JhbW1h dGljYWwNCj4NCj4gICAgICAgaW5jbHVkZWQgaW4gdGhlIG1lc3NhZ2UuICBJZiB0aGUgQUVBRCBu b25jZSBmcm9tIHRoZSByZXF1ZXN0IHdhcw0KPiAgICAgICB1c2VkLCB0aGUgUGFydGlhbCBJViBN VVNUIE5PVCBiZSBpbmNsdWRlZCBpbiB0aGUgbWVzc2FnZS4NCj5JTVBPUlRBTlQ6IFlvdSBhcmUg bm93IHZpb2xhdGluZyB0aGUgaW52YXJpYW50IG9mIHVzaW5nIHRoZSBzYW1lIG5vbmNlDQo+dHdp Y2UuDQo+VGhhdCdzIGZpbmUgaW4gdGhpcyBjYXNlLCBiZWNhdXNlIHlvdSBoYXZlIHBlci1zZW5k ZXIga2V5cyBidXQgaXQNCj5kZW1vbnN0cmF0ZXMNCj50aGF0IGl0IGlzIHVubmVjZXNzYXJ5IHRv IGVuY29kZSB0aGUgc2VuZGVyX2lkIGluIHRoZSBub25jZSBmaWVsZC4NCj4NCj4gICBTZWN1cml0 eSBsZXZlbCBoZXJlIG1lYW5zIHRoYXQgYW4gYXR0YWNrZXIgY2FuIHJlY292ZXIgb25lIG9mIHRo ZSBtDQo+ICAga2V5cyB3aXRoIGNvbXBsZXhpdHkgMl4oayArIG4pIC8gbS4gIFByb3RlY3Rpb24g YWdhaW5zdCBzdWNoIGF0dGFja3MNCj4gICBjYW4gYmUgcHJvdmlkZWQgYnkgaW5jcmVhc2luZyB0 aGUgc2l6ZSBvZiB0aGUga2V5cyBvciB0aGUgZW50cm9weSBvZg0KPlRoaXMgcGFyYWdyYXBoIGlz IGV4dHJlbWVseSBoYXJkIHRvIGZvbGxvdyBidXQgSSBhbSBub3QgcGVyc3VhZGVkIHRoYXQgaXQN Cj5pcw0KPmNvcnJlY3QuIERvIHlvdSBoYXZlIGEgY2l0YXRpb24gZm9yIHRoZSBjbGFpbSB0aGF0 IHlvdSBjYW4gYWRkIHRoZSBrZXkNCj5lbnRyb3B5DQo+YW5kIHRoZSBub25jZSBlbnRyb3B5IGxp a2UgdGhpcy4NCj4NCj4gICBzdHlsZSBvZiBwYWRkaW5nIG1lYW5zIHRoYXQgYWxsIHZhbHVlcyBu ZWVkIHRvIGJlIHBhZGRlZC4gIFNpbWlsYXINCj4gICBhcmd1bWVudHMgYXBwbHkgdG8gb3RoZXIg bWVzc2FnZSBmaWVsZHMgc3VjaCBhcyByZXNvdXJjZSBuYW1lcy4NCj5UaGUgUEtDUyM3IHBhZGRp bmcgc2NoZW1lIGF0IG1pbmltdW0gaGFzIHBvdGVudGlhbCB0aW1pbmcgY2hhbm5lbHMNCj4NCj4g ICBUaGUgc2VydmVyIHZlcmlmaWVzIHRoYXQgdGhlIFBhcnRpYWwgSVYgaGFzIG5vdCBiZWVuIHJl Y2VpdmVkIGJlZm9yZS4NCj4gICBUaGUgY2xpZW50IHZlcmlmaWVzIHRoYXQgdGhlIHJlc3BvbnNl IGlzIGJvdW5kIHRvIHRoZSByZXF1ZXN0Lg0KPkhvdyBkb2VzIHRoZSBjbGllbnQgdmVyaWZ5IHRo aXMNCj4NCj4gICAgICAgUGFydGlhbCBJViAoaW4gbmV0d29yayBieXRlIG9yZGVyKSB3aXRoIHpl cm9lcyB0byBleGFjdGx5IG5vbmNlDQo+ICAgICAgIGxlbmd0aCAtIDYgYnl0ZXMsDQo+DQo+SU1Q T1JUQU5UOiBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHJlYXNvbiBmb3IgdGhpcyBjb25zdHJ1Y3Rp b24uIFlvdQ0KPmFscmVhZHkgcmVxdWlyZSB0aGF0IHRoZSBrZXkgYmUgZGVyaXZlZCB2aWEgSEtE RiBmcm9tIHRoZSB8bWFzdGVyIGtleXwNCj5hbmQgfHNlbmRlciBJRHwgdGhlcmVmb3JlLCBpdCBp cyBub3QgbmVjZXNzYXJpbHkgdG8gc2VwYXJhdGVseSBlbmNvZGUNCj50aGUgc2VuZGVyIElEIGlu IHRoZSBub25jZS4gVGhpcyB3b3VsZCBvcmRpbmFyaWx5IG5vdCBiZSBhIGxhcmdlDQo+aXNzdWUs IGJ1dCBhcyBpdCByZXF1aXJlcyB2ZXJ5IGV4dHJlbWUgcmVzdHJpY3Rpb25zIG9uIHRoZSBzZW5k ZXIgSUQNCj4oYW5kIGVzc2VudGlhbGx5IHByZWNsdWRlcyByYW5kb20gc2VuZGVyIElEcykgSSBi ZWxpZXZlIGl0IGlzIHdvcnRoDQo+Y29uc2lkZXJpbmcgY2hhbmdpbmcsIGJ1dCBpdCdzIHVsdGlt YXRlbHkgYSBXRyBkZWNpc2lvbiwgaGVuY2Ugbm90DQo+aW4gbXkgZGlzY3Vzcy4NCj4NCj4NCg0K DQo= --_000_D6C710F5A15D5goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <010FA1AEAD53DE4696F8BE68CD41B22C@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5IDggTWFyY2ggMjAxOCBh dCAxNjowNjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkfD tnJhbiBTZWxhbmRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbSI+Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5UaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmciPmRyYWZ0LWll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZyI+ZHJhZnQtaWV0 Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzwvYT4mZ3Q7LA0KIENhcnN0ZW4gQm9ybWFu biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+Y2Fib0B0emkub3JnPC9hPiZndDss IEphaW1lIEppbcOpbmV6ICZsdDs8YSBocmVmPSJtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nv bi5jb20iPmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpjb3JlLWNoYWlyc0BpZXRmLm9yZyI+Y29yZS1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmciPmNvcmUtY2hhaXJz QGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmci PmNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogRXJpYyBSZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIE1hciA4LCAyMDE4IGF0IDY6NTkgQU0sIEfDtnJh biBTZWxhbmRlciA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNl bGFuZGVyQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdvcmFuLnNlbGFuZGVyQGVyaWNz c29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkFub3RoZXIgcmVjdXJyaW5nIGNvbW1lbnQgaXMgdGhl IGltcGFjdCBvZiBhIHByb3h5IGNoYW5naW5nIGNlcnRhaW4gQ29BUDxicj4NCm1lc3NhZ2UgZmll bGRzIGxpa2UgZS5nLiBNZXNzYWdlIElELCBUb2tlbiBvciBVcmktSG9zdC4gU2luY2UgQ29BUCBk ZWZpbmVzPGJyPg0KbGVnaXRpbWF0ZSBwcm94eSBvcGVyYXRpb25zLCB0aGVzZSBtZXNzYWdlIGZp ZWxkcyBjYW5ub3QgYmUgaW50ZWdyaXR5PGJyPg0KcHJvdGVjdGVkIGVuZC10by1lbmQuIEN1cnJl bnQgc2VjdXJpdHkgc29sdXRpb25zIGVpdGhlciBkb2VzIG5vdCBhbGxvdzxicj4NCnByb3h5IG9w ZXJhdGlvbnMgb3IgbGVhdmUgYWxsIG1lc3NhZ2UgZmllbGRzIHVucHJvdGVjdGVkIGluIHRoZSBw cm94eS4gV2U8YnI+DQp3aWxsIHRyeSB0byBtYWtlIHRoaXMgbW9yZSBjbGVhci48YnI+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcXVlc3Rpb24gaXMgd2hhdCB0 aGUgc2VjdXJpdHkgaW1wYWN0IG9mIHRoZXNlIGlzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlllcywgYW5kIHdlIHdpbGwgdHJ5IHRvIGFkZHJlc3MgdGhpcy4gQnV0IGl0 IGlzIGEgZ2VuZXJhbCBwcm9wZXJ0eSBvZiBDb0FQIHdoZW4gcHJveGllcyBhcmUgdXNlZC48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCkEgdGhpcmQgdGhpbmcgaW4gRXJpY+KAmXMgcmV2aWV3IGlzIHRoZSBjb25zdHJ1 Y3Rpb24gb2YgdGhlIG5vbmNlIHdoZXJlIHRoZTxicj4NCklEIGlzIGluY2x1ZGVkLiBUaGUgcmVh c29uIGZvciB0aGlzIGlzIHRvIGhhbmRsZSBlbmRwb2ludHMgc3dpdGNoaW5nIHJvbGVzPGJyPg0K KENvQVAgY2xpZW50ICZsdDstJmd0OyBDb0FQIHNlcnZlcikmbmJzcDsgd2hpY2ggaXMgc3VwcG9y dGVkIGJ5IENvQVAsIGFuZCBpbjxicj4NCnBhcnRpY3VsYXI8YnI+DQpncm91cCBjb21tdW5pY2F0 aW9ucyB3aXRoIG9uZSBzZW5kZXIgYW5kIG11bHRpcGxlIHJlY2lwaWVudHM8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGRvbid0IHNlZSBob3cgdGhhdCBpcyByZWxldmFu dCwgZ2l2ZW4gdGhhdCB5b3UgYWxyZWFkeSBoYXZlIGtleSBzZXBhcmF0aW9uPC9kaXY+DQo8ZGl2 PmZvciB0aGUgc2VuZGVyIGtleSwgd2hhdCBzZXBhcmF0ZSBpbmZvcm1hdGlvbiBpcyB0aGVyZSBp biB0aGUgbm9uY2U/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHNl bmRlciBrZXkgaXMgdXNlZCBib3RoIGluIHRoZSByb2xlIG9mIGNsaWVudCBtYWtpbmcgYSByZXF1 ZXN0ICh3aXRoIG93biBwYXJ0aWFsIElWKSBhbmQgaW4gdGhlIHJvbGUgb2Ygc2VydmVyIHJlc3Bv bmRpbmcgdG8gYSByZXF1ZXN0ICh3aXRoIHRoZSBvdGhlciBlbmRwb2ludOKAmXMgcGFydGlhbCBJ VikuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Hw7ZyYW48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LUVrcjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCi4gV2hpbGUgdGhlPGJyPg0KbGF0dGVy IGlzIHRoZSB0b3BpYyBvZiBhIHNlcGFyYXRlIGRyYWZ0PGJyPg0KKGRyYWZ0LXRpbG9jYS1jb3Jl LW11bHRpY2FzdC08d2JyPm9zY29hcCkgYW5kIHRoZSBwcm9wZXJ0aWVzIGluIHRoYXQgc2V0dGlu ZyBpczxicj4NCm91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0LCB3ZSB3aWxsIGFkZCBtb3JlIGV4 cGxhbmF0aW9uIHRvIHRoZSBzZWN1cml0eTxicj4NCmRlc2lnbiBhbmQgdGhlIHVuaWNhc3Qgc2Vj dXJpdHkgcHJvcGVydGllcyBpbiBnZW5lcmFsIHRvIHRoaXMgZHJhZnQuPGJyPg0KPGJyPg0KPGJy Pg0KTW9yZSBsYXRlci48YnI+DQo8c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4 ODg4OCI+PGJyPg0KR8O2cmFuPGJyPg0KPC9mb250Pjwvc3Bhbj4NCjxkaXYgY2xhc3M9IkhPRW5a YiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxOC0wMy0w OCAwMzo1OCwgJnF1b3Q7RXJpYyBSZXNjb3JsYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVr ckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0Vy aWMgUmVzY29ybGEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9y PGJyPg0KJmd0O2RyYWZ0LWlldGYtY29yZS1vYmplY3QtPHdicj5zZWN1cml0eS0wOTogRGlzY3Vz czxicj4NCiZndDs8YnI+DQomZ3Q7V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KJmd0O2VtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz PGJyPg0KJmd0O2ludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0O1BsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy88d2JyPnN0YXRl bWVudC9kaXNjdXNzLWNyaXRlcmlhLjx3YnI+aHRtbDwvYT48YnI+DQomZ3Q7Zm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJp dHkvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnLzx3YnI+ZG9jL2RyYWZ0LWlldGYtY29yZS1vYmplY3QtPHdicj5zZWN1cml0eS88 L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Oy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0t LS0tLS0tLS0tPGJyPg0KJmd0O0RJU0NVU1M6PGJyPg0KJmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPHdicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0t LS0tPGJyPg0KJmd0Ozxicj4NCiZndDs8YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5kZXZz dmNkZXYubW96YXdzLm5ldC9EMzA3NSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9tb3pwaGFiLWlldGYuPHdicj5kZXZzdmNkZXYubW96YXdzLm5ldC9EMzA3NTwvYT48 YnI+DQomZ3Q7PGJyPg0KJmd0O0RJU0NVU1M8YnI+DQomZ3Q7TXkgb3ZlcmFsbCBjb25jZXJuIHdp dGggdGhpcyBkb2N1bWVudCBpcyB0aGF0IEkgYW0gdW5hYmxlIHRvIGV2YWx1YXRlPGJyPg0KJmd0 O3RoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRoZSBzeXN0ZW0uIEkgaGF2ZSBkZXNjcmliZWQg YSBudW1iZXIgb2Y8YnI+DQomZ3Q7aXNzdWVzIGJlbG93LCBidXQgdGhlIGJhc2ljIHByb2JsZW0g aXMgdGhhdCB0aGlzIHNvcnQgb2YgcGFydGlhbDxicj4NCiZndDtwcm90ZWN0aW9uIGlzIGV4dHJl bWVseSBoYXJkIHRvIHJlYXNvbiBhYm91dCBhbmQgdGhlIHNlY3VyaXR5PGJyPg0KJmd0O2NvbnNp ZGVyYXRpb25zIGRvIG5vdCBkbyBhbiBhZGVxdWF0ZSBqb2Igb2YgZXZhbHVhdGluZyB0aGUgaW1w YWN0IG9mPGJyPg0KJmd0O3Byb3hpZXMgbW9kaWZ5aW5nIHRoZXNlIHZhbHVlcy4gSSBhbSBzaW1p bGFybHkgY29uY2VybmVkIGFib3V0IHRoZTxicj4NCiZndDtIVFRQIG1hcHBpbmcgYW5kIGxpbmsg c2VjdGlvbiB3aGljaCBzZWVtcyBleHRyZW1lbHkgc2tldGNoeSBhbmQgaGFzPGJyPg0KJmd0O2Vz c2VudGlhbGx5IG5vIHNlY3VyaXR5IGFuYWx5c2lzLCBhbmQgeWV0IHBvdGVudGlhbGx5IGhhdmUg YSBsb3Q8YnI+DQomZ3Q7b2YgbGFuZG1pbmVzLjxicj4NCiZndDs8YnI+DQomZ3Q7QXQgbWluaW11 bSwgdGhpcyBkb2N1bWVudCBuZWVkcyB0byB3YWxrIHRocm91Z2ggdGhlIGltcGxpY2F0aW9uczxi cj4NCiZndDtvZiBtb2RpZmljYXRpb25zIGJ5IHRoZSBwcm94eSB0byBldmVyeSB1bnByb3RlY3Rl ZCBmaWVsZCBpbjxicj4NCiZndDt0aGUgcHVyZSBDb0FQIGNvbnRleHQgYXMgd2VsbCBhcyB0aGUg SFRUUCBjb250ZXh0IChpZiB5b3Ugd2FudDxicj4NCiZndDt0byByZXRhaW4gdGhhdCBiaW5kaW5n KS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthcmUgZ2l2ZW4gaW4gQXBwZW5kaXgg QS4mbmJzcDsgT1NDT1JFIGRvZXMgbm90IGRlcGVuZCBvbiB1bmRlcmx5aW5nPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDtsYXllcnMsIGFuZCBjYW4gYmUgdXNlZCBhbnl3aGVyZSB3aGVyZSBDb0FQIG9y IEhUVFAgY2FuIGJlIHVzZWQsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtpbmNsdWRpbmcgbm9uLUlQ IHRyYW5zcG9ydHMgKGUuZy4sIFtJLUQuYm9ybWFubi02bG8tY29hcC04MDItMTUtPHdicj5pZV0p Ljxicj4NCiZndDs8YnI+DQomZ3Q7SU1QT1JUQU5UOiBUaGlzIGRvY3VtZW50IGNsYWltcyB0byBi ZSBhcHBsaWNhYmxlIHRvIHByb3RvY29scyBvdGhlcjxicj4NCiZndDt0aGFuIENPQVAsIGluIHBh cnRpY3VsYXIgSFRUUC4gSGFzIHRoaXMgYmVlbiByZXZpZXdlZCBieSB0aGUgSFRUUDxicj4NCiZn dDt3b3JraW5nIGdyb3VwPyBNYXJ0aW4gVGhvbXNvbidzIHJldmlldyBzdWdnZXN0cyB0aGF0IHRo aXMgaXMgb3V0IG9mPGJyPg0KJmd0O3N0ZXAgd2l0aCBIVFRQIHByYWN0aWNlLjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO0lEcyBNVVNUIGJlIGxvbmcgdW5pZm9ybWx5IHJhbmRvbSBk aXN0cmlidXRlZCBieXRlIHN0cmluZ3Mgc3VjaCB0aGF0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt0 aGUgcHJvYmFiaWxpdHkgb2YgY29sbGlzaW9ucyBpcyBuZWdsaWdpYmxlLjxicj4NCiZndDs8YnI+ DQomZ3Q7SU1QT1JUQU5UOiBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoaXMgcGFyYWdyYXBoIGFu ZCB0aGUgcHJldmlvdXM8YnI+DQomZ3Q7cGFyYWdyYXBoIGludGVyYWN0LiBZb3Ugc2F5IHRoYXQg dGhlIG1heGltdW0gbGVuZ3RoIGlzIDcgb2N0ZXRzIGluIHRoZTxicj4NCiZndDtwcmV2aW91cyBw YXJhZ3JhcGgsIHdoaWNoIEkgZG9uJ3QgdGhpbmsgcXVhbGlmaWVzIGFzICZxdW90O2xvbmcmcXVv dDsuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsx IHwgSWYtTWF0Y2gmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCB4IHwmbmJzcDsgJm5ic3A7 fDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDszIHwgVXJpLUhvc3Qm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDt8IHggfDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDs0IHwgRVRhZyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgeCB8Jm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7SU1Q T1JUQU5UOiBXaHkgZG8geW91IHRoaW5rIHRoYXQgaXQncyBub3QgaW1wb3J0YW50IHRvIGhhdmUg aW50ZWdyaXR5PGJyPg0KJmd0O3Byb3RlY3Rpb24gZm9yIFVyaS1Ib3N0IGFuZCBVcmktcG9ydD88 YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtPdXRlciBvcHRpb24gbWVzc2FnZSBmaWVs ZHMgKENsYXNzIFUgb3IgSSkgYXJlIHVzZWQgdG8gc3VwcG9ydCBwcm94eTxicj4NCiZndDsmbmJz cDsgJm5ic3A7b3BlcmF0aW9ucy48YnI+DQomZ3Q7SU1QT1JUQU5UOiBUaGlzIHNlZW1zIHByb2Js ZW1hdGljIGJlY2F1c2UgdGhlIHByb3h5IGNhbm5vdCB2ZXJpZnkgY2xhc3MgSTxicj4NCiZndDtm aWVsZHMuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7bGF5ZXIgb25seSwgYW5kIG5v dCB0aGUgTWVzc2FnaW5nIExheWVyIChTZWN0aW9uIDIgb2YgW1JGQzcyNTJdKSwgc288YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwO2ZpZWxkcyBzdWNoIGFzIFR5cGUgYW5kIE1lc3NhZ2UgSUQgYXJlIG5v dCBwcm90ZWN0ZWQgd2l0aCBPU0NPUkUuPGJyPg0KJmd0Ozxicj4NCiZndDtJTVBPUlRBTlQ6IFRo aXMgc2VlbXMgZXh0cmVtZWx5IGhhcmQgdG8gcmVhc29uIGFib3V0LiBXaGF0IGFyZSB0aGU8YnI+ DQomZ3Q7aW1wbGljYXRpb25zIG9mIHRoZSBwcm94eSBiZWluZyBhYmxlIHRvIGNoYW5nZSB0aGVz ZT88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtvJm5ic3A7IHJlcXVlc3RfcGl2OiBj b250YWlucyB0aGUgdmFsdWUgb2YgdGhlICdQYXJ0aWFsIElWJyBpbiB0aGUgQ09TRTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBvYmplY3Qgb2YgdGhlIHJlcXVlc3QgKHNlZSBTZWN0aW9u IDUpLjxicj4NCiZndDs8YnI+DQomZ3Q7SU1QT1JUQU5UOiBJIHRoaW5rIHdoYXQgSSBhbSBnZXR0 aW5nIGhlcmUgaXMgdGhhdCB0aGUgcmVxdWVzdF9waXYgaXM8YnI+DQomZ3Q7dXNlZCB0byB2ZXJp ZnkgdGhhdCB0aGUgcmVxdWVzdCBhbmQgcmVzcG9uc2UgbWF0Y2guIEhvd2V2ZXIsIEkgZG8gbm90 PGJyPg0KJmd0O3NlZSB0aGlzIGV4cGxpY2l0bHkgc3RhdGVkIGFueXdoZXJlLCBhbmQgaXQncyBu b3QgY2xlYXIgdG8gbWUgaG93IHRoZTxicj4NCiZndDtjbGllbnQgaXMgc3VwcG9zZWQgdG8gcmVj b3ZlciB0aGUgcmVxdWVzdF9waXYgYW5kIHRoZSB0ZXh0IGlzIHByZXR0eTxicj4NCiZndDt1bmNs ZWFyIGhlcmU/IElzIHRoZSBleHRlcm5hbF9hYWQgY2FycmllZCBzb21ld2hlcmUgaW4gdGhlIG1l c3NhZ2U/IEFtPGJyPg0KJmd0O0kgc3VwcG9zZWQgdG8gcmVjb25zdHJ1Y3QgaXQgZnJvbSB0aGUg bWVzc2FnZSBpZD88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtGb3IgcmVzcG9uc2Vz LCB0aGUgbWVzc2FnZSBiaW5kaW5nIGd1YXJhbnRlZXMgdGhhdCBhIHJlc3BvbnNlIGlzIG5vdDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7b2xkZXIgdGhhbiBpdHMgcmVxdWVzdC4mbmJzcDsgRm9yIHJl c3BvbnNlcyB3aXRob3V0IE9ic2VydmUsIHRoaXMgZ2l2ZXM8YnI+DQomZ3Q7PGJyPg0KJmd0O0lN UE9SVEFOVDogSSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgdHJ1ZS4gV2hhdCBoYXBwZW5zIG9m IHRoZTxicj4NCiZndDtjb3VudGVycGFydHkgbGllcz8gV2hhdCBpcyB5b3VyIHRocmVhdCBtb2Rl bD88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtBbiBleHRlbnNpb24gb2YgT1NDT1JF IG1heSBhbHNvIGJlIHVzZWQgdG8gcHJvdGVjdCBncm91cDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 Y29tbXVuaWNhdGlvbiBmb3IgQ29BUCBbSS1ELnRpbG9jYS1jb3JlLW11bHRpY2FzdC08d2JyPm9z Y29hcF0uJm5ic3A7IFRoZSB1c2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO29mIE9TQ09SRSBkb2Vz IG5vdCBhZmZlY3QgdGhlIFVSSSBzY2hlbWUgYW5kIE9TQ09SRSBjYW4gdGhlcmVmb3JlIGJlPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDt1c2VkIHdpdGggYW55IFVSSSBzY2hlbWUgZGVmaW5lZCBmb3Ig Q29BUCBvciBIVFRQLiZuYnNwOyBUaGUgYXBwbGljYXRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw O2RlY2lkZXMgdGhlIGNvbmRpdGlvbnMgZm9yIHdoaWNoIE9TQ09SRSBpcyByZXF1aXJlZC48YnI+ DQomZ3Q7PGJyPg0KJmd0O1RoaXMgaXMgcHJldHR5IHN1cnByaXNpbmcgdG8ganVzdCBkcm9wIGlu IGhlcmUuIE11bHRpY2FzdCBoYXMgdG90YWxseTxicj4NCiZndDtkaWZmZXJlbnQ8YnI+DQomZ3Q7 c2VjdXJpdHkgcHJvcGVydGllcyBmcm9tIG5vbi1tdWx0aWNhc3QuPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS08YnI+DQomZ3Q7Q09NTUVOVDo8YnI+ DQomZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2J1dCBpcyBhbHNvIGFibGUgdG8gZWF2ZXNkcm9wIG9u LCBvciBtYW5pcHVsYXRlIGFueSBwYXJ0IG9mIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7bWVz c2FnZSBwYXlsb2FkIGFuZCBtZXRhZGF0YSwgaW4gdHJhbnNpdCBiZXR3ZWVuIHRoZSBlbmRwb2lu dHMuJm5ic3A7IFRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7cHJveHkgY2FuIGFsc28gaW5qZWN0 LCBkZWxldGUsIG9yIHJlb3JkZXIgcGFja2V0cyBzaW5jZSB0aGV5IGFyZSBubzxicj4NCiZndDtO aXQ6IHlvdSB3YW50PGJyPg0KJmd0OyZxdW90O2VhdmVzZHJvcCBvbiwgb3IgbWFuaXB1bGF0ZSBh bnkgcGFydCBvZiwgdGhlIG1lc3NhZ2UgcGF5bG9hZCBhbmQ8YnI+DQomZ3Q7bWV0YWRhdGEgaW48 YnI+DQomZ3Q7dHJhbnNpdCZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7SS5lLiwgbW92ZSB0aGUg c2Vjb25kIGNvbW1hPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7dGhlIGVuZHBvaW50 cywgYW5kIHRob3NlIGFyZSB0aGVyZWZvcmUgcHJvY2Vzc2VkIGFzIGRlZmluZWQgaW48YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwO1tSRkM3MjUyXS4mbmJzcDsgQWRkaXRpb25hbGx5LCBzaW5jZSB0aGUg bWVzc2FnZSBmb3JtYXRzIGZvciBDb0FQIG92ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3VucmVs aWFibGUgdHJhbnNwb3J0IFtSRkM3MjUyXSBhbmQgZm9yIENvQVAgb3ZlciByZWxpYWJsZSB0cmFu c3BvcnQ8YnI+DQomZ3Q7Tml0OiAmcXVvdDtPU0NPUkUgcHJvdGVjdHMgbmVpdGhlciAuLi4uIG5v ci4uLi4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFNhbHQu Jm5ic3A7IExlbmd0aCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBBRUFEIEFsZ29yaXRobS4mbmJzcDsg SXRzIHZhbHVlIGlzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbW11dGFibGUg b25jZSB0aGUgc2VjdXJpdHkgY29udGV4dCBpcyBlc3RhYmxpc2hlZC48YnI+DQomZ3Q7Tml0OiB5 b3UgbWlnaHQganVzdCBzYXkgYWJvdmUgb3IgYmVsb3cgdGhpcyBsaXN0IHRoYXQgYWxsIHRoZSB2 YWx1ZXMgYXJlPGJyPg0KJmd0O2ltbXV0YWJsZSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDtkaWZmZXJlbnQgb3BlcmF0aW9ucy4mbmJzcDsgT25lIG1lY2hhbmlzbSBlbmFibGluZyB0 aGlzIGlzIHNwZWNpZmllZCBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7W0ktRC5pZXRmLWNvcmUt ZWNoby1yZXF1ZXN0LTx3YnI+dGFnXS48YnI+DQomZ3Q7SXMgdGhpcyBhIHNlY3VyaXR5IGNvbmRp dGlvbj88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IG9mIFtSRkM3MjUy XSwgd2hlcmUgdGhlIGRlbHRhIGlzIHRoZSBkaWZmZXJlbmNlIHRvIHRoZSBwcmV2aW91c2x5PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGluY2x1ZGVkIGNsYXNzIEkgb3B0aW9uLjxicj4N CiZndDtJcyB0aGUgZGVsdGEgaGVyZSB0aGUgcHJldmlvdXNseSBpbmNsdWRlZCBDbGFzcyBJIG9w dGlvbiBvciB0aGUgcHJldmlvdXNseTxicj4NCiZndDtpbmNsdWRlZCBpbnN0YW5jZSBvZiB0aGUg c2FtZSBvcHRpb24sIGFzIGl0IGFwcGVhcnMgdG8gc2F5IGluIFMgMy4xLjxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbXByZXNzZWQgQ09TRSBv YmplY3QuJm5ic3A7IFRoZSB2YWx1ZXMgbiA9IDYgYW5kIG4gPSA3IGFyZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVzZXJ2ZWQuPGJyPg0KJmd0O0hvdyBjYW4g UGFydGlhbCBJViBub3QgYmUgcHJlc2VudD8gaXQncyB0aGUgc2VxdWVuY2UgbnVtYmVyLiBJcyB0 aGU8YnI+DQomZ3Q7YW5zd2VyIHRoYXQ8YnI+DQomZ3Q7aXQgaXMgdGhlIDAgdmFsdWU/PGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7cmVzcG9uc2UuJm5ic3A7IFRoZSBzZXJ2ZXIgdGhl cmVmb3JlIG5lZWRzIHRvIHN0b3JlIHRoZSBraWQgYW5kIFBhcnRpYWwgSVY8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO29mIHRoZSByZXF1ZXN0IHVudGlsIGFsbCByZXNwb25zZXMgaGF2ZSBiZWVuIHNl bnQuPGJyPg0KJmd0O0l0IHdhcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGtpZCB3YXMgbmVl ZGVkIHRvIGxvb2sgdXAgdGhlIGtleS4gV2h5PGJyPg0KJmd0O2FyZSBraWQ8YnI+DQomZ3Q7c3Vi c3RpdHV0aW9uIGF0dGFja3MgYW4gaXNzdWU/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7VGhlIG1heGltdW0gU2VuZGVyIFNlcXVlbmNlIE51bWJlciBpcyBhbGdvcml0aG0gZGVwZW5k ZW50IChzZWU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1NlY3Rpb24gMTEpLCBhbmQgbm8gZ3JlYXRl ciB0aGFuIDJeNDAgLSAxLiZuYnNwOyBJZiB0aGUgU2VuZGVyIFNlcXVlbmNlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDtOdW1iZXIgZXhjZWVkcyB0aGUgbWF4aW11bSwgdGhlIGVuZHBvaW50IE1VU1Qg Tk9UIHByb2Nlc3MgYW55IG1vcmU8YnI+DQomZ3Q7SWYgeW91IHRha2UgbXkgc3VnZ2VzdGlvbiBh Ym91dCByZW1vdmluZyBzZW5kZXJJRCBmcm9tIHRoZSBub25jZSB5b3Ugd2lsbDxicj4NCiZndDti ZTxicj4NCiZndDthYmxlIHRvIHJlbGF4IHRoaXMuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7QWZ0ZXIgYm9vdCwgYW4gZW5kcG9pbnQgTUFZIHJlamVjdCB0byB1c2UgZXhpc3Rpbmcg c2VjdXJpdHkgY29udGV4dHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2Zyb20gYmVmb3JlIGl0IGJv b3RlZCBhbmQgTUFZIGVzdGFibGlzaCBhIG5ldyBzZWN1cml0eSBjb250ZXh0IHdpdGg8YnI+DQom Z3Q7Tml0OiB0aGlzIGlzIHVuZ3JhbW1hdGljYWw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2luY2x1ZGVkIGluIHRoZSBtZXNzYWdlLiZuYnNwOyBJZiB0aGUg QUVBRCBub25jZSBmcm9tIHRoZSByZXF1ZXN0IHdhczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt1c2VkLCB0aGUgUGFydGlhbCBJViBNVVNUIE5PVCBiZSBpbmNsdWRlZCBpbiB0 aGUgbWVzc2FnZS48YnI+DQomZ3Q7SU1QT1JUQU5UOiBZb3UgYXJlIG5vdyB2aW9sYXRpbmcgdGhl IGludmFyaWFudCBvZiB1c2luZyB0aGUgc2FtZSBub25jZTxicj4NCiZndDt0d2ljZS48YnI+DQom Z3Q7VGhhdCdzIGZpbmUgaW4gdGhpcyBjYXNlLCBiZWNhdXNlIHlvdSBoYXZlIHBlci1zZW5kZXIg a2V5cyBidXQgaXQ8YnI+DQomZ3Q7ZGVtb25zdHJhdGVzPGJyPg0KJmd0O3RoYXQgaXQgaXMgdW5u ZWNlc3NhcnkgdG8gZW5jb2RlIHRoZSBzZW5kZXJfaWQgaW4gdGhlIG5vbmNlIGZpZWxkLjxicj4N CiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1NlY3VyaXR5IGxldmVsIGhlcmUgbWVhbnMgdGhh dCBhbiBhdHRhY2tlciBjYW4gcmVjb3ZlciBvbmUgb2YgdGhlIG08YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwO2tleXMgd2l0aCBjb21wbGV4aXR5IDJeKGsgJiM0MzsgbikgLyBtLiZuYnNwOyBQcm90ZWN0 aW9uIGFnYWluc3Qgc3VjaCBhdHRhY2tzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtjYW4gYmUgcHJv dmlkZWQgYnkgaW5jcmVhc2luZyB0aGUgc2l6ZSBvZiB0aGUga2V5cyBvciB0aGUgZW50cm9weSBv Zjxicj4NCiZndDtUaGlzIHBhcmFncmFwaCBpcyBleHRyZW1lbHkgaGFyZCB0byBmb2xsb3cgYnV0 IEkgYW0gbm90IHBlcnN1YWRlZCB0aGF0IGl0PGJyPg0KJmd0O2lzPGJyPg0KJmd0O2NvcnJlY3Qu IERvIHlvdSBoYXZlIGEgY2l0YXRpb24gZm9yIHRoZSBjbGFpbSB0aGF0IHlvdSBjYW4gYWRkIHRo ZSBrZXk8YnI+DQomZ3Q7ZW50cm9weTxicj4NCiZndDthbmQgdGhlIG5vbmNlIGVudHJvcHkgbGlr ZSB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3N0eWxlIG9mIHBhZGRpbmcg bWVhbnMgdGhhdCBhbGwgdmFsdWVzIG5lZWQgdG8gYmUgcGFkZGVkLiZuYnNwOyBTaW1pbGFyPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDthcmd1bWVudHMgYXBwbHkgdG8gb3RoZXIgbWVzc2FnZSBmaWVs ZHMgc3VjaCBhcyByZXNvdXJjZSBuYW1lcy48YnI+DQomZ3Q7VGhlIFBLQ1MjNyBwYWRkaW5nIHNj aGVtZSBhdCBtaW5pbXVtIGhhcyBwb3RlbnRpYWwgdGltaW5nIGNoYW5uZWxzPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7VGhlIHNlcnZlciB2ZXJpZmllcyB0aGF0IHRoZSBQYXJ0aWFs IElWIGhhcyBub3QgYmVlbiByZWNlaXZlZCBiZWZvcmUuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtU aGUgY2xpZW50IHZlcmlmaWVzIHRoYXQgdGhlIHJlc3BvbnNlIGlzIGJvdW5kIHRvIHRoZSByZXF1 ZXN0Ljxicj4NCiZndDtIb3cgZG9lcyB0aGUgY2xpZW50IHZlcmlmeSB0aGlzPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYXJ0aWFsIElWIChpbiBuZXR3b3Jr IGJ5dGUgb3JkZXIpIHdpdGggemVyb2VzIHRvIGV4YWN0bHkgbm9uY2U8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVuZ3RoIC0gNiBieXRlcyw8YnI+DQomZ3Q7PGJyPg0KJmd0 O0lNUE9SVEFOVDogSSBkb24ndCB1bmRlcnN0YW5kIHRoZSByZWFzb24gZm9yIHRoaXMgY29uc3Ry dWN0aW9uLiBZb3U8YnI+DQomZ3Q7YWxyZWFkeSByZXF1aXJlIHRoYXQgdGhlIGtleSBiZSBkZXJp dmVkIHZpYSBIS0RGIGZyb20gdGhlIHxtYXN0ZXIga2V5fDxicj4NCiZndDthbmQgfHNlbmRlciBJ RHwgdGhlcmVmb3JlLCBpdCBpcyBub3QgbmVjZXNzYXJpbHkgdG8gc2VwYXJhdGVseSBlbmNvZGU8 YnI+DQomZ3Q7dGhlIHNlbmRlciBJRCBpbiB0aGUgbm9uY2UuIFRoaXMgd291bGQgb3JkaW5hcmls eSBub3QgYmUgYSBsYXJnZTxicj4NCiZndDtpc3N1ZSwgYnV0IGFzIGl0IHJlcXVpcmVzIHZlcnkg ZXh0cmVtZSByZXN0cmljdGlvbnMgb24gdGhlIHNlbmRlciBJRDxicj4NCiZndDsoYW5kIGVzc2Vu dGlhbGx5IHByZWNsdWRlcyByYW5kb20gc2VuZGVyIElEcykgSSBiZWxpZXZlIGl0IGlzIHdvcnRo PGJyPg0KJmd0O2NvbnNpZGVyaW5nIGNoYW5naW5nLCBidXQgaXQncyB1bHRpbWF0ZWx5IGEgV0cg ZGVjaXNpb24sIGhlbmNlIG5vdDxicj4NCiZndDtpbiBteSBkaXNjdXNzLjxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D6C710F5A15D5goranselanderericssoncom_-- From nobody Thu Mar 8 07:40:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87036127078 for ; Thu, 8 Mar 2018 07:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 zQUJ1epJhVqq for ; Thu, 8 Mar 2018 07:40:03 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 1789F124207 for ; Thu, 8 Mar 2018 07:39:59 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id n12so7177141qtl.5 for ; Thu, 08 Mar 2018 07:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5MpEdLOXzFlTRXBraZI8BUW9j/DC46/lXIbxlLqnr1A=; b=bqJV4siRljFnSwKv4JUERWtQIdeA2bomnw8o5M5aNk2vKT0Mpn8y0iuH5rqFeDP621 jFcFbN2yaCFSurkGfwsv0E7z4dxRZPdN/p+ISZek0K4dB5AUvTwQ2QPMfT164QLylg/6 qbl5UICtKgR95Z5BukMzx1DruV2G/CCK0HK0SUog+jlGzxEygISUgLUjiPLjPcIk9RE3 mwao7YsnpQpVHZgUDdf0m45gfZ8/Mtv3JO8qIxptjuuQerszPBgGN3F7/0lC37/kABoP x1yb/muyd9canVr8pnhjn7UvZTiY1AFJZ6XNTMoMIVyr1k7V6bCIDmN3OeMhrwCEEIM3 zL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5MpEdLOXzFlTRXBraZI8BUW9j/DC46/lXIbxlLqnr1A=; b=czGG1Mm9qL2RULdc//pWifCumZaPHc68jIjdVJrmo5ztfsduUsbVPO9avf3dnwtJxQ vdxim3OvO6PIU5XBa75+gjtRZcUQA3q37zK8owYnmxqxFFKBYxzhhwwjswxqW0znxJqA pZssxyYxrGqMEd3Rn1TERFlRwt9sTias4VUiBN/cYAtn6o/FTRZzWM5MvkOJVafr7Gfa 7Rv2SzsaFBv5Hn347dNCtG8JnChMQyyYGzBQqfwAGz0di6Wda2QjUhIyCfWo65o+/HzI L7rgrolEB8/GMJo67jlGED5HBRSLCPD32dR2d+wXQLGX5k0SF82Gz6gWL4dLKwvUX3Yr 5myw== X-Gm-Message-State: AElRT7EGbh5g6lU6tO1o+ak3QBgx3CykTxOkeVzt80SrzDyKgrHJfgUP eXsXbk23dmcFuev5+BF16aBrO5sLS8JjgcNnBtdCLg== X-Google-Smtp-Source: AG47ELvPlOeT58kEG755FcEnbRHMo6EJ6hzoKgJVdUehijRAEy0IffGRQxSKB1kF5HnahafY5T7rhaqk4vy8sYfekeQ= X-Received: by 10.200.7.77 with SMTP id k13mr40268806qth.165.1520523598061; Thu, 08 Mar 2018 07:39:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Thu, 8 Mar 2018 07:39:17 -0800 (PST) In-Reply-To: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 8 Mar 2018 07:39:17 -0800 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: The IESG , "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , "core-chairs@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="f403043a8c74ef751d0566e87c6c" Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 15:40:06 -0000 --f403043a8c74ef751d0566e87c6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 8, 2018 at 7:23 AM, G=C3=B6ran Selander wrote: > > > From: Eric Rescorla > Date: Thursday 8 March 2018 at 16:06 > To: G=C3=B6ran Selander > Cc: The IESG , "draft-ietf-core-object-security@ietf.org" = < > draft-ietf-core-object-security@ietf.org>, Carsten Bormann = , > Jaime Jim=C3=A9nez , "core-chairs@ietf.org" < > core-chairs@ietf.org>, "core@ietf.org" > Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-0= 9: > (with DISCUSS and COMMENT) > > > > On Thu, Mar 8, 2018 at 6:59 AM, G=C3=B6ran Selander < > goran.selander@ericsson.com> wrote: > >> Another recurring comment is the impact of a proxy changing certain CoAP >> message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defin= es >> legitimate proxy operations, these message fields cannot be integrity >> protected end-to-end. Current security solutions either does not allow >> proxy operations or leave all message fields unprotected in the proxy. W= e >> will try to make this more clear. >> > > The question is what the security impact of these is. > > > Yes, and we will try to address this. But it is a general property of CoA= P > when proxies are used. > Yes, but the whole point of this design is to protect to some extent against malicious proxies. A third thing in Eric=E2=80=99s review is the construction of the nonce whe= re the >> ID is included. The reason for this is to handle endpoints switching rol= es >> (CoAP client <-> CoAP server) which is supported by CoAP, and in >> particular >> group communications with one sender and multiple recipients > > > I don't see how that is relevant, given that you already have key > separation > for the sender key, what separate information is there in the nonce? > > > The sender key is used both in the role of client making a request (with > own partial IV) and in the role of server responding to a request (with t= he > other endpoint=E2=80=99s partial IV). > This seems extremely hard to analyze. You should just use separate keys. -Ekr > G=C3=B6ran > > > -Ekr > > > >> . While the >> latter is the topic of a separate draft >> (draft-tiloca-core-multicast-oscoap) and the properties in that setting >> is >> out of scope of this draft, we will add more explanation to the security >> design and the unicast security properties in general to this draft. >> >> >> More later. >> >> G=C3=B6ran >> >> >> >> >> On 2018-03-08 03:58, "Eric Rescorla" wrote: >> >> >Eric Rescorla has entered the following ballot position for >> >draft-ietf-core-object-security-09: Discuss >> > >> >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/stat >> ement/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-object-security/ >> > >> > >> > >> >---------------------------------------------------------------------- >> >DISCUSS: >> >---------------------------------------------------------------------- >> > >> >https://mozphab-ietf.devsvcdev.mozaws.net/D3075 >> > >> >DISCUSS >> >My overall concern with this document is that I am unable to evaluate >> >the security properties of the system. I have described a number of >> >issues below, but the basic problem is that this sort of partial >> >protection is extremely hard to reason about and the security >> >considerations do not do an adequate job of evaluating the impact of >> >proxies modifying these values. I am similarly concerned about the >> >HTTP mapping and link section which seems extremely sketchy and has >> >essentially no security analysis, and yet potentially have a lot >> >of landmines. >> > >> >At minimum, this document needs to walk through the implications >> >of modifications by the proxy to every unprotected field in >> >the pure CoAP context as well as the HTTP context (if you want >> >to retain that binding). >> > >> > are given in Appendix A. OSCORE does not depend on underlying >> > layers, and can be used anywhere where CoAP or HTTP can be used, >> > including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie])= . >> > >> >IMPORTANT: This document claims to be applicable to protocols other >> >than COAP, in particular HTTP. Has this been reviewed by the HTTP >> >working group? Martin Thomson's review suggests that this is out of >> >step with HTTP practice. >> > >> > IDs MUST be long uniformly random distributed byte strings such that >> > the probability of collisions is negligible. >> > >> >IMPORTANT: I don't understand how this paragraph and the previous >> >paragraph interact. You say that the maximum length is 7 octets in the >> >previous paragraph, which I don't think qualifies as "long". >> > >> > | 1 | If-Match | x | | >> > | 3 | Uri-Host | | x | >> > | 4 | ETag | x | | >> >IMPORTANT: Why do you think that it's not important to have integrity >> >protection for Uri-Host and Uri-port? >> > >> > Outer option message fields (Class U or I) are used to support proxy >> > operations. >> >IMPORTANT: This seems problematic because the proxy cannot verify class= I >> >fields. >> > >> > layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so >> > fields such as Type and Message ID are not protected with OSCORE. >> > >> >IMPORTANT: This seems extremely hard to reason about. What are the >> >implications of the proxy being able to change these? >> > >> > o request_piv: contains the value of the 'Partial IV' in the COSE >> > object of the request (see Section 5). >> > >> >IMPORTANT: I think what I am getting here is that the request_piv is >> >used to verify that the request and response match. However, I do not >> >see this explicitly stated anywhere, and it's not clear to me how the >> >client is supposed to recover the request_piv and the text is pretty >> >unclear here? Is the external_aad carried somewhere in the message? Am >> >I supposed to reconstruct it from the message id? >> > >> > For responses, the message binding guarantees that a response is not >> > older than its request. For responses without Observe, this gives >> > >> >IMPORTANT: I am not sure that this is true. What happens of the >> >counterparty lies? What is your threat model? >> > >> > An extension of OSCORE may also be used to protect group >> > communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use >> > of OSCORE does not affect the URI scheme and OSCORE can therefore be >> > used with any URI scheme defined for CoAP or HTTP. The application >> > decides the conditions for which OSCORE is required. >> > >> >This is pretty surprising to just drop in here. Multicast has totally >> >different >> >security properties from non-multicast. >> > >> > >> >---------------------------------------------------------------------- >> >COMMENT: >> >---------------------------------------------------------------------- >> > >> > >> > >> > but is also able to eavesdrop on, or manipulate any part of the >> > message payload and metadata, in transit between the endpoints. The >> > proxy can also inject, delete, or reorder packets since they are no >> >Nit: you want >> >"eavesdrop on, or manipulate any part of, the message payload and >> >metadata in >> >transit" >> > >> >I.e., move the second comma >> > >> > the endpoints, and those are therefore processed as defined in >> > [RFC7252]. Additionally, since the message formats for CoAP over >> > unreliable transport [RFC7252] and for CoAP over reliable transport >> >Nit: "OSCORE protects neither .... nor...." >> > >> > Salt. Length is determined by the AEAD Algorithm. Its value is >> >> immutable once the security context is established. >> >Nit: you might just say above or below this list that all the values ar= e >> >immutable, >> > >> > different operations. One mechanism enabling this is specified in >> > [I-D.ietf-core-echo-request-tag]. >> >Is this a security condition? >> > >> > of [RFC7252], where the delta is the difference to the previously >> > included class I option. >> >Is the delta here the previously included Class I option or the >> previously >> >included instance of the same option, as it appears to say in S 3.1. >> > >> > compressed COSE object. The values n =3D 6 and n =3D 7 are >> > reserved. >> >How can Partial IV not be present? it's the sequence number. Is the >> >answer that >> >it is the 0 value? >> > >> > response. The server therefore needs to store the kid and Partial I= V >> > of the request until all responses have been sent. >> >It was my understanding that the kid was needed to look up the key. Why >> >are kid >> >substitution attacks an issue? >> > >> > The maximum Sender Sequence Number is algorithm dependent (see >> > Section 11), and no greater than 2^40 - 1. If the Sender Sequence >> > Number exceeds the maximum, the endpoint MUST NOT process any more >> >If you take my suggestion about removing senderID from the nonce you wi= ll >> >be >> >able to relax this. >> > >> > After boot, an endpoint MAY reject to use existing security contexts >> > from before it booted and MAY establish a new security context with >> >Nit: this is ungrammatical >> > >> > included in the message. If the AEAD nonce from the request was >> > used, the Partial IV MUST NOT be included in the message. >> >IMPORTANT: You are now violating the invariant of using the same nonce >> >twice. >> >That's fine in this case, because you have per-sender keys but it >> >demonstrates >> >that it is unnecessary to encode the sender_id in the nonce field. >> > >> > Security level here means that an attacker can recover one of the m >> > keys with complexity 2^(k + n) / m. Protection against such attacks >> > can be provided by increasing the size of the keys or the entropy of >> >This paragraph is extremely hard to follow but I am not persuaded that = it >> >is >> >correct. Do you have a citation for the claim that you can add the key >> >entropy >> >and the nonce entropy like this. >> > >> > style of padding means that all values need to be padded. Similar >> > arguments apply to other message fields such as resource names. >> >The PKCS#7 padding scheme at minimum has potential timing channels >> > >> > The server verifies that the Partial IV has not been received before= . >> > The client verifies that the response is bound to the request. >> >How does the client verify this >> > >> > Partial IV (in network byte order) with zeroes to exactly nonce >> > length - 6 bytes, >> > >> >IMPORTANT: I don't understand the reason for this construction. You >> >already require that the key be derived via HKDF from the |master key| >> >and |sender ID| therefore, it is not necessarily to separately encode >> >the sender ID in the nonce. This would ordinarily not be a large >> >issue, but as it requires very extreme restrictions on the sender ID >> >(and essentially precludes random sender IDs) I believe it is worth >> >considering changing, but it's ultimately a WG decision, hence not >> >in my discuss. >> > >> > >> >> > --f403043a8c74ef751d0566e87c6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 8, 2018 at 7:23 AM, G=C3=B6ran Selander &= lt;goran.s= elander@ericsson.com> wrote:


From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday 8 March 2018 at 16:0= 6
To: G=C3=B6ran Selander <goran.selander@er= icsson.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf= -core-object-security@ietf.org" <draft-ietf-core-object= -security@ietf.org>, Carsten Bormann <cabo= @tzi.org>, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com>, "core-chairs@ietf.org= " <co= re-chairs@ietf.org>, "core@ietf.org= " <core@ietf.org= >
Subject: Re: Eric Rescorla's Di= scuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT= )



On Thu, Mar 8, 2018 at 6:59 AM, G=C3=B6ran Selan= der <goran.= selander@ericsson.com> wrote:
Another recurring comment is the impact of a proxy changing certain CoAP message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines<= br> legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We will try to make this more clear.

The question is what the security impact of these is.

Yes, and we will try to address this. But it is a general property of = CoAP when proxies are used.

Yes= , but the whole point of this design is to protect to some extent against m= alicious proxies.


A third thing in Eric=E2=80=99s review is the construction of the nonce whe= re the
ID is included. The reason for this is to handle endpoints switching roles<= br> (CoAP client <-> CoAP server)=C2=A0 which is supported by CoAP, and i= n
particular
group communications with one sender and multiple recipients

I don't see how that is relevant, given that you already have key = separation
for the sender key, what separate information is there in the nonce?

The sender key is used both in the role of client making a requ= est (with own partial IV) and in the role of server responding to a request= (with the other endpoint=E2=80=99s partial IV).

This seems extremely hard to analyze. You should just use= separate keys.

-Ekr


G=C3=B6ran


-Ekr

=C2=A0
. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that settin= g is
out of scope of this draft, we will add more explanation to the security design and the unicast security properties in general to this draft.


More later.

G=C3=B6ran




On 2018-03-08 03:58, "Eric Rescorla" <ekr@rtfm.com> wrote:

>Eric Rescorla has entered the following ballot position for
>draft-ietf-core-object-security-09: Discuss
>
>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-object-security/
>
>
>
>-------------------------------------------------------------= ---------
>DISCUSS:
>-------------------------------------------------------------= ---------
>
>https://mozphab-ietf.devsvcdev.mozaws.net/D3= 075
>
>DISCUSS
>My overall concern with this document is that I am unable to evaluate >the security properties of the system. I have described a number of
>issues below, but the basic problem is that this sort of partial
>protection is extremely hard to reason about and the security
>considerations do not do an adequate job of evaluating the impact of >proxies modifying these values. I am similarly concerned about the
>HTTP mapping and link section which seems extremely sketchy and has
>essentially no security analysis, and yet potentially have a lot
>of landmines.
>
>At minimum, this document needs to walk through the implications
>of modifications by the proxy to every unprotected field in
>the pure CoAP context as well as the HTTP context (if you want
>to retain that binding).
>
>=C2=A0 =C2=A0are given in Appendix A.=C2=A0 OSCORE does not depend on u= nderlying
>=C2=A0 =C2=A0layers, and can be used anywhere where CoAP or HTTP can be= used,
>=C2=A0 =C2=A0including non-IP transports (e.g., [I-D.bormann-6lo-coap-8= 02-15-ie]).
>
>IMPORTANT: This document claims to be applicable to protocols other
>than COAP, in particular HTTP. Has this been reviewed by the HTTP
>working group? Martin Thomson's review suggests that this is out of=
>step with HTTP practice.
>
>=C2=A0 =C2=A0IDs MUST be long uniformly random distributed byte strings= such that
>=C2=A0 =C2=A0the probability of collisions is negligible.
>
>IMPORTANT: I don't understand how this paragraph and the previous >paragraph interact. You say that the maximum length is 7 octets in the<= br> >previous paragraph, which I don't think qualifies as "long&quo= t;.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A01 | If-Match=C2=A0 =C2=A0 =C2=A0 =C2=A0 | x |=C2=A0 =C2= =A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A03 | Uri-Host=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|= x |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A04 | ETag=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x |= =C2=A0 =C2=A0|
>IMPORTANT: Why do you think that it's not important to have integri= ty
>protection for Uri-Host and Uri-port?
>
>=C2=A0 =C2=A0Outer option message fields (Class U or I) are used to sup= port proxy
>=C2=A0 =C2=A0operations.
>IMPORTANT: This seems problematic because the proxy cannot verify class= I
>fields.
>
>=C2=A0 =C2=A0layer only, and not the Messaging Layer (Section 2 of [RFC= 7252]), so
>=C2=A0 =C2=A0fields such as Type and Message ID are not protected with = OSCORE.
>
>IMPORTANT: This seems extremely hard to reason about. What are the
>implications of the proxy being able to change these?
>
>=C2=A0 =C2=A0o=C2=A0 request_piv: contains the value of the 'Partia= l IV' in the COSE
>=C2=A0 =C2=A0 =C2=A0 object of the request (see Section 5).
>
>IMPORTANT: I think what I am getting here is that the request_piv is >used to verify that the request and response match. However, I do not >see this explicitly stated anywhere, and it's not clear to me how t= he
>client is supposed to recover the request_piv and the text is pretty >unclear here? Is the external_aad carried somewhere in the message? Am<= br> >I supposed to reconstruct it from the message id?
>
>=C2=A0 =C2=A0For responses, the message binding guarantees that a respo= nse is not
>=C2=A0 =C2=A0older than its request.=C2=A0 For responses without Observ= e, this gives
>
>IMPORTANT: I am not sure that this is true. What happens of the
>counterparty lies? What is your threat model?
>
>=C2=A0 =C2=A0An extension of OSCORE may also be used to protect group >=C2=A0 =C2=A0communication for CoAP [I-D.tiloca-core-multicast-osc= oap].=C2=A0 The use
>=C2=A0 =C2=A0of OSCORE does not affect the URI scheme and OSCORE can th= erefore be
>=C2=A0 =C2=A0used with any URI scheme defined for CoAP or HTTP.=C2=A0 T= he application
>=C2=A0 =C2=A0decides the conditions for which OSCORE is required.
>
>This is pretty surprising to just drop in here. Multicast has totally >different
>security properties from non-multicast.
>
>
>-------------------------------------------------------------= ---------
>COMMENT:
>-------------------------------------------------------------= ---------
>
>
>
>=C2=A0 =C2=A0but is also able to eavesdrop on, or manipulate any part o= f the
>=C2=A0 =C2=A0message payload and metadata, in transit between the endpo= ints.=C2=A0 The
>=C2=A0 =C2=A0proxy can also inject, delete, or reorder packets since th= ey are no
>Nit: you want
>"eavesdrop on, or manipulate any part of, the message payload and<= br> >metadata in
>transit"
>
>I.e., move the second comma
>
>=C2=A0 =C2=A0the endpoints, and those are therefore processed as define= d in
>=C2=A0 =C2=A0[RFC7252].=C2=A0 Additionally, since the message formats f= or CoAP over
>=C2=A0 =C2=A0unreliable transport [RFC7252] and for CoAP over reliable = transport
>Nit: "OSCORE protects neither .... nor...."
>
>=C2=A0 =C2=A0 =C2=A0 Salt.=C2=A0 Length is determined by the AEAD Algor= ithm.=C2=A0 Its value is
>>=C2=A0 =C2=A0 =C2=A0 immutable once the security context is establi= shed.
>Nit: you might just say above or below this list that all the values ar= e
>immutable,
>
>=C2=A0 =C2=A0different operations.=C2=A0 One mechanism enabling this is= specified in
>=C2=A0 =C2=A0[I-D.ietf-core-echo-request-tag].
>Is this a security condition?
>
>=C2=A0 =C2=A0 =C2=A0 of [RFC7252], where the delta is the difference to= the previously
>=C2=A0 =C2=A0 =C2=A0 included class I option.
>Is the delta here the previously included Class I option or the previou= sly
>included instance of the same option, as it appears to say in S 3.1. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compressed COSE object.=C2=A0 The val= ues n =3D 6 and n =3D 7 are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reserved.
>How can Partial IV not be present? it's the sequence number. Is the=
>answer that
>it is the 0 value?
>
>=C2=A0 =C2=A0response.=C2=A0 The server therefore needs to store the ki= d and Partial IV
>=C2=A0 =C2=A0of the request until all responses have been sent.
>It was my understanding that the kid was needed to look up the key. Why=
>are kid
>substitution attacks an issue?
>
>=C2=A0 =C2=A0The maximum Sender Sequence Number is algorithm dependent = (see
>=C2=A0 =C2=A0Section 11), and no greater than 2^40 - 1.=C2=A0 If the Se= nder Sequence
>=C2=A0 =C2=A0Number exceeds the maximum, the endpoint MUST NOT process = any more
>If you take my suggestion about removing senderID from the nonce you wi= ll
>be
>able to relax this.
>
>=C2=A0 =C2=A0After boot, an endpoint MAY reject to use existing securit= y contexts
>=C2=A0 =C2=A0from before it booted and MAY establish a new security con= text with
>Nit: this is ungrammatical
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0included in the message.=C2=A0 If the AEAD n= once from the request was
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used, the Partial IV MUST NOT be included in= the message.
>IMPORTANT: You are now violating the invariant of using the same nonce<= br> >twice.
>That's fine in this case, because you have per-sender keys but it >demonstrates
>that it is unnecessary to encode the sender_id in the nonce field.
>
>=C2=A0 =C2=A0Security level here means that an attacker can recover one= of the m
>=C2=A0 =C2=A0keys with complexity 2^(k + n) / m.=C2=A0 Protection again= st such attacks
>=C2=A0 =C2=A0can be provided by increasing the size of the keys or the = entropy of
>This paragraph is extremely hard to follow but I am not persuaded that = it
>is
>correct. Do you have a citation for the claim that you can add the key<= br> >entropy
>and the nonce entropy like this.
>
>=C2=A0 =C2=A0style of padding means that all values need to be padded.= =C2=A0 Similar
>=C2=A0 =C2=A0arguments apply to other message fields such as resource n= ames.
>The PKCS#7 padding scheme at minimum has potential timing channels
>
>=C2=A0 =C2=A0The server verifies that the Partial IV has not been recei= ved before.
>=C2=A0 =C2=A0The client verifies that the response is bound to the requ= est.
>How does the client verify this
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partial IV (in network byte order) with zero= es to exactly nonce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0length - 6 bytes,
>
>IMPORTANT: I don't understand the reason for this construction. You=
>already require that the key be derived via HKDF from the |master key|<= br> >and |sender ID| therefore, it is not necessarily to separately encode >the sender ID in the nonce. This would ordinarily not be a large
>issue, but as it requires very extreme restrictions on the sender ID >(and essentially precludes random sender IDs) I believe it is worth
>considering changing, but it's ultimately a WG decision, hence not<= br> >in my discuss.
>
>

--f403043a8c74ef751d0566e87c6c-- From nobody Thu Mar 8 08:25:25 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082F5127369 for ; Thu, 8 Mar 2018 08:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 uqTjiyE-PlLS for ; Thu, 8 Mar 2018 08:25:20 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D9BA9127333 for ; Thu, 8 Mar 2018 08:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520526313; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Qxw9Dy3r0FMfZvGAo7kO6M1s1xtM141JiLbcHVEWp8M=; b=czMNmPPh/MD7mQoYJwJGjcdWn2cz5YpCkuJ0BAUoklBjkYO2irelGl0ScZ6CiQHb MRwcMvxonC6pjkAWUjm+ITE+QyH2r35jS3ADmLSQzJyyNRg7M860bgVCo4FZUP/P ybkduUCEnphj5PS08oSjyjDhZis8135TbWCYiG2gAuU=; X-AuditID: c1b4fb25-44ba69c000002d5f-82-5aa163e9d38a Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.98.11615.9E361AA5; Thu, 8 Mar 2018 17:25:13 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.88]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 17:24:23 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eric Rescorla CC: The IESG , "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) Thread-Index: AQHTtolfO1SWXHzYR0WCPxFNrQ+jVKPGbw+A///xRQCAABVjAP//866AgAAdYIA= Date: Thu, 8 Mar 2018 16:24:23 +0000 Message-ID: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: multipart/alternative; boundary="_000_D6C71CA5A15F7goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyM2K7se7L5IVRBmd+yVkcmXKX1WLbxgts Fvverme2mPbvDIvFitfn2C1m/JnI7MDmsWTJTyaPyY/bmD2mLcoMYI7isklJzcksSy3St0vg ylh+/gpzwef3TBXz9k9nbGBc8oypi5GTQ0LAROLK7e0sXYxcHEIChxklOn4/ZoZwFjFKbOg9 wA5SxSbgIvGg4RFYh4iAgsSvPyfAOpgFVjFJ/Dywjg0kISyQIdH+5hUjRFGmxNO961khbD+J s80NYDUsAioSW1Y+B6vhFbCQaG/fyQqxbSeTxIfb38E2cAoESixf2gvWzCggJvH91BqwOLOA uMStJ/Oh7haQWLLnPDOELSrx8vE/sHpRAT2JvT3tQMs4gOJKEj0bpCBaYyU+nT8BtVdQ4uTM JywTGEVnIZk6C0nZLCRls4AmMQtoSqzfpQ9RoigxpfshO4StIdE6Zy6UbS2x9sFLRmQ1Cxg5 VjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERu/BLb9VdzBefuN4iFGAg1GJh/dF1MIoIdbE suLK3EOMEhzMSiK8AfpAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxzhNujhATSE0tSs1NTC1KL YLJMHJxSDYzcZyZ27K9hvvI+ruWgxvxD4e/ED5y+3Ns/7QCrV2Yxp/Xrza9+BZn9qY/fs3Q9 /6xZ4px3X92U2XBU1OlRbbTlr0cbZP9ssZ7n2DbXwUVn1YlyY3Uhi9MvQw0FlQVzml81rHHn 4xD6fedlhPmMQoH/PVO3PNibWe91Z/2ry/f7Rf6XLll5o2KPEktxRqKhFnNRcSIAAboOP9oC AAA= Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 16:25:24 -0000 --_000_D6C71CA5A15F7goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29t Pj4NCkRhdGU6IFRodXJzZGF5IDggTWFyY2ggMjAxOCBhdCAxNjozOQ0KVG86IEfDtnJhbiBTZWxh bmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb20+Pg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGll dGYub3JnPj4sICJkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPiIgPGRyYWZ0LWlldGYt Y29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHlAaWV0Zi5vcmc+PiwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFp bHRvOmNhYm9AdHppLm9yZz4+LCBKYWltZSBKaW3DqW5leiA8amFpbWUuamltZW5lekBlcmljc3Nv bi5jb208bWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPj4sICJjb3JlLWNoYWlyc0Bp ZXRmLm9yZzxtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmc+IiA8Y29yZS1jaGFpcnNAaWV0Zi5v cmc8bWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnPj4sICJjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPiIgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHktMDk6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCg0KDQpPbiBUaHUs IE1hciA4LCAyMDE4IGF0IDc6MjMgQU0sIEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+PiB3cm90ZToN Cg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNv bT4+DQpEYXRlOiBUaHVyc2RheSA4IE1hcmNoIDIwMTggYXQgMTY6MDYNClRvOiBHw7ZyYW4gU2Vs YW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPj4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0Bp ZXRmLm9yZz4+LCAiZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZz4iIDxkcmFmdC1pZXRm LWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2Jq ZWN0LXNlY3VyaXR5QGlldGYub3JnPj4sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1h aWx0bzpjYWJvQHR6aS5vcmc+PiwgSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nz b24uY29tPG1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbT4+LCAiY29yZS1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnPiIgPGNvcmUtY2hhaXJzQGlldGYu b3JnPG1haWx0bzpjb3JlLWNoYWlyc0BpZXRmLm9yZz4+LCAiY29yZUBpZXRmLm9yZzxtYWlsdG86 Y29yZUBpZXRmLm9yZz4iIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNvcmUtb2Jq ZWN0LXNlY3VyaXR5LTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQoNCg0KT24gVGh1 LCBNYXIgOCwgMjAxOCBhdCA2OjU5IEFNLCBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVy QGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQpBbm90aGVyIHJlY3VycmluZyBjb21tZW50IGlzIHRoZSBpbXBhY3Qgb2YgYSBwcm94eSBjaGFu Z2luZyBjZXJ0YWluIENvQVANCm1lc3NhZ2UgZmllbGRzIGxpa2UgZS5nLiBNZXNzYWdlIElELCBU b2tlbiBvciBVcmktSG9zdC4gU2luY2UgQ29BUCBkZWZpbmVzDQpsZWdpdGltYXRlIHByb3h5IG9w ZXJhdGlvbnMsIHRoZXNlIG1lc3NhZ2UgZmllbGRzIGNhbm5vdCBiZSBpbnRlZ3JpdHkNCnByb3Rl Y3RlZCBlbmQtdG8tZW5kLiBDdXJyZW50IHNlY3VyaXR5IHNvbHV0aW9ucyBlaXRoZXIgZG9lcyBu b3QgYWxsb3cNCnByb3h5IG9wZXJhdGlvbnMgb3IgbGVhdmUgYWxsIG1lc3NhZ2UgZmllbGRzIHVu cHJvdGVjdGVkIGluIHRoZSBwcm94eS4gV2UNCndpbGwgdHJ5IHRvIG1ha2UgdGhpcyBtb3JlIGNs ZWFyLg0KDQpUaGUgcXVlc3Rpb24gaXMgd2hhdCB0aGUgc2VjdXJpdHkgaW1wYWN0IG9mIHRoZXNl IGlzLg0KDQpZZXMsIGFuZCB3ZSB3aWxsIHRyeSB0byBhZGRyZXNzIHRoaXMuIEJ1dCBpdCBpcyBh IGdlbmVyYWwgcHJvcGVydHkgb2YgQ29BUCB3aGVuIHByb3hpZXMgYXJlIHVzZWQuDQoNClllcywg YnV0IHRoZSB3aG9sZSBwb2ludCBvZiB0aGlzIGRlc2lnbiBpcyB0byBwcm90ZWN0IHRvIHNvbWUg ZXh0ZW50IGFnYWluc3QgbWFsaWNpb3VzIHByb3hpZXMuDQoNClllcywgYnV0IG5vdCBhZ2FpbnN0 IHByb3h5IG9wZXJhdGlvbnMgd2hpY2ggYXJlIGRlZmluZWQgYXMgbGVnaXRpbWF0ZSBieSBDb0FQ IGFuZC9vciB3aGVyZSB0aGVyZSBhcmUgb3RoZXIgbWVhbnMgdG8gdmVyaWZ5IHRoZSBvcGVyYXRp b24uDQoNCg0KDQpBIHRoaXJkIHRoaW5nIGluIEVyaWPigJlzIHJldmlldyBpcyB0aGUgY29uc3Ry dWN0aW9uIG9mIHRoZSBub25jZSB3aGVyZSB0aGUNCklEIGlzIGluY2x1ZGVkLiBUaGUgcmVhc29u IGZvciB0aGlzIGlzIHRvIGhhbmRsZSBlbmRwb2ludHMgc3dpdGNoaW5nIHJvbGVzDQooQ29BUCBj bGllbnQgPC0+IENvQVAgc2VydmVyKSAgd2hpY2ggaXMgc3VwcG9ydGVkIGJ5IENvQVAsIGFuZCBp bg0KcGFydGljdWxhcg0KZ3JvdXAgY29tbXVuaWNhdGlvbnMgd2l0aCBvbmUgc2VuZGVyIGFuZCBt dWx0aXBsZSByZWNpcGllbnRzDQoNCkkgZG9uJ3Qgc2VlIGhvdyB0aGF0IGlzIHJlbGV2YW50LCBn aXZlbiB0aGF0IHlvdSBhbHJlYWR5IGhhdmUga2V5IHNlcGFyYXRpb24NCmZvciB0aGUgc2VuZGVy IGtleSwgd2hhdCBzZXBhcmF0ZSBpbmZvcm1hdGlvbiBpcyB0aGVyZSBpbiB0aGUgbm9uY2U/DQoN ClRoZSBzZW5kZXIga2V5IGlzIHVzZWQgYm90aCBpbiB0aGUgcm9sZSBvZiBjbGllbnQgbWFraW5n IGEgcmVxdWVzdCAod2l0aCBvd24gcGFydGlhbCBJVikgYW5kIGluIHRoZSByb2xlIG9mIHNlcnZl ciByZXNwb25kaW5nIHRvIGEgcmVxdWVzdCAod2l0aCB0aGUgb3RoZXIgZW5kcG9pbnTigJlzIHBh cnRpYWwgSVYpLg0KDQpUaGlzIHNlZW1zIGV4dHJlbWVseSBoYXJkIHRvIGFuYWx5emUuIFlvdSBz aG91bGQganVzdCB1c2Ugc2VwYXJhdGUga2V5cy4NCg0KVGhhdCBpcyBhbiBhbHRlcm5hdGl2ZSBz b2x1dGlvbiB3aGljaCBpcyBsZXNzIG9wdGltaXNlZCBlLmcuIGluIHRlcm1zIG9mIHNpemUgb2Yg Z3JvdXAgY29tbXVuaWNhdGlvbiBzZWN1cml0eSBjb250ZXh0LiBMZXQgdXMgY29tZSBiYWNrIG9u IHRoYXQuDQoNCkfDtnJhbg0KDQoNCi1Fa3INCg0KDQpHw7ZyYW4NCg0KDQotRWtyDQoNCg0KLiBX aGlsZSB0aGUNCmxhdHRlciBpcyB0aGUgdG9waWMgb2YgYSBzZXBhcmF0ZSBkcmFmdA0KKGRyYWZ0 LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXApIGFuZCB0aGUgcHJvcGVydGllcyBpbiB0aGF0 IHNldHRpbmcgaXMNCm91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0LCB3ZSB3aWxsIGFkZCBtb3Jl IGV4cGxhbmF0aW9uIHRvIHRoZSBzZWN1cml0eQ0KZGVzaWduIGFuZCB0aGUgdW5pY2FzdCBzZWN1 cml0eSBwcm9wZXJ0aWVzIGluIGdlbmVyYWwgdG8gdGhpcyBkcmFmdC4NCg0KDQpNb3JlIGxhdGVy Lg0KDQpHw7ZyYW4NCg0KDQoNCg0KT24gMjAxOC0wMy0wOCAwMzo1OCwgIkVyaWMgUmVzY29ybGEi IDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQo+RXJpYyBSZXNj b3JsYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj5kcmFm dC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTA5OiBEaXNjdXNzDQo+DQo+V2hlbiByZXNwb25k aW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxs DQo+ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVs IGZyZWUgdG8gY3V0IHRoaXMNCj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4N Cj4NCj5QbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4NCj4NCj5UaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0 eS8NCj4NCj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+RElTQ1VTUzoNCj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ DQo+aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDMwNzUNCj4NCj5E SVNDVVNTDQo+TXkgb3ZlcmFsbCBjb25jZXJuIHdpdGggdGhpcyBkb2N1bWVudCBpcyB0aGF0IEkg YW0gdW5hYmxlIHRvIGV2YWx1YXRlDQo+dGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhlIHN5 c3RlbS4gSSBoYXZlIGRlc2NyaWJlZCBhIG51bWJlciBvZg0KPmlzc3VlcyBiZWxvdywgYnV0IHRo ZSBiYXNpYyBwcm9ibGVtIGlzIHRoYXQgdGhpcyBzb3J0IG9mIHBhcnRpYWwNCj5wcm90ZWN0aW9u IGlzIGV4dHJlbWVseSBoYXJkIHRvIHJlYXNvbiBhYm91dCBhbmQgdGhlIHNlY3VyaXR5DQo+Y29u c2lkZXJhdGlvbnMgZG8gbm90IGRvIGFuIGFkZXF1YXRlIGpvYiBvZiBldmFsdWF0aW5nIHRoZSBp bXBhY3Qgb2YNCj5wcm94aWVzIG1vZGlmeWluZyB0aGVzZSB2YWx1ZXMuIEkgYW0gc2ltaWxhcmx5 IGNvbmNlcm5lZCBhYm91dCB0aGUNCj5IVFRQIG1hcHBpbmcgYW5kIGxpbmsgc2VjdGlvbiB3aGlj aCBzZWVtcyBleHRyZW1lbHkgc2tldGNoeSBhbmQgaGFzDQo+ZXNzZW50aWFsbHkgbm8gc2VjdXJp dHkgYW5hbHlzaXMsIGFuZCB5ZXQgcG90ZW50aWFsbHkgaGF2ZSBhIGxvdA0KPm9mIGxhbmRtaW5l cy4NCj4NCj5BdCBtaW5pbXVtLCB0aGlzIGRvY3VtZW50IG5lZWRzIHRvIHdhbGsgdGhyb3VnaCB0 aGUgaW1wbGljYXRpb25zDQo+b2YgbW9kaWZpY2F0aW9ucyBieSB0aGUgcHJveHkgdG8gZXZlcnkg dW5wcm90ZWN0ZWQgZmllbGQgaW4NCj50aGUgcHVyZSBDb0FQIGNvbnRleHQgYXMgd2VsbCBhcyB0 aGUgSFRUUCBjb250ZXh0IChpZiB5b3Ugd2FudA0KPnRvIHJldGFpbiB0aGF0IGJpbmRpbmcpLg0K Pg0KPiAgIGFyZSBnaXZlbiBpbiBBcHBlbmRpeCBBLiAgT1NDT1JFIGRvZXMgbm90IGRlcGVuZCBv biB1bmRlcmx5aW5nDQo+ICAgbGF5ZXJzLCBhbmQgY2FuIGJlIHVzZWQgYW55d2hlcmUgd2hlcmUg Q29BUCBvciBIVFRQIGNhbiBiZSB1c2VkLA0KPiAgIGluY2x1ZGluZyBub24tSVAgdHJhbnNwb3J0 cyAoZS5nLiwgW0ktRC5ib3JtYW5uLTZsby1jb2FwLTgwMi0xNS1pZV0pLg0KPg0KPklNUE9SVEFO VDogVGhpcyBkb2N1bWVudCBjbGFpbXMgdG8gYmUgYXBwbGljYWJsZSB0byBwcm90b2NvbHMgb3Ro ZXINCj50aGFuIENPQVAsIGluIHBhcnRpY3VsYXIgSFRUUC4gSGFzIHRoaXMgYmVlbiByZXZpZXdl ZCBieSB0aGUgSFRUUA0KPndvcmtpbmcgZ3JvdXA/IE1hcnRpbiBUaG9tc29uJ3MgcmV2aWV3IHN1 Z2dlc3RzIHRoYXQgdGhpcyBpcyBvdXQgb2YNCj5zdGVwIHdpdGggSFRUUCBwcmFjdGljZS4NCj4N Cj4gICBJRHMgTVVTVCBiZSBsb25nIHVuaWZvcm1seSByYW5kb20gZGlzdHJpYnV0ZWQgYnl0ZSBz dHJpbmdzIHN1Y2ggdGhhdA0KPiAgIHRoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb25zIGlzIG5l Z2xpZ2libGUuDQo+DQo+SU1QT1JUQU5UOiBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoaXMgcGFy YWdyYXBoIGFuZCB0aGUgcHJldmlvdXMNCj5wYXJhZ3JhcGggaW50ZXJhY3QuIFlvdSBzYXkgdGhh dCB0aGUgbWF4aW11bSBsZW5ndGggaXMgNyBvY3RldHMgaW4gdGhlDQo+cHJldmlvdXMgcGFyYWdy YXBoLCB3aGljaCBJIGRvbid0IHRoaW5rIHF1YWxpZmllcyBhcyAibG9uZyIuDQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgfCAgIDEgfCBJZi1NYXRjaCAgICAgICAgfCB4IHwgICB8DQo+ICAgICAg ICAgICAgICAgICAgICAgfCAgIDMgfCBVcmktSG9zdCAgICAgICAgfCAgIHwgeCB8DQo+ICAgICAg ICAgICAgICAgICAgICAgfCAgIDQgfCBFVGFnICAgICAgICAgICAgfCB4IHwgICB8DQo+SU1QT1JU QU5UOiBXaHkgZG8geW91IHRoaW5rIHRoYXQgaXQncyBub3QgaW1wb3J0YW50IHRvIGhhdmUgaW50 ZWdyaXR5DQo+cHJvdGVjdGlvbiBmb3IgVXJpLUhvc3QgYW5kIFVyaS1wb3J0Pw0KPg0KPiAgIE91 dGVyIG9wdGlvbiBtZXNzYWdlIGZpZWxkcyAoQ2xhc3MgVSBvciBJKSBhcmUgdXNlZCB0byBzdXBw b3J0IHByb3h5DQo+ICAgb3BlcmF0aW9ucy4NCj5JTVBPUlRBTlQ6IFRoaXMgc2VlbXMgcHJvYmxl bWF0aWMgYmVjYXVzZSB0aGUgcHJveHkgY2Fubm90IHZlcmlmeSBjbGFzcyBJDQo+ZmllbGRzLg0K Pg0KPiAgIGxheWVyIG9ubHksIGFuZCBub3QgdGhlIE1lc3NhZ2luZyBMYXllciAoU2VjdGlvbiAy IG9mIFtSRkM3MjUyXSksIHNvDQo+ICAgZmllbGRzIHN1Y2ggYXMgVHlwZSBhbmQgTWVzc2FnZSBJ RCBhcmUgbm90IHByb3RlY3RlZCB3aXRoIE9TQ09SRS4NCj4NCj5JTVBPUlRBTlQ6IFRoaXMgc2Vl bXMgZXh0cmVtZWx5IGhhcmQgdG8gcmVhc29uIGFib3V0LiBXaGF0IGFyZSB0aGUNCj5pbXBsaWNh dGlvbnMgb2YgdGhlIHByb3h5IGJlaW5nIGFibGUgdG8gY2hhbmdlIHRoZXNlPw0KPg0KPiAgIG8g IHJlcXVlc3RfcGl2OiBjb250YWlucyB0aGUgdmFsdWUgb2YgdGhlICdQYXJ0aWFsIElWJyBpbiB0 aGUgQ09TRQ0KPiAgICAgIG9iamVjdCBvZiB0aGUgcmVxdWVzdCAoc2VlIFNlY3Rpb24gNSkuDQo+ DQo+SU1QT1JUQU5UOiBJIHRoaW5rIHdoYXQgSSBhbSBnZXR0aW5nIGhlcmUgaXMgdGhhdCB0aGUg cmVxdWVzdF9waXYgaXMNCj51c2VkIHRvIHZlcmlmeSB0aGF0IHRoZSByZXF1ZXN0IGFuZCByZXNw b25zZSBtYXRjaC4gSG93ZXZlciwgSSBkbyBub3QNCj5zZWUgdGhpcyBleHBsaWNpdGx5IHN0YXRl ZCBhbnl3aGVyZSwgYW5kIGl0J3Mgbm90IGNsZWFyIHRvIG1lIGhvdyB0aGUNCj5jbGllbnQgaXMg c3VwcG9zZWQgdG8gcmVjb3ZlciB0aGUgcmVxdWVzdF9waXYgYW5kIHRoZSB0ZXh0IGlzIHByZXR0 eQ0KPnVuY2xlYXIgaGVyZT8gSXMgdGhlIGV4dGVybmFsX2FhZCBjYXJyaWVkIHNvbWV3aGVyZSBp biB0aGUgbWVzc2FnZT8gQW0NCj5JIHN1cHBvc2VkIHRvIHJlY29uc3RydWN0IGl0IGZyb20gdGhl IG1lc3NhZ2UgaWQ/DQo+DQo+ICAgRm9yIHJlc3BvbnNlcywgdGhlIG1lc3NhZ2UgYmluZGluZyBn dWFyYW50ZWVzIHRoYXQgYSByZXNwb25zZSBpcyBub3QNCj4gICBvbGRlciB0aGFuIGl0cyByZXF1 ZXN0LiAgRm9yIHJlc3BvbnNlcyB3aXRob3V0IE9ic2VydmUsIHRoaXMgZ2l2ZXMNCj4NCj5JTVBP UlRBTlQ6IEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIGlzIHRydWUuIFdoYXQgaGFwcGVucyBvZiB0 aGUNCj5jb3VudGVycGFydHkgbGllcz8gV2hhdCBpcyB5b3VyIHRocmVhdCBtb2RlbD8NCj4NCj4g ICBBbiBleHRlbnNpb24gb2YgT1NDT1JFIG1heSBhbHNvIGJlIHVzZWQgdG8gcHJvdGVjdCBncm91 cA0KPiAgIGNvbW11bmljYXRpb24gZm9yIENvQVAgW0ktRC50aWxvY2EtY29yZS1tdWx0aWNhc3Qt b3Njb2FwXS4gIFRoZSB1c2UNCj4gICBvZiBPU0NPUkUgZG9lcyBub3QgYWZmZWN0IHRoZSBVUkkg c2NoZW1lIGFuZCBPU0NPUkUgY2FuIHRoZXJlZm9yZSBiZQ0KPiAgIHVzZWQgd2l0aCBhbnkgVVJJ IHNjaGVtZSBkZWZpbmVkIGZvciBDb0FQIG9yIEhUVFAuICBUaGUgYXBwbGljYXRpb24NCj4gICBk ZWNpZGVzIHRoZSBjb25kaXRpb25zIGZvciB3aGljaCBPU0NPUkUgaXMgcmVxdWlyZWQuDQo+DQo+ VGhpcyBpcyBwcmV0dHkgc3VycHJpc2luZyB0byBqdXN0IGRyb3AgaW4gaGVyZS4gTXVsdGljYXN0 IGhhcyB0b3RhbGx5DQo+ZGlmZmVyZW50DQo+c2VjdXJpdHkgcHJvcGVydGllcyBmcm9tIG5vbi1t dWx0aWNhc3QuDQo+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPg0KPg0KPg0KPiAgIGJ1dCBpcyBhbHNvIGFibGUgdG8gZWF2ZXNkcm9wIG9uLCBvciBtYW5p cHVsYXRlIGFueSBwYXJ0IG9mIHRoZQ0KPiAgIG1lc3NhZ2UgcGF5bG9hZCBhbmQgbWV0YWRhdGEs IGluIHRyYW5zaXQgYmV0d2VlbiB0aGUgZW5kcG9pbnRzLiAgVGhlDQo+ICAgcHJveHkgY2FuIGFs c28gaW5qZWN0LCBkZWxldGUsIG9yIHJlb3JkZXIgcGFja2V0cyBzaW5jZSB0aGV5IGFyZSBubw0K Pk5pdDogeW91IHdhbnQNCj4iZWF2ZXNkcm9wIG9uLCBvciBtYW5pcHVsYXRlIGFueSBwYXJ0IG9m LCB0aGUgbWVzc2FnZSBwYXlsb2FkIGFuZA0KPm1ldGFkYXRhIGluDQo+dHJhbnNpdCINCj4NCj5J LmUuLCBtb3ZlIHRoZSBzZWNvbmQgY29tbWENCj4NCj4gICB0aGUgZW5kcG9pbnRzLCBhbmQgdGhv c2UgYXJlIHRoZXJlZm9yZSBwcm9jZXNzZWQgYXMgZGVmaW5lZCBpbg0KPiAgIFtSRkM3MjUyXS4g IEFkZGl0aW9uYWxseSwgc2luY2UgdGhlIG1lc3NhZ2UgZm9ybWF0cyBmb3IgQ29BUCBvdmVyDQo+ ICAgdW5yZWxpYWJsZSB0cmFuc3BvcnQgW1JGQzcyNTJdIGFuZCBmb3IgQ29BUCBvdmVyIHJlbGlh YmxlIHRyYW5zcG9ydA0KPk5pdDogIk9TQ09SRSBwcm90ZWN0cyBuZWl0aGVyIC4uLi4gbm9yLi4u LiINCj4NCj4gICAgICBTYWx0LiAgTGVuZ3RoIGlzIGRldGVybWluZWQgYnkgdGhlIEFFQUQgQWxn b3JpdGhtLiAgSXRzIHZhbHVlIGlzDQo+PiAgICAgIGltbXV0YWJsZSBvbmNlIHRoZSBzZWN1cml0 eSBjb250ZXh0IGlzIGVzdGFibGlzaGVkLg0KPk5pdDogeW91IG1pZ2h0IGp1c3Qgc2F5IGFib3Zl IG9yIGJlbG93IHRoaXMgbGlzdCB0aGF0IGFsbCB0aGUgdmFsdWVzIGFyZQ0KPmltbXV0YWJsZSwN Cj4NCj4gICBkaWZmZXJlbnQgb3BlcmF0aW9ucy4gIE9uZSBtZWNoYW5pc20gZW5hYmxpbmcgdGhp cyBpcyBzcGVjaWZpZWQgaW4NCj4gICBbSS1ELmlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnXS4N Cj5JcyB0aGlzIGEgc2VjdXJpdHkgY29uZGl0aW9uPw0KPg0KPiAgICAgIG9mIFtSRkM3MjUyXSwg d2hlcmUgdGhlIGRlbHRhIGlzIHRoZSBkaWZmZXJlbmNlIHRvIHRoZSBwcmV2aW91c2x5DQo+ICAg ICAgaW5jbHVkZWQgY2xhc3MgSSBvcHRpb24uDQo+SXMgdGhlIGRlbHRhIGhlcmUgdGhlIHByZXZp b3VzbHkgaW5jbHVkZWQgQ2xhc3MgSSBvcHRpb24gb3IgdGhlIHByZXZpb3VzbHkNCj5pbmNsdWRl ZCBpbnN0YW5jZSBvZiB0aGUgc2FtZSBvcHRpb24sIGFzIGl0IGFwcGVhcnMgdG8gc2F5IGluIFMg My4xLg0KPg0KPiAgICAgICAgIGNvbXByZXNzZWQgQ09TRSBvYmplY3QuICBUaGUgdmFsdWVzIG4g PSA2IGFuZCBuID0gNyBhcmUNCj4gICAgICAgICByZXNlcnZlZC4NCj5Ib3cgY2FuIFBhcnRpYWwg SVYgbm90IGJlIHByZXNlbnQ/IGl0J3MgdGhlIHNlcXVlbmNlIG51bWJlci4gSXMgdGhlDQo+YW5z d2VyIHRoYXQNCj5pdCBpcyB0aGUgMCB2YWx1ZT8NCj4NCj4gICByZXNwb25zZS4gIFRoZSBzZXJ2 ZXIgdGhlcmVmb3JlIG5lZWRzIHRvIHN0b3JlIHRoZSBraWQgYW5kIFBhcnRpYWwgSVYNCj4gICBv ZiB0aGUgcmVxdWVzdCB1bnRpbCBhbGwgcmVzcG9uc2VzIGhhdmUgYmVlbiBzZW50Lg0KPkl0IHdh cyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGtpZCB3YXMgbmVlZGVkIHRvIGxvb2sgdXAgdGhl IGtleS4gV2h5DQo+YXJlIGtpZA0KPnN1YnN0aXR1dGlvbiBhdHRhY2tzIGFuIGlzc3VlPw0KPg0K PiAgIFRoZSBtYXhpbXVtIFNlbmRlciBTZXF1ZW5jZSBOdW1iZXIgaXMgYWxnb3JpdGhtIGRlcGVu ZGVudCAoc2VlDQo+ICAgU2VjdGlvbiAxMSksIGFuZCBubyBncmVhdGVyIHRoYW4gMl40MCAtIDEu ICBJZiB0aGUgU2VuZGVyIFNlcXVlbmNlDQo+ICAgTnVtYmVyIGV4Y2VlZHMgdGhlIG1heGltdW0s IHRoZSBlbmRwb2ludCBNVVNUIE5PVCBwcm9jZXNzIGFueSBtb3JlDQo+SWYgeW91IHRha2UgbXkg c3VnZ2VzdGlvbiBhYm91dCByZW1vdmluZyBzZW5kZXJJRCBmcm9tIHRoZSBub25jZSB5b3Ugd2ls bA0KPmJlDQo+YWJsZSB0byByZWxheCB0aGlzLg0KPg0KPiAgIEFmdGVyIGJvb3QsIGFuIGVuZHBv aW50IE1BWSByZWplY3QgdG8gdXNlIGV4aXN0aW5nIHNlY3VyaXR5IGNvbnRleHRzDQo+ICAgZnJv bSBiZWZvcmUgaXQgYm9vdGVkIGFuZCBNQVkgZXN0YWJsaXNoIGEgbmV3IHNlY3VyaXR5IGNvbnRl eHQgd2l0aA0KPk5pdDogdGhpcyBpcyB1bmdyYW1tYXRpY2FsDQo+DQo+ICAgICAgIGluY2x1ZGVk IGluIHRoZSBtZXNzYWdlLiAgSWYgdGhlIEFFQUQgbm9uY2UgZnJvbSB0aGUgcmVxdWVzdCB3YXMN Cj4gICAgICAgdXNlZCwgdGhlIFBhcnRpYWwgSVYgTVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4gdGhl IG1lc3NhZ2UuDQo+SU1QT1JUQU5UOiBZb3UgYXJlIG5vdyB2aW9sYXRpbmcgdGhlIGludmFyaWFu dCBvZiB1c2luZyB0aGUgc2FtZSBub25jZQ0KPnR3aWNlLg0KPlRoYXQncyBmaW5lIGluIHRoaXMg Y2FzZSwgYmVjYXVzZSB5b3UgaGF2ZSBwZXItc2VuZGVyIGtleXMgYnV0IGl0DQo+ZGVtb25zdHJh dGVzDQo+dGhhdCBpdCBpcyB1bm5lY2Vzc2FyeSB0byBlbmNvZGUgdGhlIHNlbmRlcl9pZCBpbiB0 aGUgbm9uY2UgZmllbGQuDQo+DQo+ICAgU2VjdXJpdHkgbGV2ZWwgaGVyZSBtZWFucyB0aGF0IGFu IGF0dGFja2VyIGNhbiByZWNvdmVyIG9uZSBvZiB0aGUgbQ0KPiAgIGtleXMgd2l0aCBjb21wbGV4 aXR5IDJeKGsgKyBuKSAvIG0uICBQcm90ZWN0aW9uIGFnYWluc3Qgc3VjaCBhdHRhY2tzDQo+ICAg Y2FuIGJlIHByb3ZpZGVkIGJ5IGluY3JlYXNpbmcgdGhlIHNpemUgb2YgdGhlIGtleXMgb3IgdGhl IGVudHJvcHkgb2YNCj5UaGlzIHBhcmFncmFwaCBpcyBleHRyZW1lbHkgaGFyZCB0byBmb2xsb3cg YnV0IEkgYW0gbm90IHBlcnN1YWRlZCB0aGF0IGl0DQo+aXMNCj5jb3JyZWN0LiBEbyB5b3UgaGF2 ZSBhIGNpdGF0aW9uIGZvciB0aGUgY2xhaW0gdGhhdCB5b3UgY2FuIGFkZCB0aGUga2V5DQo+ZW50 cm9weQ0KPmFuZCB0aGUgbm9uY2UgZW50cm9weSBsaWtlIHRoaXMuDQo+DQo+ICAgc3R5bGUgb2Yg cGFkZGluZyBtZWFucyB0aGF0IGFsbCB2YWx1ZXMgbmVlZCB0byBiZSBwYWRkZWQuICBTaW1pbGFy DQo+ICAgYXJndW1lbnRzIGFwcGx5IHRvIG90aGVyIG1lc3NhZ2UgZmllbGRzIHN1Y2ggYXMgcmVz b3VyY2UgbmFtZXMuDQo+VGhlIFBLQ1MjNyBwYWRkaW5nIHNjaGVtZSBhdCBtaW5pbXVtIGhhcyBw b3RlbnRpYWwgdGltaW5nIGNoYW5uZWxzDQo+DQo+ICAgVGhlIHNlcnZlciB2ZXJpZmllcyB0aGF0 IHRoZSBQYXJ0aWFsIElWIGhhcyBub3QgYmVlbiByZWNlaXZlZCBiZWZvcmUuDQo+ICAgVGhlIGNs aWVudCB2ZXJpZmllcyB0aGF0IHRoZSByZXNwb25zZSBpcyBib3VuZCB0byB0aGUgcmVxdWVzdC4N Cj5Ib3cgZG9lcyB0aGUgY2xpZW50IHZlcmlmeSB0aGlzDQo+DQo+ICAgICAgIFBhcnRpYWwgSVYg KGluIG5ldHdvcmsgYnl0ZSBvcmRlcikgd2l0aCB6ZXJvZXMgdG8gZXhhY3RseSBub25jZQ0KPiAg ICAgICBsZW5ndGggLSA2IGJ5dGVzLA0KPg0KPklNUE9SVEFOVDogSSBkb24ndCB1bmRlcnN0YW5k IHRoZSByZWFzb24gZm9yIHRoaXMgY29uc3RydWN0aW9uLiBZb3UNCj5hbHJlYWR5IHJlcXVpcmUg dGhhdCB0aGUga2V5IGJlIGRlcml2ZWQgdmlhIEhLREYgZnJvbSB0aGUgfG1hc3RlciBrZXl8DQo+ YW5kIHxzZW5kZXIgSUR8IHRoZXJlZm9yZSwgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IHRvIHNlcGFy YXRlbHkgZW5jb2RlDQo+dGhlIHNlbmRlciBJRCBpbiB0aGUgbm9uY2UuIFRoaXMgd291bGQgb3Jk aW5hcmlseSBub3QgYmUgYSBsYXJnZQ0KPmlzc3VlLCBidXQgYXMgaXQgcmVxdWlyZXMgdmVyeSBl eHRyZW1lIHJlc3RyaWN0aW9ucyBvbiB0aGUgc2VuZGVyIElEDQo+KGFuZCBlc3NlbnRpYWxseSBw cmVjbHVkZXMgcmFuZG9tIHNlbmRlciBJRHMpIEkgYmVsaWV2ZSBpdCBpcyB3b3J0aA0KPmNvbnNp ZGVyaW5nIGNoYW5naW5nLCBidXQgaXQncyB1bHRpbWF0ZWx5IGEgV0cgZGVjaXNpb24sIGhlbmNl IG5vdA0KPmluIG15IGRpc2N1c3MuDQo+DQo+DQoNCg0KDQo= --_000_D6C71CA5A15F7goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5IDggTWFyY2ggMjAxOCBh dCAxNjozOTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkfD tnJhbiBTZWxhbmRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbSI+Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5UaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmciPmRyYWZ0LWll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZyI+ZHJhZnQtaWV0 Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzwvYT4mZ3Q7LA0KIENhcnN0ZW4gQm9ybWFu biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+Y2Fib0B0emkub3JnPC9hPiZndDss IEphaW1lIEppbcOpbmV6ICZsdDs8YSBocmVmPSJtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nv bi5jb20iPmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpjb3JlLWNoYWlyc0BpZXRmLm9yZyI+Y29yZS1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmciPmNvcmUtY2hhaXJz QGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmci PmNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogRXJpYyBSZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIE1hciA4LCAyMDE4IGF0IDc6MjMgQU0sIEfDtnJh biBTZWxhbmRlciA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNl bGFuZGVyQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdvcmFuLnNlbGFuZGVyQGVyaWNz c29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk O2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Im1fLTM4MzY5OTQwMzY3OTE5MjA3OTBPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O3RleHQtYWxpZ246bGVmdDtjb2xv cjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1bSBub25l O1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6MGluO0JP UkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25lO1BBRERJ TkctVE9QOjNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFu PkVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0i X2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXkgOCBNYXJjaCAyMDE4IGF0IDE2OjA2PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+R8O2cmFuIFNlbGFuZGVy ICZsdDs8YSBocmVmPSJtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5UaGUgSUVTRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXNnQGlldGYub3JnPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC08d2JyPnNl Y3VyaXR5QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt Y29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRm LWNvcmUtb2JqZWN0LTx3YnI+c2VjdXJpdHlAaWV0Zi5vcmc8L2E+Jmd0OywNCiBDYXJzdGVuIEJv cm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciIHRhcmdldD0iX2JsYW5rIj5j YWJvQHR6aS5vcmc8L2E+Jmd0OywgSmFpbWUgSmltw6luZXogJmx0OzxhIGhyZWY9Im1haWx0bzpq YWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphaW1lLmppbWVuZXpA ZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpjb3JlLWNoYWlyc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmUtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90Ow0K ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5jb3JlLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y29y ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8 L3NwYW4+UmU6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1vYmpl Y3QtPHdicj5zZWN1cml0eS0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8YnI+DQo8L2Rp dj4NCjxzcGFuIGNsYXNzPSIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJt Xy0zODM2OTk0MDM2NzkxOTIwNzkwTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIg c3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYgNSBzb2xpZDtQQURESU5HOjAgMCAwIDU7TUFSR0lO OjAgMCAwIDUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgTWFy IDgsIDIwMTggYXQgNjo1OSBBTSwgR8O2cmFuIFNlbGFuZGVyIDxzcGFuIGRpcj0ibHRyIj4NCiZs dDs8YSBocmVmPSJtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9i bGFuayI+Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi cj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KQW5vdGhl ciByZWN1cnJpbmcgY29tbWVudCBpcyB0aGUgaW1wYWN0IG9mIGEgcHJveHkgY2hhbmdpbmcgY2Vy dGFpbiBDb0FQPGJyPg0KbWVzc2FnZSBmaWVsZHMgbGlrZSBlLmcuIE1lc3NhZ2UgSUQsIFRva2Vu IG9yIFVyaS1Ib3N0LiBTaW5jZSBDb0FQIGRlZmluZXM8YnI+DQpsZWdpdGltYXRlIHByb3h5IG9w ZXJhdGlvbnMsIHRoZXNlIG1lc3NhZ2UgZmllbGRzIGNhbm5vdCBiZSBpbnRlZ3JpdHk8YnI+DQpw cm90ZWN0ZWQgZW5kLXRvLWVuZC4gQ3VycmVudCBzZWN1cml0eSBzb2x1dGlvbnMgZWl0aGVyIGRv ZXMgbm90IGFsbG93PGJyPg0KcHJveHkgb3BlcmF0aW9ucyBvciBsZWF2ZSBhbGwgbWVzc2FnZSBm aWVsZHMgdW5wcm90ZWN0ZWQgaW4gdGhlIHByb3h5LiBXZTxicj4NCndpbGwgdHJ5IHRvIG1ha2Ug dGhpcyBtb3JlIGNsZWFyLjxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlRoZSBxdWVzdGlvbiBpcyB3aGF0IHRoZSBzZWN1cml0eSBpbXBhY3Qgb2YgdGhlc2UgaXMu PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlllcywgYW5kIHdl IHdpbGwgdHJ5IHRvIGFkZHJlc3MgdGhpcy4gQnV0IGl0IGlzIGEgZ2VuZXJhbCBwcm9wZXJ0eSBv ZiBDb0FQIHdoZW4gcHJveGllcyBhcmUgdXNlZC48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WWVzLCBidXQgdGhlIHdob2xlIHBvaW50IG9mIHRo aXMgZGVzaWduIGlzIHRvIHByb3RlY3QgdG8gc29tZSBleHRlbnQgYWdhaW5zdCBtYWxpY2lvdXMg cHJveGllcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIGJ1dCBu b3QgYWdhaW5zdCBwcm94eSBvcGVyYXRpb25zIHdoaWNoIGFyZSBkZWZpbmVkIGFzIGxlZ2l0aW1h dGUgYnkgQ29BUCBhbmQvb3Igd2hlcmUgdGhlcmUgYXJlIG90aGVyIG1lYW5zIHRvIHZlcmlmeSB0 aGUgb3BlcmF0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6 MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv cmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiI+PHNwYW4gaWQ9Im1fLTM4MzY5OTQwMzY3OTE5MjA3 OTBPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0ibV8tMzgzNjk5NDAzNjc5 MTkyMDc5ME1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt TEVGVDojYjVjNGRmIDUgc29saWQ7UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij4NCkEgdGhpcmQgdGhpbmcgaW4gRXJpY+KAmXMgcmV2aWV3IGlzIHRoZSBj b25zdHJ1Y3Rpb24gb2YgdGhlIG5vbmNlIHdoZXJlIHRoZTxicj4NCklEIGlzIGluY2x1ZGVkLiBU aGUgcmVhc29uIGZvciB0aGlzIGlzIHRvIGhhbmRsZSBlbmRwb2ludHMgc3dpdGNoaW5nIHJvbGVz PGJyPg0KKENvQVAgY2xpZW50ICZsdDstJmd0OyBDb0FQIHNlcnZlcikmbmJzcDsgd2hpY2ggaXMg c3VwcG9ydGVkIGJ5IENvQVAsIGFuZCBpbjxicj4NCnBhcnRpY3VsYXI8YnI+DQpncm91cCBjb21t dW5pY2F0aW9ucyB3aXRoIG9uZSBzZW5kZXIgYW5kIG11bHRpcGxlIHJlY2lwaWVudHM8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGRvbid0IHNlZSBob3cgdGhhdCBpcyBy ZWxldmFudCwgZ2l2ZW4gdGhhdCB5b3UgYWxyZWFkeSBoYXZlIGtleSBzZXBhcmF0aW9uPC9kaXY+ DQo8ZGl2PmZvciB0aGUgc2VuZGVyIGtleSwgd2hhdCBzZXBhcmF0ZSBpbmZvcm1hdGlvbiBpcyB0 aGVyZSBpbiB0aGUgbm9uY2U/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvc3Bh bj4NCjxkaXY+VGhlIHNlbmRlciBrZXkgaXMgdXNlZCBib3RoIGluIHRoZSByb2xlIG9mIGNsaWVu dCBtYWtpbmcgYSByZXF1ZXN0ICh3aXRoIG93biBwYXJ0aWFsIElWKSBhbmQgaW4gdGhlIHJvbGUg b2Ygc2VydmVyIHJlc3BvbmRpbmcgdG8gYSByZXF1ZXN0ICh3aXRoIHRoZSBvdGhlciBlbmRwb2lu dOKAmXMgcGFydGlhbCBJVikuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PlRoaXMgc2VlbXMgZXh0cmVtZWx5IGhhcmQgdG8gYW5hbHl6ZS4gWW91 IHNob3VsZCBqdXN0IHVzZSBzZXBhcmF0ZSBrZXlzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYXQgaXMgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gd2hpY2ggaXMgbGVz cyBvcHRpbWlzZWQgZS5nLiBpbiB0ZXJtcyBvZiBzaXplIG9mIGdyb3VwIGNvbW11bmljYXRpb24g c2VjdXJpdHkgY29udGV4dC4gTGV0IHVzIGNvbWUgYmFjayBvbiB0aGF0LjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+R8O2cmFuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xp ZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1Fa3I8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXpl OjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuIGNsYXNzPSJIT0Vu WmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkfDtnJh bjwvZGl2Pg0KPC9mb250Pjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Im1fLTM4MzY5OTQwMzY3OTE5MjA3OTBPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0ibV8tMzgzNjk5NDAzNjc5MTkyMDc5ME1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUg c29saWQ7UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tRWtyPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPg0KLiBXaGlsZSB0aGU8YnI+DQpsYXR0ZXIgaXMgdGhlIHRvcGljIG9m IGEgc2VwYXJhdGUgZHJhZnQ8YnI+DQooZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW88d2Jy PnNjb2FwKSBhbmQgdGhlIHByb3BlcnRpZXMgaW4gdGhhdCBzZXR0aW5nIGlzPGJyPg0Kb3V0IG9m IHNjb3BlIG9mIHRoaXMgZHJhZnQsIHdlIHdpbGwgYWRkIG1vcmUgZXhwbGFuYXRpb24gdG8gdGhl IHNlY3VyaXR5PGJyPg0KZGVzaWduIGFuZCB0aGUgdW5pY2FzdCBzZWN1cml0eSBwcm9wZXJ0aWVz IGluIGdlbmVyYWwgdG8gdGhpcyBkcmFmdC48YnI+DQo8YnI+DQo8YnI+DQpNb3JlIGxhdGVyLjxi cj4NCjxzcGFuIGNsYXNzPSJtXy0zODM2OTk0MDM2NzkxOTIwNzkwSE9FblpiIj48Zm9udCBjb2xv cj0iIzg4ODg4OCI+PGJyPg0KR8O2cmFuPGJyPg0KPC9mb250Pjwvc3Bhbj4NCjxkaXYgY2xhc3M9 Im1fLTM4MzY5OTQwMzY3OTE5MjA3OTBIT0VuWmIiPg0KPGRpdiBjbGFzcz0ibV8tMzgzNjk5NDAz Njc5MTkyMDc5MGg1Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAyMDE4LTAzLTA4IDAzOjU4 LCAmcXVvdDtFcmljIFJlc2NvcmxhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0u Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJy Pg0KJmd0O0VyaWMgUmVzY29ybGEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yPGJyPg0KJmd0O2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpPHdicj50eS0w OTogRGlzY3Vzczxicj4NCiZndDs8YnI+DQomZ3Q7V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2Vl cCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KJmd0O2VtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzPGJyPg0KJmd0O2ludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O1BsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0PHdicj5lbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PGJyPg0KJmd0O2ZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCiZndDs8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNl Y3VyaXR5LyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy88d2JyPmRvYy9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlYzx3YnI+dXJp dHkvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdi cj4tLS0tLS0tLS0tLTxicj4NCiZndDtESVNDVVNTOjxicj4NCiZndDstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0t LS0tLS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYu ZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDMwNzUiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2RlPHdicj52Lm1vemF3cy5uZXQvRDMwNzU8 L2E+PGJyPg0KJmd0Ozxicj4NCiZndDtESVNDVVNTPGJyPg0KJmd0O015IG92ZXJhbGwgY29uY2Vy biB3aXRoIHRoaXMgZG9jdW1lbnQgaXMgdGhhdCBJIGFtIHVuYWJsZSB0byBldmFsdWF0ZTxicj4N CiZndDt0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiB0aGUgc3lzdGVtLiBJIGhhdmUgZGVzY3Jp YmVkIGEgbnVtYmVyIG9mPGJyPg0KJmd0O2lzc3VlcyBiZWxvdywgYnV0IHRoZSBiYXNpYyBwcm9i bGVtIGlzIHRoYXQgdGhpcyBzb3J0IG9mIHBhcnRpYWw8YnI+DQomZ3Q7cHJvdGVjdGlvbiBpcyBl eHRyZW1lbHkgaGFyZCB0byByZWFzb24gYWJvdXQgYW5kIHRoZSBzZWN1cml0eTxicj4NCiZndDtj b25zaWRlcmF0aW9ucyBkbyBub3QgZG8gYW4gYWRlcXVhdGUgam9iIG9mIGV2YWx1YXRpbmcgdGhl IGltcGFjdCBvZjxicj4NCiZndDtwcm94aWVzIG1vZGlmeWluZyB0aGVzZSB2YWx1ZXMuIEkgYW0g c2ltaWxhcmx5IGNvbmNlcm5lZCBhYm91dCB0aGU8YnI+DQomZ3Q7SFRUUCBtYXBwaW5nIGFuZCBs aW5rIHNlY3Rpb24gd2hpY2ggc2VlbXMgZXh0cmVtZWx5IHNrZXRjaHkgYW5kIGhhczxicj4NCiZn dDtlc3NlbnRpYWxseSBubyBzZWN1cml0eSBhbmFseXNpcywgYW5kIHlldCBwb3RlbnRpYWxseSBo YXZlIGEgbG90PGJyPg0KJmd0O29mIGxhbmRtaW5lcy48YnI+DQomZ3Q7PGJyPg0KJmd0O0F0IG1p bmltdW0sIHRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gd2FsayB0aHJvdWdoIHRoZSBpbXBsaWNhdGlv bnM8YnI+DQomZ3Q7b2YgbW9kaWZpY2F0aW9ucyBieSB0aGUgcHJveHkgdG8gZXZlcnkgdW5wcm90 ZWN0ZWQgZmllbGQgaW48YnI+DQomZ3Q7dGhlIHB1cmUgQ29BUCBjb250ZXh0IGFzIHdlbGwgYXMg dGhlIEhUVFAgY29udGV4dCAoaWYgeW91IHdhbnQ8YnI+DQomZ3Q7dG8gcmV0YWluIHRoYXQgYmlu ZGluZykuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7YXJlIGdpdmVuIGluIEFwcGVu ZGl4IEEuJm5ic3A7IE9TQ09SRSBkb2VzIG5vdCBkZXBlbmQgb24gdW5kZXJseWluZzxicj4NCiZn dDsmbmJzcDsgJm5ic3A7bGF5ZXJzLCBhbmQgY2FuIGJlIHVzZWQgYW55d2hlcmUgd2hlcmUgQ29B UCBvciBIVFRQIGNhbiBiZSB1c2VkLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7aW5jbHVkaW5nIG5v bi1JUCB0cmFuc3BvcnRzIChlLmcuLCBbSS1ELmJvcm1hbm4tNmxvLWNvYXAtODAyLTE1LWk8d2Jy PmVdKS48YnI+DQomZ3Q7PGJyPg0KJmd0O0lNUE9SVEFOVDogVGhpcyBkb2N1bWVudCBjbGFpbXMg dG8gYmUgYXBwbGljYWJsZSB0byBwcm90b2NvbHMgb3RoZXI8YnI+DQomZ3Q7dGhhbiBDT0FQLCBp biBwYXJ0aWN1bGFyIEhUVFAuIEhhcyB0aGlzIGJlZW4gcmV2aWV3ZWQgYnkgdGhlIEhUVFA8YnI+ DQomZ3Q7d29ya2luZyBncm91cD8gTWFydGluIFRob21zb24ncyByZXZpZXcgc3VnZ2VzdHMgdGhh dCB0aGlzIGlzIG91dCBvZjxicj4NCiZndDtzdGVwIHdpdGggSFRUUCBwcmFjdGljZS48YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtJRHMgTVVTVCBiZSBsb25nIHVuaWZvcm1seSByYW5k b20gZGlzdHJpYnV0ZWQgYnl0ZSBzdHJpbmdzIHN1Y2ggdGhhdDxicj4NCiZndDsmbmJzcDsgJm5i c3A7dGhlIHByb2JhYmlsaXR5IG9mIGNvbGxpc2lvbnMgaXMgbmVnbGlnaWJsZS48YnI+DQomZ3Q7 PGJyPg0KJmd0O0lNUE9SVEFOVDogSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGlzIHBhcmFncmFw aCBhbmQgdGhlIHByZXZpb3VzPGJyPg0KJmd0O3BhcmFncmFwaCBpbnRlcmFjdC4gWW91IHNheSB0 aGF0IHRoZSBtYXhpbXVtIGxlbmd0aCBpcyA3IG9jdGV0cyBpbiB0aGU8YnI+DQomZ3Q7cHJldmlv dXMgcGFyYWdyYXBoLCB3aGljaCBJIGRvbid0IHRoaW5rIHF1YWxpZmllcyBhcyAmcXVvdDtsb25n JnF1b3Q7Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5i c3A7MSB8IElmLU1hdGNoJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgeCB8Jm5ic3A7ICZu YnNwO3w8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7MyB8IFVyaS1I b3N0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7fCB4IHw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7NCB8IEVUYWcmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IHggfCZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0 O0lNUE9SVEFOVDogV2h5IGRvIHlvdSB0aGluayB0aGF0IGl0J3Mgbm90IGltcG9ydGFudCB0byBo YXZlIGludGVncml0eTxicj4NCiZndDtwcm90ZWN0aW9uIGZvciBVcmktSG9zdCBhbmQgVXJpLXBv cnQ/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7T3V0ZXIgb3B0aW9uIG1lc3NhZ2Ug ZmllbGRzIChDbGFzcyBVIG9yIEkpIGFyZSB1c2VkIHRvIHN1cHBvcnQgcHJveHk8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwO29wZXJhdGlvbnMuPGJyPg0KJmd0O0lNUE9SVEFOVDogVGhpcyBzZWVtcyBw cm9ibGVtYXRpYyBiZWNhdXNlIHRoZSBwcm94eSBjYW5ub3QgdmVyaWZ5IGNsYXNzIEk8YnI+DQom Z3Q7ZmllbGRzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2xheWVyIG9ubHksIGFu ZCBub3QgdGhlIE1lc3NhZ2luZyBMYXllciAoU2VjdGlvbiAyIG9mIFtSRkM3MjUyXSksIHNvPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDtmaWVsZHMgc3VjaCBhcyBUeXBlIGFuZCBNZXNzYWdlIElEIGFy ZSBub3QgcHJvdGVjdGVkIHdpdGggT1NDT1JFLjxicj4NCiZndDs8YnI+DQomZ3Q7SU1QT1JUQU5U OiBUaGlzIHNlZW1zIGV4dHJlbWVseSBoYXJkIHRvIHJlYXNvbiBhYm91dC4gV2hhdCBhcmUgdGhl PGJyPg0KJmd0O2ltcGxpY2F0aW9ucyBvZiB0aGUgcHJveHkgYmVpbmcgYWJsZSB0byBjaGFuZ2Ug dGhlc2U/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7byZuYnNwOyByZXF1ZXN0X3Bp djogY29udGFpbnMgdGhlIHZhbHVlIG9mIHRoZSAnUGFydGlhbCBJVicgaW4gdGhlIENPU0U8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgb2JqZWN0IG9mIHRoZSByZXF1ZXN0IChzZWUgU2Vj dGlvbiA1KS48YnI+DQomZ3Q7PGJyPg0KJmd0O0lNUE9SVEFOVDogSSB0aGluayB3aGF0IEkgYW0g Z2V0dGluZyBoZXJlIGlzIHRoYXQgdGhlIHJlcXVlc3RfcGl2IGlzPGJyPg0KJmd0O3VzZWQgdG8g dmVyaWZ5IHRoYXQgdGhlIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1hdGNoLiBIb3dldmVyLCBJIGRv IG5vdDxicj4NCiZndDtzZWUgdGhpcyBleHBsaWNpdGx5IHN0YXRlZCBhbnl3aGVyZSwgYW5kIGl0 J3Mgbm90IGNsZWFyIHRvIG1lIGhvdyB0aGU8YnI+DQomZ3Q7Y2xpZW50IGlzIHN1cHBvc2VkIHRv IHJlY292ZXIgdGhlIHJlcXVlc3RfcGl2IGFuZCB0aGUgdGV4dCBpcyBwcmV0dHk8YnI+DQomZ3Q7 dW5jbGVhciBoZXJlPyBJcyB0aGUgZXh0ZXJuYWxfYWFkIGNhcnJpZWQgc29tZXdoZXJlIGluIHRo ZSBtZXNzYWdlPyBBbTxicj4NCiZndDtJIHN1cHBvc2VkIHRvIHJlY29uc3RydWN0IGl0IGZyb20g dGhlIG1lc3NhZ2UgaWQ/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7Rm9yIHJlc3Bv bnNlcywgdGhlIG1lc3NhZ2UgYmluZGluZyBndWFyYW50ZWVzIHRoYXQgYSByZXNwb25zZSBpcyBu b3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO29sZGVyIHRoYW4gaXRzIHJlcXVlc3QuJm5ic3A7IEZv ciByZXNwb25zZXMgd2l0aG91dCBPYnNlcnZlLCB0aGlzIGdpdmVzPGJyPg0KJmd0Ozxicj4NCiZn dDtJTVBPUlRBTlQ6IEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIGlzIHRydWUuIFdoYXQgaGFwcGVu cyBvZiB0aGU8YnI+DQomZ3Q7Y291bnRlcnBhcnR5IGxpZXM/IFdoYXQgaXMgeW91ciB0aHJlYXQg bW9kZWw/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7QW4gZXh0ZW5zaW9uIG9mIE9T Q09SRSBtYXkgYWxzbyBiZSB1c2VkIHRvIHByb3RlY3QgZ3JvdXA8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwO2NvbW11bmljYXRpb24gZm9yIENvQVAgW0ktRC50aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Nj PHdicj5vYXBdLiZuYnNwOyBUaGUgdXNlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtvZiBPU0NPUkUg ZG9lcyBub3QgYWZmZWN0IHRoZSBVUkkgc2NoZW1lIGFuZCBPU0NPUkUgY2FuIHRoZXJlZm9yZSBi ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7dXNlZCB3aXRoIGFueSBVUkkgc2NoZW1lIGRlZmluZWQg Zm9yIENvQVAgb3IgSFRUUC4mbmJzcDsgVGhlIGFwcGxpY2F0aW9uPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDtkZWNpZGVzIHRoZSBjb25kaXRpb25zIGZvciB3aGljaCBPU0NPUkUgaXMgcmVxdWlyZWQu PGJyPg0KJmd0Ozxicj4NCiZndDtUaGlzIGlzIHByZXR0eSBzdXJwcmlzaW5nIHRvIGp1c3QgZHJv cCBpbiBoZXJlLiBNdWx0aWNhc3QgaGFzIHRvdGFsbHk8YnI+DQomZ3Q7ZGlmZmVyZW50PGJyPg0K Jmd0O3NlY3VyaXR5IHByb3BlcnRpZXMgZnJvbSBub24tbXVsdGljYXN0Ljxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tPGJyPg0KJmd0O0NPTU1FTlQ6 PGJyPg0KJmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtidXQgaXMgYWxzbyBhYmxlIHRvIGVhdmVzZHJv cCBvbiwgb3IgbWFuaXB1bGF0ZSBhbnkgcGFydCBvZiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw O21lc3NhZ2UgcGF5bG9hZCBhbmQgbWV0YWRhdGEsIGluIHRyYW5zaXQgYmV0d2VlbiB0aGUgZW5k cG9pbnRzLiZuYnNwOyBUaGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3Byb3h5IGNhbiBhbHNvIGlu amVjdCwgZGVsZXRlLCBvciByZW9yZGVyIHBhY2tldHMgc2luY2UgdGhleSBhcmUgbm88YnI+DQom Z3Q7Tml0OiB5b3Ugd2FudDxicj4NCiZndDsmcXVvdDtlYXZlc2Ryb3Agb24sIG9yIG1hbmlwdWxh dGUgYW55IHBhcnQgb2YsIHRoZSBtZXNzYWdlIHBheWxvYWQgYW5kPGJyPg0KJmd0O21ldGFkYXRh IGluPGJyPg0KJmd0O3RyYW5zaXQmcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0O0kuZS4sIG1vdmUg dGhlIHNlY29uZCBjb21tYTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3RoZSBlbmRw b2ludHMsIGFuZCB0aG9zZSBhcmUgdGhlcmVmb3JlIHByb2Nlc3NlZCBhcyBkZWZpbmVkIGluPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDtbUkZDNzI1Ml0uJm5ic3A7IEFkZGl0aW9uYWxseSwgc2luY2Ug dGhlIG1lc3NhZ2UgZm9ybWF0cyBmb3IgQ29BUCBvdmVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt1 bnJlbGlhYmxlIHRyYW5zcG9ydCBbUkZDNzI1Ml0gYW5kIGZvciBDb0FQIG92ZXIgcmVsaWFibGUg dHJhbnNwb3J0PGJyPg0KJmd0O05pdDogJnF1b3Q7T1NDT1JFIHByb3RlY3RzIG5laXRoZXIgLi4u LiBub3IuLi4uJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBT YWx0LiZuYnNwOyBMZW5ndGggaXMgZGV0ZXJtaW5lZCBieSB0aGUgQUVBRCBBbGdvcml0aG0uJm5i c3A7IEl0cyB2YWx1ZSBpczxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaW1tdXRh YmxlIG9uY2UgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgZXN0YWJsaXNoZWQuPGJyPg0KJmd0O05p dDogeW91IG1pZ2h0IGp1c3Qgc2F5IGFib3ZlIG9yIGJlbG93IHRoaXMgbGlzdCB0aGF0IGFsbCB0 aGUgdmFsdWVzIGFyZTxicj4NCiZndDtpbW11dGFibGUsPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ZGlmZmVyZW50IG9wZXJhdGlvbnMuJm5ic3A7IE9uZSBtZWNoYW5pc20gZW5hYmxp bmcgdGhpcyBpcyBzcGVjaWZpZWQgaW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1tJLUQuaWV0Zi1j b3JlLWVjaG8tcmVxdWVzdC10PHdicj5hZ10uPGJyPg0KJmd0O0lzIHRoaXMgYSBzZWN1cml0eSBj b25kaXRpb24/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBvZiBbUkZD NzI1Ml0sIHdoZXJlIHRoZSBkZWx0YSBpcyB0aGUgZGlmZmVyZW5jZSB0byB0aGUgcHJldmlvdXNs eTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmNsdWRlZCBjbGFzcyBJIG9wdGlvbi48 YnI+DQomZ3Q7SXMgdGhlIGRlbHRhIGhlcmUgdGhlIHByZXZpb3VzbHkgaW5jbHVkZWQgQ2xhc3Mg SSBvcHRpb24gb3IgdGhlIHByZXZpb3VzbHk8YnI+DQomZ3Q7aW5jbHVkZWQgaW5zdGFuY2Ugb2Yg dGhlIHNhbWUgb3B0aW9uLCBhcyBpdCBhcHBlYXJzIHRvIHNheSBpbiBTIDMuMS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb21wcmVzc2VkIENP U0Ugb2JqZWN0LiZuYnNwOyBUaGUgdmFsdWVzIG4gPSA2IGFuZCBuID0gNyBhcmU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Jlc2VydmVkLjxicj4NCiZndDtIb3cg Y2FuIFBhcnRpYWwgSVYgbm90IGJlIHByZXNlbnQ/IGl0J3MgdGhlIHNlcXVlbmNlIG51bWJlci4g SXMgdGhlPGJyPg0KJmd0O2Fuc3dlciB0aGF0PGJyPg0KJmd0O2l0IGlzIHRoZSAwIHZhbHVlPzxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3Jlc3BvbnNlLiZuYnNwOyBUaGUgc2VydmVy IHRoZXJlZm9yZSBuZWVkcyB0byBzdG9yZSB0aGUga2lkIGFuZCBQYXJ0aWFsIElWPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDtvZiB0aGUgcmVxdWVzdCB1bnRpbCBhbGwgcmVzcG9uc2VzIGhhdmUgYmVl biBzZW50Ljxicj4NCiZndDtJdCB3YXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBraWQgd2Fz IG5lZWRlZCB0byBsb29rIHVwIHRoZSBrZXkuIFdoeTxicj4NCiZndDthcmUga2lkPGJyPg0KJmd0 O3N1YnN0aXR1dGlvbiBhdHRhY2tzIGFuIGlzc3VlPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwO1RoZSBtYXhpbXVtIFNlbmRlciBTZXF1ZW5jZSBOdW1iZXIgaXMgYWxnb3JpdGhtIGRl cGVuZGVudCAoc2VlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtTZWN0aW9uIDExKSwgYW5kIG5vIGdy ZWF0ZXIgdGhhbiAyXjQwIC0gMS4mbmJzcDsgSWYgdGhlIFNlbmRlciBTZXF1ZW5jZTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7TnVtYmVyIGV4Y2VlZHMgdGhlIG1heGltdW0sIHRoZSBlbmRwb2ludCBN VVNUIE5PVCBwcm9jZXNzIGFueSBtb3JlPGJyPg0KJmd0O0lmIHlvdSB0YWtlIG15IHN1Z2dlc3Rp b24gYWJvdXQgcmVtb3Zpbmcgc2VuZGVySUQgZnJvbSB0aGUgbm9uY2UgeW91IHdpbGw8YnI+DQom Z3Q7YmU8YnI+DQomZ3Q7YWJsZSB0byByZWxheCB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO0FmdGVyIGJvb3QsIGFuIGVuZHBvaW50IE1BWSByZWplY3QgdG8gdXNlIGV4aXN0 aW5nIHNlY3VyaXR5IGNvbnRleHRzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtmcm9tIGJlZm9yZSBp dCBib290ZWQgYW5kIE1BWSBlc3RhYmxpc2ggYSBuZXcgc2VjdXJpdHkgY29udGV4dCB3aXRoPGJy Pg0KJmd0O05pdDogdGhpcyBpcyB1bmdyYW1tYXRpY2FsPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmNsdWRlZCBpbiB0aGUgbWVzc2FnZS4mbmJzcDsgSWYg dGhlIEFFQUQgbm9uY2UgZnJvbSB0aGUgcmVxdWVzdCB3YXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dXNlZCwgdGhlIFBhcnRpYWwgSVYgTVVTVCBOT1QgYmUgaW5jbHVkZWQg aW4gdGhlIG1lc3NhZ2UuPGJyPg0KJmd0O0lNUE9SVEFOVDogWW91IGFyZSBub3cgdmlvbGF0aW5n IHRoZSBpbnZhcmlhbnQgb2YgdXNpbmcgdGhlIHNhbWUgbm9uY2U8YnI+DQomZ3Q7dHdpY2UuPGJy Pg0KJmd0O1RoYXQncyBmaW5lIGluIHRoaXMgY2FzZSwgYmVjYXVzZSB5b3UgaGF2ZSBwZXItc2Vu ZGVyIGtleXMgYnV0IGl0PGJyPg0KJmd0O2RlbW9uc3RyYXRlczxicj4NCiZndDt0aGF0IGl0IGlz IHVubmVjZXNzYXJ5IHRvIGVuY29kZSB0aGUgc2VuZGVyX2lkIGluIHRoZSBub25jZSBmaWVsZC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtTZWN1cml0eSBsZXZlbCBoZXJlIG1lYW5z IHRoYXQgYW4gYXR0YWNrZXIgY2FuIHJlY292ZXIgb25lIG9mIHRoZSBtPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDtrZXlzIHdpdGggY29tcGxleGl0eSAyXihrICYjNDM7IG4pIC8gbS4mbmJzcDsgUHJv dGVjdGlvbiBhZ2FpbnN0IHN1Y2ggYXR0YWNrczxicj4NCiZndDsmbmJzcDsgJm5ic3A7Y2FuIGJl IHByb3ZpZGVkIGJ5IGluY3JlYXNpbmcgdGhlIHNpemUgb2YgdGhlIGtleXMgb3IgdGhlIGVudHJv cHkgb2Y8YnI+DQomZ3Q7VGhpcyBwYXJhZ3JhcGggaXMgZXh0cmVtZWx5IGhhcmQgdG8gZm9sbG93 IGJ1dCBJIGFtIG5vdCBwZXJzdWFkZWQgdGhhdCBpdDxicj4NCiZndDtpczxicj4NCiZndDtjb3Jy ZWN0LiBEbyB5b3UgaGF2ZSBhIGNpdGF0aW9uIGZvciB0aGUgY2xhaW0gdGhhdCB5b3UgY2FuIGFk ZCB0aGUga2V5PGJyPg0KJmd0O2VudHJvcHk8YnI+DQomZ3Q7YW5kIHRoZSBub25jZSBlbnRyb3B5 IGxpa2UgdGhpcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtzdHlsZSBvZiBwYWRk aW5nIG1lYW5zIHRoYXQgYWxsIHZhbHVlcyBuZWVkIHRvIGJlIHBhZGRlZC4mbmJzcDsgU2ltaWxh cjxicj4NCiZndDsmbmJzcDsgJm5ic3A7YXJndW1lbnRzIGFwcGx5IHRvIG90aGVyIG1lc3NhZ2Ug ZmllbGRzIHN1Y2ggYXMgcmVzb3VyY2UgbmFtZXMuPGJyPg0KJmd0O1RoZSBQS0NTIzcgcGFkZGlu ZyBzY2hlbWUgYXQgbWluaW11bSBoYXMgcG90ZW50aWFsIHRpbWluZyBjaGFubmVsczxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1RoZSBzZXJ2ZXIgdmVyaWZpZXMgdGhhdCB0aGUgUGFy dGlhbCBJViBoYXMgbm90IGJlZW4gcmVjZWl2ZWQgYmVmb3JlLjxicj4NCiZndDsmbmJzcDsgJm5i c3A7VGhlIGNsaWVudCB2ZXJpZmllcyB0aGF0IHRoZSByZXNwb25zZSBpcyBib3VuZCB0byB0aGUg cmVxdWVzdC48YnI+DQomZ3Q7SG93IGRvZXMgdGhlIGNsaWVudCB2ZXJpZnkgdGhpczxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGFydGlhbCBJViAoaW4gbmV0 d29yayBieXRlIG9yZGVyKSB3aXRoIHplcm9lcyB0byBleGFjdGx5IG5vbmNlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlbmd0aCAtIDYgYnl0ZXMsPGJyPg0KJmd0Ozxicj4N CiZndDtJTVBPUlRBTlQ6IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmVhc29uIGZvciB0aGlzIGNv bnN0cnVjdGlvbi4gWW91PGJyPg0KJmd0O2FscmVhZHkgcmVxdWlyZSB0aGF0IHRoZSBrZXkgYmUg ZGVyaXZlZCB2aWEgSEtERiBmcm9tIHRoZSB8bWFzdGVyIGtleXw8YnI+DQomZ3Q7YW5kIHxzZW5k ZXIgSUR8IHRoZXJlZm9yZSwgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IHRvIHNlcGFyYXRlbHkgZW5j b2RlPGJyPg0KJmd0O3RoZSBzZW5kZXIgSUQgaW4gdGhlIG5vbmNlLiBUaGlzIHdvdWxkIG9yZGlu YXJpbHkgbm90IGJlIGEgbGFyZ2U8YnI+DQomZ3Q7aXNzdWUsIGJ1dCBhcyBpdCByZXF1aXJlcyB2 ZXJ5IGV4dHJlbWUgcmVzdHJpY3Rpb25zIG9uIHRoZSBzZW5kZXIgSUQ8YnI+DQomZ3Q7KGFuZCBl c3NlbnRpYWxseSBwcmVjbHVkZXMgcmFuZG9tIHNlbmRlciBJRHMpIEkgYmVsaWV2ZSBpdCBpcyB3 b3J0aDxicj4NCiZndDtjb25zaWRlcmluZyBjaGFuZ2luZywgYnV0IGl0J3MgdWx0aW1hdGVseSBh IFdHIGRlY2lzaW9uLCBoZW5jZSBub3Q8YnI+DQomZ3Q7aW4gbXkgZGlzY3Vzcy48YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D6C71CA5A15F7goranselanderericssoncom_-- From nobody Thu Mar 8 09:06:53 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FA312711B for ; Thu, 8 Mar 2018 09:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 fxyCifdRuoFp for ; Thu, 8 Mar 2018 09:06:44 -0800 (PST) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (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 43A2D12751F for ; Thu, 8 Mar 2018 09:06:40 -0800 (PST) Received: by mail-qk0-f179.google.com with SMTP id s198so460098qke.5 for ; Thu, 08 Mar 2018 09:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nd5hPQ+VLN93eKG8Ttm1RYr//VVoLVyvFIrSowSdjX0=; b=wMpBlGnTR1O3hoE16SiopVUuutGan9nQIiC8FRxedrZLg6AsGGXy3EO3P24UpLT8z/ o6cWBKu0QfOwgdtsX7FNX4ThDxRrlsjngHThIAB7W0snxZD+RLyUTyZfofWnkzGwO7IQ Ubtze0KhWtDlcGJ38135rPDAhQsyVo/NPu0eNCeB283HmkUVzrcQSvY6opRGhALv3VDD QVhbxW/xEWXmLqTrIQ3/U3Kp5WkSln7+VzIulSk0MMAnLxDvpKJrVo9kzQwBhenUUFSt pnyp3KYKDSZLWfNuGGxaqPfkf8USliZTFlUf3ItXJ8slGmsI8hsQgw+CzIDDKrLcmqZ1 q2+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nd5hPQ+VLN93eKG8Ttm1RYr//VVoLVyvFIrSowSdjX0=; b=oz95p+O79n6PUm/GRbbIASwS97z17w499YV3On06H2QPXaQbxhRFdeAIyZ6F8m2AGM 5sW/IWGd7/3A69hwZSbZ2GXN0HbmABJRIPL39cumpbkhW9oAyspIs1k/PUv562JrsGBU cRR0z9GstziPmQ8niq+sSjqB0hPxcMfgbcPrlW0YOvl4GYB2OS0CQLCpsBWVQwbpErSE YYC9w4uk7ZbUOFsKp4TYxuVWtpeoWi+nZqHTmtjQppvJOeTJakDS5AcfZrltuokh9f5I N1F8gi6VmOZtDj3sAUSfHa5Fqs1s0fNQepuiYINVahORY/cRy6kySchxInLiHqafu+FI mRZg== X-Gm-Message-State: AElRT7EGdn90jRpOVkQte3TJIZekjJiJYaw8CtHUnG5MRutTQJgirXJ3 8nw7fA7N/4+uj9FYXfnWSlzydqJklL0Tq4bqumMeHw== X-Google-Smtp-Source: AG47ELsdTAAxMCQD2+tt+bfr5eLY8qdEp+V5725lKTbnCLw8ViBaqFCO74FfpeZWQMHnfs7D6Nc8GbVwvnUu+AW3UQo= X-Received: by 10.55.221.198 with SMTP id u67mr40477434qku.91.1520528798956; Thu, 08 Mar 2018 09:06:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Thu, 8 Mar 2018 09:05:58 -0800 (PST) In-Reply-To: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 8 Mar 2018 09:05:58 -0800 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: The IESG , "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , "core-chairs@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="001a114992e0eeeadd0566e9b2a4" Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 17:06:47 -0000 --001a114992e0eeeadd0566e9b2a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 8, 2018 at 8:24 AM, G=C3=B6ran Selander wrote: > > > From: Eric Rescorla > Date: Thursday 8 March 2018 at 16:39 > To: G=C3=B6ran Selander > Cc: The IESG , "draft-ietf-core-object-security@ietf.org" = < > draft-ietf-core-object-security@ietf.org>, Carsten Bormann = , > Jaime Jim=C3=A9nez , "core-chairs@ietf.org" < > core-chairs@ietf.org>, "core@ietf.org" > Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-0= 9: > (with DISCUSS and COMMENT) > > > > On Thu, Mar 8, 2018 at 7:23 AM, G=C3=B6ran Selander < > goran.selander@ericsson.com> wrote: > >> >> >> From: Eric Rescorla >> Date: Thursday 8 March 2018 at 16:06 >> To: G=C3=B6ran Selander >> Cc: The IESG , "draft-ietf-core-object-security@ietf.org" >> , Carsten Bormann , >> Jaime Jim=C3=A9nez , "core-chairs@ietf.org" = < >> core-chairs@ietf.org>, "core@ietf.org" >> Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-= 09: >> (with DISCUSS and COMMENT) >> >> >> >> On Thu, Mar 8, 2018 at 6:59 AM, G=C3=B6ran Selander < >> goran.selander@ericsson.com> wrote: >> >>> Another recurring comment is the impact of a proxy changing certain CoA= P >>> message fields like e.g. Message ID, Token or Uri-Host. Since CoAP >>> defines >>> legitimate proxy operations, these message fields cannot be integrity >>> protected end-to-end. Current security solutions either does not allow >>> proxy operations or leave all message fields unprotected in the proxy. = We >>> will try to make this more clear. >>> >> >> The question is what the security impact of these is. >> >> >> Yes, and we will try to address this. But it is a general property of >> CoAP when proxies are used. >> > > Yes, but the whole point of this design is to protect to some extent > against malicious proxies. > > > Yes, but not against proxy operations which are defined as legitimate by > CoAP and/or where there are other means to verify the operation. > Whether these operations are in fact safe is the question at hand. I will wait for your detailed analysis. -Ekr > > A third thing in Eric=E2=80=99s review is the construction of the nonce w= here the >>> ID is included. The reason for this is to handle endpoints switching >>> roles >>> (CoAP client <-> CoAP server) which is supported by CoAP, and in >>> particular >>> group communications with one sender and multiple recipients >> >> >> I don't see how that is relevant, given that you already have key >> separation >> for the sender key, what separate information is there in the nonce? >> >> >> The sender key is used both in the role of client making a request (with >> own partial IV) and in the role of server responding to a request (with = the >> other endpoint=E2=80=99s partial IV). >> > > This seems extremely hard to analyze. You should just use separate keys. > > > That is an alternative solution which is less optimised e.g. in terms of > size of group communication security context. Let us come back on that. > > G=C3=B6ran > > > -Ekr > > >> G=C3=B6ran >> >> >> -Ekr >> >> >> >>> . While the >>> latter is the topic of a separate draft >>> (draft-tiloca-core-multicast-oscoap) and the properties in that setting >>> is >>> out of scope of this draft, we will add more explanation to the securit= y >>> design and the unicast security properties in general to this draft. >>> >>> >>> More later. >>> >>> G=C3=B6ran >>> >>> >>> >>> >>> On 2018-03-08 03:58, "Eric Rescorla" wrote: >>> >>> >Eric Rescorla has entered the following ballot position for >>> >draft-ietf-core-object-security-09: Discuss >>> > >>> >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 thi= s >>> >introductory paragraph, however.) >>> > >>> > >>> >Please refer to https://www.ietf.org/iesg/stat >>> ement/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-object-security/ >>> > >>> > >>> > >>> >---------------------------------------------------------------------- >>> >DISCUSS: >>> >---------------------------------------------------------------------- >>> > >>> >https://mozphab-ietf.devsvcdev.mozaws.net/D3075 >>> > >>> >DISCUSS >>> >My overall concern with this document is that I am unable to evaluate >>> >the security properties of the system. I have described a number of >>> >issues below, but the basic problem is that this sort of partial >>> >protection is extremely hard to reason about and the security >>> >considerations do not do an adequate job of evaluating the impact of >>> >proxies modifying these values. I am similarly concerned about the >>> >HTTP mapping and link section which seems extremely sketchy and has >>> >essentially no security analysis, and yet potentially have a lot >>> >of landmines. >>> > >>> >At minimum, this document needs to walk through the implications >>> >of modifications by the proxy to every unprotected field in >>> >the pure CoAP context as well as the HTTP context (if you want >>> >to retain that binding). >>> > >>> > are given in Appendix A. OSCORE does not depend on underlying >>> > layers, and can be used anywhere where CoAP or HTTP can be used, >>> > including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-i >>> e]). >>> > >>> >IMPORTANT: This document claims to be applicable to protocols other >>> >than COAP, in particular HTTP. Has this been reviewed by the HTTP >>> >working group? Martin Thomson's review suggests that this is out of >>> >step with HTTP practice. >>> > >>> > IDs MUST be long uniformly random distributed byte strings such tha= t >>> > the probability of collisions is negligible. >>> > >>> >IMPORTANT: I don't understand how this paragraph and the previous >>> >paragraph interact. You say that the maximum length is 7 octets in the >>> >previous paragraph, which I don't think qualifies as "long". >>> > >>> > | 1 | If-Match | x | | >>> > | 3 | Uri-Host | | x | >>> > | 4 | ETag | x | | >>> >IMPORTANT: Why do you think that it's not important to have integrity >>> >protection for Uri-Host and Uri-port? >>> > >>> > Outer option message fields (Class U or I) are used to support prox= y >>> > operations. >>> >IMPORTANT: This seems problematic because the proxy cannot verify clas= s >>> I >>> >fields. >>> > >>> > layer only, and not the Messaging Layer (Section 2 of [RFC7252]), s= o >>> > fields such as Type and Message ID are not protected with OSCORE. >>> > >>> >IMPORTANT: This seems extremely hard to reason about. What are the >>> >implications of the proxy being able to change these? >>> > >>> > o request_piv: contains the value of the 'Partial IV' in the COSE >>> > object of the request (see Section 5). >>> > >>> >IMPORTANT: I think what I am getting here is that the request_piv is >>> >used to verify that the request and response match. However, I do not >>> >see this explicitly stated anywhere, and it's not clear to me how the >>> >client is supposed to recover the request_piv and the text is pretty >>> >unclear here? Is the external_aad carried somewhere in the message? Am >>> >I supposed to reconstruct it from the message id? >>> > >>> > For responses, the message binding guarantees that a response is no= t >>> > older than its request. For responses without Observe, this gives >>> > >>> >IMPORTANT: I am not sure that this is true. What happens of the >>> >counterparty lies? What is your threat model? >>> > >>> > An extension of OSCORE may also be used to protect group >>> > communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use >>> > of OSCORE does not affect the URI scheme and OSCORE can therefore b= e >>> > used with any URI scheme defined for CoAP or HTTP. The application >>> > decides the conditions for which OSCORE is required. >>> > >>> >This is pretty surprising to just drop in here. Multicast has totally >>> >different >>> >security properties from non-multicast. >>> > >>> > >>> >---------------------------------------------------------------------- >>> >COMMENT: >>> >---------------------------------------------------------------------- >>> > >>> > >>> > >>> > but is also able to eavesdrop on, or manipulate any part of the >>> > message payload and metadata, in transit between the endpoints. Th= e >>> > proxy can also inject, delete, or reorder packets since they are no >>> >Nit: you want >>> >"eavesdrop on, or manipulate any part of, the message payload and >>> >metadata in >>> >transit" >>> > >>> >I.e., move the second comma >>> > >>> > the endpoints, and those are therefore processed as defined in >>> > [RFC7252]. Additionally, since the message formats for CoAP over >>> > unreliable transport [RFC7252] and for CoAP over reliable transport >>> >Nit: "OSCORE protects neither .... nor...." >>> > >>> > Salt. Length is determined by the AEAD Algorithm. Its value is >>> >> immutable once the security context is established. >>> >Nit: you might just say above or below this list that all the values a= re >>> >immutable, >>> > >>> > different operations. One mechanism enabling this is specified in >>> > [I-D.ietf-core-echo-request-tag]. >>> >Is this a security condition? >>> > >>> > of [RFC7252], where the delta is the difference to the previousl= y >>> > included class I option. >>> >Is the delta here the previously included Class I option or the >>> previously >>> >included instance of the same option, as it appears to say in S 3.1. >>> > >>> > compressed COSE object. The values n =3D 6 and n =3D 7 are >>> > reserved. >>> >How can Partial IV not be present? it's the sequence number. Is the >>> >answer that >>> >it is the 0 value? >>> > >>> > response. The server therefore needs to store the kid and Partial = IV >>> > of the request until all responses have been sent. >>> >It was my understanding that the kid was needed to look up the key. Wh= y >>> >are kid >>> >substitution attacks an issue? >>> > >>> > The maximum Sender Sequence Number is algorithm dependent (see >>> > Section 11), and no greater than 2^40 - 1. If the Sender Sequence >>> > Number exceeds the maximum, the endpoint MUST NOT process any more >>> >If you take my suggestion about removing senderID from the nonce you >>> will >>> >be >>> >able to relax this. >>> > >>> > After boot, an endpoint MAY reject to use existing security context= s >>> > from before it booted and MAY establish a new security context with >>> >Nit: this is ungrammatical >>> > >>> > included in the message. If the AEAD nonce from the request wa= s >>> > used, the Partial IV MUST NOT be included in the message. >>> >IMPORTANT: You are now violating the invariant of using the same nonce >>> >twice. >>> >That's fine in this case, because you have per-sender keys but it >>> >demonstrates >>> >that it is unnecessary to encode the sender_id in the nonce field. >>> > >>> > Security level here means that an attacker can recover one of the m >>> > keys with complexity 2^(k + n) / m. Protection against such attack= s >>> > can be provided by increasing the size of the keys or the entropy o= f >>> >This paragraph is extremely hard to follow but I am not persuaded that >>> it >>> >is >>> >correct. Do you have a citation for the claim that you can add the key >>> >entropy >>> >and the nonce entropy like this. >>> > >>> > style of padding means that all values need to be padded. Similar >>> > arguments apply to other message fields such as resource names. >>> >The PKCS#7 padding scheme at minimum has potential timing channels >>> > >>> > The server verifies that the Partial IV has not been received befor= e. >>> > The client verifies that the response is bound to the request. >>> >How does the client verify this >>> > >>> > Partial IV (in network byte order) with zeroes to exactly nonce >>> > length - 6 bytes, >>> > >>> >IMPORTANT: I don't understand the reason for this construction. You >>> >already require that the key be derived via HKDF from the |master key| >>> >and |sender ID| therefore, it is not necessarily to separately encode >>> >the sender ID in the nonce. This would ordinarily not be a large >>> >issue, but as it requires very extreme restrictions on the sender ID >>> >(and essentially precludes random sender IDs) I believe it is worth >>> >considering changing, but it's ultimately a WG decision, hence not >>> >in my discuss. >>> > >>> > >>> >>> >> > --001a114992e0eeeadd0566e9b2a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 8, 2018 at 8:24 AM, G=C3=B6ran Selander &= lt;goran.s= elander@ericsson.com> wrote:


From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday 8 March 2018 at 16:3= 9
To: G=C3=B6ran Selander <goran.selander@er= icsson.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf= -core-object-security@ietf.org" <draft-ietf-core-object= -security@ietf.org>, Carsten Bormann <cabo= @tzi.org>, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com>, "core-chairs@ietf.org= " <co= re-chairs@ietf.org>, "core@ietf.org= " <core@ietf.org= >
Subject: Re: Eric Rescorla's Di= scuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT= )



On Thu, Mar 8, 2018 at 7:23 AM, G=C3=B6ran Selan= der <goran.= selander@ericsson.com> wrote:


From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday 8 March 2018 at 16:0= 6
To: G=C3=B6ran Selander <goran.selander@er= icsson.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf= -core-object-security@ietf.org" <draft-ietf-core-object= -security@ietf.org>, Carsten Bormann <cabo= @tzi.org>, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com>, "core-chairs@ietf.org= " <core-chairs@= ietf.org>, "= core@ietf.org" <core@ietf.org>
Subject: Re: Eric Rescorla's Di= scuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT= )



On Thu, Mar 8, 2018 at 6:59 AM, G=C3=B6ran Selan= der <goran.= selander@ericsson.com> wrote:
Another recurring comment is the impact of a proxy changing certain CoAP message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines<= br> legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We will try to make this more clear.

The question is what the security impact of these is.

Yes, and we will try to address this. But it is a general property of = CoAP when proxies are used.

Yes, but the whole point of this design is to protect to some extent a= gainst malicious proxies.

Yes, but not against proxy operations which are defined as legitimate = by CoAP and/or where there are other means to verify the operation.

Whether these operations are in fact s= afe is the question at hand. I will wait for your detailed analysis.
<= div>
-Ekr

=


A third thing in Eric=E2=80=99s review is the construction of the nonce whe= re the
ID is included. The reason for this is to handle endpoints switching roles<= br> (CoAP client <-> CoAP server)=C2=A0 which is supported by CoAP, and i= n
particular
group communications with one sender and multiple recipients

I don't see how that is relevant, given that you already have key = separation
for the sender key, what separate information is there in the nonce?

The sender key is used both in the role of client making a request (wi= th own partial IV) and in the role of server responding to a request (with = the other endpoint=E2=80=99s partial IV).

This seems extremely hard to analyze. You should just use separate key= s.

That is an alternative solution which is less optimised e.g. in= terms of size of group communication security context. Let us come back on= that.

G=C3=B6ran


-Ekr


G=C3=B6ran


-Ekr

=C2=A0
. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that settin= g is
out of scope of this draft, we will add more explanation to the security design and the unicast security properties in general to this draft.


More later.

G=C3=B6ran




On 2018-03-08 03:58, "Eric Rescorla" <ekr@rtfm.com> wrote:

>Eric Rescorla has entered the following ballot position for
>draft-ietf-core-object-security-09: Discuss
>
>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-object-security/
>
>
>
>-------------------------------------------------------------= ---------
>DISCUSS:
>-------------------------------------------------------------= ---------
>
>https://mozphab-ietf.devsvcdev.mozaws.net/D3= 075
>
>DISCUSS
>My overall concern with this document is that I am unable to evaluate >the security properties of the system. I have described a number of
>issues below, but the basic problem is that this sort of partial
>protection is extremely hard to reason about and the security
>considerations do not do an adequate job of evaluating the impact of >proxies modifying these values. I am similarly concerned about the
>HTTP mapping and link section which seems extremely sketchy and has
>essentially no security analysis, and yet potentially have a lot
>of landmines.
>
>At minimum, this document needs to walk through the implications
>of modifications by the proxy to every unprotected field in
>the pure CoAP context as well as the HTTP context (if you want
>to retain that binding).
>
>=C2=A0 =C2=A0are given in Appendix A.=C2=A0 OSCORE does not depend on u= nderlying
>=C2=A0 =C2=A0layers, and can be used anywhere where CoAP or HTTP can be= used,
>=C2=A0 =C2=A0including non-IP transports (e.g., [I-D.bormann-6lo-coap-8= 02-15-ie]).
>
>IMPORTANT: This document claims to be applicable to protocols other
>than COAP, in particular HTTP. Has this been reviewed by the HTTP
>working group? Martin Thomson's review suggests that this is out of=
>step with HTTP practice.
>
>=C2=A0 =C2=A0IDs MUST be long uniformly random distributed byte strings= such that
>=C2=A0 =C2=A0the probability of collisions is negligible.
>
>IMPORTANT: I don't understand how this paragraph and the previous >paragraph interact. You say that the maximum length is 7 octets in the<= br> >previous paragraph, which I don't think qualifies as "long&quo= t;.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A01 | If-Match=C2=A0 =C2=A0 =C2=A0 =C2=A0 | x |=C2=A0 =C2= =A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A03 | Uri-Host=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|= x |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A04 | ETag=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x |= =C2=A0 =C2=A0|
>IMPORTANT: Why do you think that it's not important to have integri= ty
>protection for Uri-Host and Uri-port?
>
>=C2=A0 =C2=A0Outer option message fields (Class U or I) are used to sup= port proxy
>=C2=A0 =C2=A0operations.
>IMPORTANT: This seems problematic because the proxy cannot verify class= I
>fields.
>
>=C2=A0 =C2=A0layer only, and not the Messaging Layer (Section 2 of [RFC= 7252]), so
>=C2=A0 =C2=A0fields such as Type and Message ID are not protected with = OSCORE.
>
>IMPORTANT: This seems extremely hard to reason about. What are the
>implications of the proxy being able to change these?
>
>=C2=A0 =C2=A0o=C2=A0 request_piv: contains the value of the 'Partia= l IV' in the COSE
>=C2=A0 =C2=A0 =C2=A0 object of the request (see Section 5).
>
>IMPORTANT: I think what I am getting here is that the request_piv is >used to verify that the request and response match. However, I do not >see this explicitly stated anywhere, and it's not clear to me how t= he
>client is supposed to recover the request_piv and the text is pretty >unclear here? Is the external_aad carried somewhere in the message? Am<= br> >I supposed to reconstruct it from the message id?
>
>=C2=A0 =C2=A0For responses, the message binding guarantees that a respo= nse is not
>=C2=A0 =C2=A0older than its request.=C2=A0 For responses without Observ= e, this gives
>
>IMPORTANT: I am not sure that this is true. What happens of the
>counterparty lies? What is your threat model?
>
>=C2=A0 =C2=A0An extension of OSCORE may also be used to protect group >=C2=A0 =C2=A0communication for CoAP [I-D.tiloca-core-multicast-osc= oap].=C2=A0 The use
>=C2=A0 =C2=A0of OSCORE does not affect the URI scheme and OSCORE can th= erefore be
>=C2=A0 =C2=A0used with any URI scheme defined for CoAP or HTTP.=C2=A0 T= he application
>=C2=A0 =C2=A0decides the conditions for which OSCORE is required.
>
>This is pretty surprising to just drop in here. Multicast has totally >different
>security properties from non-multicast.
>
>
>-------------------------------------------------------------= ---------
>COMMENT:
>-------------------------------------------------------------= ---------
>
>
>
>=C2=A0 =C2=A0but is also able to eavesdrop on, or manipulate any part o= f the
>=C2=A0 =C2=A0message payload and metadata, in transit between the endpo= ints.=C2=A0 The
>=C2=A0 =C2=A0proxy can also inject, delete, or reorder packets since th= ey are no
>Nit: you want
>"eavesdrop on, or manipulate any part of, the message payload and<= br> >metadata in
>transit"
>
>I.e., move the second comma
>
>=C2=A0 =C2=A0the endpoints, and those are therefore processed as define= d in
>=C2=A0 =C2=A0[RFC7252].=C2=A0 Additionally, since the message formats f= or CoAP over
>=C2=A0 =C2=A0unreliable transport [RFC7252] and for CoAP over reliable = transport
>Nit: "OSCORE protects neither .... nor...."
>
>=C2=A0 =C2=A0 =C2=A0 Salt.=C2=A0 Length is determined by the AEAD Algor= ithm.=C2=A0 Its value is
>>=C2=A0 =C2=A0 =C2=A0 immutable once the security context is establi= shed.
>Nit: you might just say above or below this list that all the values ar= e
>immutable,
>
>=C2=A0 =C2=A0different operations.=C2=A0 One mechanism enabling this is= specified in
>=C2=A0 =C2=A0[I-D.ietf-core-echo-request-tag].
>Is this a security condition?
>
>=C2=A0 =C2=A0 =C2=A0 of [RFC7252], where the delta is the difference to= the previously
>=C2=A0 =C2=A0 =C2=A0 included class I option.
>Is the delta here the previously included Class I option or the previou= sly
>included instance of the same option, as it appears to say in S 3.1. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compressed COSE object.=C2=A0 The val= ues n =3D 6 and n =3D 7 are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reserved.
>How can Partial IV not be present? it's the sequence number. Is the=
>answer that
>it is the 0 value?
>
>=C2=A0 =C2=A0response.=C2=A0 The server therefore needs to store the ki= d and Partial IV
>=C2=A0 =C2=A0of the request until all responses have been sent.
>It was my understanding that the kid was needed to look up the key. Why=
>are kid
>substitution attacks an issue?
>
>=C2=A0 =C2=A0The maximum Sender Sequence Number is algorithm dependent = (see
>=C2=A0 =C2=A0Section 11), and no greater than 2^40 - 1.=C2=A0 If the Se= nder Sequence
>=C2=A0 =C2=A0Number exceeds the maximum, the endpoint MUST NOT process = any more
>If you take my suggestion about removing senderID from the nonce you wi= ll
>be
>able to relax this.
>
>=C2=A0 =C2=A0After boot, an endpoint MAY reject to use existing securit= y contexts
>=C2=A0 =C2=A0from before it booted and MAY establish a new security con= text with
>Nit: this is ungrammatical
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0included in the message.=C2=A0 If the AEAD n= once from the request was
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used, the Partial IV MUST NOT be included in= the message.
>IMPORTANT: You are now violating the invariant of using the same nonce<= br> >twice.
>That's fine in this case, because you have per-sender keys but it >demonstrates
>that it is unnecessary to encode the sender_id in the nonce field.
>
>=C2=A0 =C2=A0Security level here means that an attacker can recover one= of the m
>=C2=A0 =C2=A0keys with complexity 2^(k + n) / m.=C2=A0 Protection again= st such attacks
>=C2=A0 =C2=A0can be provided by increasing the size of the keys or the = entropy of
>This paragraph is extremely hard to follow but I am not persuaded that = it
>is
>correct. Do you have a citation for the claim that you can add the key<= br> >entropy
>and the nonce entropy like this.
>
>=C2=A0 =C2=A0style of padding means that all values need to be padded.= =C2=A0 Similar
>=C2=A0 =C2=A0arguments apply to other message fields such as resource n= ames.
>The PKCS#7 padding scheme at minimum has potential timing channels
>
>=C2=A0 =C2=A0The server verifies that the Partial IV has not been recei= ved before.
>=C2=A0 =C2=A0The client verifies that the response is bound to the requ= est.
>How does the client verify this
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partial IV (in network byte order) with zero= es to exactly nonce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0length - 6 bytes,
>
>IMPORTANT: I don't understand the reason for this construction. You=
>already require that the key be derived via HKDF from the |master key|<= br> >and |sender ID| therefore, it is not necessarily to separately encode >the sender ID in the nonce. This would ordinarily not be a large
>issue, but as it requires very extreme restrictions on the sender ID >(and essentially precludes random sender IDs) I believe it is worth
>considering changing, but it's ultimately a WG decision, hence not<= br> >in my discuss.
>
>

--001a114992e0eeeadd0566e9b2a4-- From nobody Thu Mar 8 09:53:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF1B1243F6 for ; Thu, 8 Mar 2018 09:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DM7QEjmlJt5L for ; Thu, 8 Mar 2018 09:53:29 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 E664F12D870 for ; Thu, 8 Mar 2018 09:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520531607; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tQgq0HJECNxH2ghYiJv5QJ1+IOMhCLerEfK5U2w052Q=; b=XlL6mEpNGLweN4qkNxcnR3nMkojOi4p0KM1Ll+OsL8BRc9EDg0lSAIg4MzHe0zOR 2OQsEJiYtvjEr3YSp+XfOehCljofF5y/H4rxXGy5QZWSscz957IdabZ1aBbTHY6K o9MddH/FjSqKnrZhcjipPok425FGPTPk8HS/xyoXPV0=; X-AuditID: c1b4fb30-3b1ff70000004778-c0-5aa17896d26f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 74.FB.18296.69871AA5; Thu, 8 Mar 2018 18:53:27 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.88]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 18:53:26 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eric Rescorla CC: The IESG , "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) Thread-Index: AQHTtolfO1SWXHzYR0WCPxFNrQ+jVKPGbw+A///xRQCAABVjAP//866AgAAdYID///rZAAADwSEA Date: Thu, 8 Mar 2018 17:53:26 +0000 Message-ID: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: multipart/alternative; boundary="_000_D6C73674A1630goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUyM2J7lO70ioVRBj92M1ocmXKX1WLbxgts Fvverme2mPbvDIvFitfn2C1m/JnI7MDmsWTJTyaPyY/bmD2mLcoMYI7isklJzcksSy3St0vg yjjSeIypYOdy5oqpK5cyNzBumcPcxcjJISFgIvHj8ywgm4tDSOAwo0T3ysUsEM4iRol3Z+Yw glSxCbhIPGh4xARiiwgoSPz6cwKsiFlgFZPEzwPr2EASwgIZEu1vXjFCFGVKPN27nrWLkQPI jpJo/OYIEmYRUJHYsucRWAmvgIXE8a6zTBDL1jNLfO87CbaAUyBQYuWrQ2DnMQqISXw/tQYs ziwgLnHryXwmiLMFJJbsOQ/1gqjEy8f/WEFsUQE9ib097WwgeyUElCR6NkhBtMZK7P/wiBli r6DEyZlPWCYwis5CMnUWkrJZSMpmAU1iFtCUWL9LH6JEUWJK90N2CFtDonXOXCjbWqLt0xFW ZDULGDlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgTG7sEtvw12ML587niIUYCDUYmH16hw YZQQa2JZcWXuIUYJDmYlEd7ebKAQb0piZVVqUX58UWlOavEhRmkOFiVx3pOevFFCAumJJanZ qakFqUUwWSYOTqkGxkUZ9+7vkuVUv6j8h/E495XCvcb7Q1KvXG1qWlR0c/rPGf2sGWcuaLx8 eG3FRH6O9OabSxdumr5byDH2/iWPwy82M+/s8NSXnehnueD5ZMOgGy7Cptdy320JirTbemwT O+dN50d1O1JZfog+XznhleKuEpWZAq72366sTwn3ETSz/HiRbbpo1y8lluKMREMt5qLiRAD1 4ms82QIAAA== Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Mar 2018 17:53:34 -0000 --_000_D6C73674A1630goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29t Pj4NCkRhdGU6IFRodXJzZGF5IDggTWFyY2ggMjAxOCBhdCAxODowNQ0KVG86IEfDtnJhbiBTZWxh bmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb20+Pg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGll dGYub3JnPj4sICJkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPiIgPGRyYWZ0LWlldGYt Y29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHlAaWV0Zi5vcmc+PiwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFp bHRvOmNhYm9AdHppLm9yZz4+LCBKYWltZSBKaW3DqW5leiA8amFpbWUuamltZW5lekBlcmljc3Nv bi5jb208bWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPj4sICJjb3JlLWNoYWlyc0Bp ZXRmLm9yZzxtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmc+IiA8Y29yZS1jaGFpcnNAaWV0Zi5v cmc8bWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnPj4sICJjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPiIgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHktMDk6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCg0KDQpPbiBUaHUs IE1hciA4LCAyMDE4IGF0IDg6MjQgQU0sIEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+PiB3cm90ZToN Cg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNv bT4+DQpEYXRlOiBUaHVyc2RheSA4IE1hcmNoIDIwMTggYXQgMTY6MzkNClRvOiBHw7ZyYW4gU2Vs YW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPj4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0Bp ZXRmLm9yZz4+LCAiZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZz4iIDxkcmFmdC1pZXRm LWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2Jq ZWN0LXNlY3VyaXR5QGlldGYub3JnPj4sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1h aWx0bzpjYWJvQHR6aS5vcmc+PiwgSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nz b24uY29tPG1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbT4+LCAiY29yZS1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnPiIgPGNvcmUtY2hhaXJzQGlldGYu b3JnPG1haWx0bzpjb3JlLWNoYWlyc0BpZXRmLm9yZz4+LCAiY29yZUBpZXRmLm9yZzxtYWlsdG86 Y29yZUBpZXRmLm9yZz4iIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNvcmUtb2Jq ZWN0LXNlY3VyaXR5LTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQoNCg0KT24gVGh1 LCBNYXIgOCwgMjAxOCBhdCA3OjIzIEFNLCBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVy QGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQoNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5j b20+Pg0KRGF0ZTogVGh1cnNkYXkgOCBNYXJjaCAyMDE4IGF0IDE2OjA2DQpUbzogR8O2cmFuIFNl bGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208bWFpbHRvOmdvcmFuLnNlbGFuZGVy QGVyaWNzc29uLmNvbT4+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dA aWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0 Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9i amVjdC1zZWN1cml0eUBpZXRmLm9yZz4+LCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxt YWlsdG86Y2Fib0B0emkub3JnPj4sIEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTxtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+PiwgImNvcmUtY2hhaXJz QGlldGYub3JnPG1haWx0bzpjb3JlLWNoYWlyc0BpZXRmLm9yZz4iIDxjb3JlLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmc+PiwgImNvcmVAaWV0Zi5vcmc8bWFpbHRv OmNvcmVAaWV0Zi5vcmc+IiA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogRXJpYyBSZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1jb3JlLW9i amVjdC1zZWN1cml0eS0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KDQoNCk9uIFRo dSwgTWFyIDgsIDIwMTggYXQgNjo1OSBBTSwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRl ckBlcmljc3Nvbi5jb208bWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KQW5vdGhlciByZWN1cnJpbmcgY29tbWVudCBpcyB0aGUgaW1wYWN0IG9mIGEgcHJveHkgY2hh bmdpbmcgY2VydGFpbiBDb0FQDQptZXNzYWdlIGZpZWxkcyBsaWtlIGUuZy4gTWVzc2FnZSBJRCwg VG9rZW4gb3IgVXJpLUhvc3QuIFNpbmNlIENvQVAgZGVmaW5lcw0KbGVnaXRpbWF0ZSBwcm94eSBv cGVyYXRpb25zLCB0aGVzZSBtZXNzYWdlIGZpZWxkcyBjYW5ub3QgYmUgaW50ZWdyaXR5DQpwcm90 ZWN0ZWQgZW5kLXRvLWVuZC4gQ3VycmVudCBzZWN1cml0eSBzb2x1dGlvbnMgZWl0aGVyIGRvZXMg bm90IGFsbG93DQpwcm94eSBvcGVyYXRpb25zIG9yIGxlYXZlIGFsbCBtZXNzYWdlIGZpZWxkcyB1 bnByb3RlY3RlZCBpbiB0aGUgcHJveHkuIFdlDQp3aWxsIHRyeSB0byBtYWtlIHRoaXMgbW9yZSBj bGVhci4NCg0KVGhlIHF1ZXN0aW9uIGlzIHdoYXQgdGhlIHNlY3VyaXR5IGltcGFjdCBvZiB0aGVz ZSBpcy4NCg0KWWVzLCBhbmQgd2Ugd2lsbCB0cnkgdG8gYWRkcmVzcyB0aGlzLiBCdXQgaXQgaXMg YSBnZW5lcmFsIHByb3BlcnR5IG9mIENvQVAgd2hlbiBwcm94aWVzIGFyZSB1c2VkLg0KDQpZZXMs IGJ1dCB0aGUgd2hvbGUgcG9pbnQgb2YgdGhpcyBkZXNpZ24gaXMgdG8gcHJvdGVjdCB0byBzb21l IGV4dGVudCBhZ2FpbnN0IG1hbGljaW91cyBwcm94aWVzLg0KDQpZZXMsIGJ1dCBub3QgYWdhaW5z dCBwcm94eSBvcGVyYXRpb25zIHdoaWNoIGFyZSBkZWZpbmVkIGFzIGxlZ2l0aW1hdGUgYnkgQ29B UCBhbmQvb3Igd2hlcmUgdGhlcmUgYXJlIG90aGVyIG1lYW5zIHRvIHZlcmlmeSB0aGUgb3BlcmF0 aW9uLg0KDQpXaGV0aGVyIHRoZXNlIG9wZXJhdGlvbnMgYXJlIGluIGZhY3Qgc2FmZSBpcyB0aGUg cXVlc3Rpb24gYXQgaGFuZC4gSSB3aWxsIHdhaXQgZm9yIHlvdXIgZGV0YWlsZWQgYW5hbHlzaXMu DQoNCk1lYW53aGlsZSwgcGVvcGxlIGludGVyZXN0ZWQgaW4gdGhlIHByb2JsZW0gc3RhdGVtZW50 IGNhbiByZWFkIHRoaXM6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFydGtl LWNvcmUtZTJlLXNlY3VyaXR5LXJlcXMtMDMNCg0KR8O2cmFuDQoNCg0KLUVrcg0KDQoNCg0KQSB0 aGlyZCB0aGluZyBpbiBFcmlj4oCZcyByZXZpZXcgaXMgdGhlIGNvbnN0cnVjdGlvbiBvZiB0aGUg bm9uY2Ugd2hlcmUgdGhlDQpJRCBpcyBpbmNsdWRlZC4gVGhlIHJlYXNvbiBmb3IgdGhpcyBpcyB0 byBoYW5kbGUgZW5kcG9pbnRzIHN3aXRjaGluZyByb2xlcw0KKENvQVAgY2xpZW50IDwtPiBDb0FQ IHNlcnZlcikgIHdoaWNoIGlzIHN1cHBvcnRlZCBieSBDb0FQLCBhbmQgaW4NCnBhcnRpY3VsYXIN Cmdyb3VwIGNvbW11bmljYXRpb25zIHdpdGggb25lIHNlbmRlciBhbmQgbXVsdGlwbGUgcmVjaXBp ZW50cw0KDQpJIGRvbid0IHNlZSBob3cgdGhhdCBpcyByZWxldmFudCwgZ2l2ZW4gdGhhdCB5b3Ug YWxyZWFkeSBoYXZlIGtleSBzZXBhcmF0aW9uDQpmb3IgdGhlIHNlbmRlciBrZXksIHdoYXQgc2Vw YXJhdGUgaW5mb3JtYXRpb24gaXMgdGhlcmUgaW4gdGhlIG5vbmNlPw0KDQpUaGUgc2VuZGVyIGtl eSBpcyB1c2VkIGJvdGggaW4gdGhlIHJvbGUgb2YgY2xpZW50IG1ha2luZyBhIHJlcXVlc3QgKHdp dGggb3duIHBhcnRpYWwgSVYpIGFuZCBpbiB0aGUgcm9sZSBvZiBzZXJ2ZXIgcmVzcG9uZGluZyB0 byBhIHJlcXVlc3QgKHdpdGggdGhlIG90aGVyIGVuZHBvaW504oCZcyBwYXJ0aWFsIElWKS4NCg0K VGhpcyBzZWVtcyBleHRyZW1lbHkgaGFyZCB0byBhbmFseXplLiBZb3Ugc2hvdWxkIGp1c3QgdXNl IHNlcGFyYXRlIGtleXMuDQoNClRoYXQgaXMgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gd2hpY2gg aXMgbGVzcyBvcHRpbWlzZWQgZS5nLiBpbiB0ZXJtcyBvZiBzaXplIG9mIGdyb3VwIGNvbW11bmlj YXRpb24gc2VjdXJpdHkgY29udGV4dC4gTGV0IHVzIGNvbWUgYmFjayBvbiB0aGF0Lg0KDQpHw7Zy YW4NCg0KDQotRWtyDQoNCg0KR8O2cmFuDQoNCg0KLUVrcg0KDQoNCi4gV2hpbGUgdGhlDQpsYXR0 ZXIgaXMgdGhlIHRvcGljIG9mIGEgc2VwYXJhdGUgZHJhZnQNCihkcmFmdC10aWxvY2EtY29yZS1t dWx0aWNhc3Qtb3Njb2FwKSBhbmQgdGhlIHByb3BlcnRpZXMgaW4gdGhhdCBzZXR0aW5nIGlzDQpv dXQgb2Ygc2NvcGUgb2YgdGhpcyBkcmFmdCwgd2Ugd2lsbCBhZGQgbW9yZSBleHBsYW5hdGlvbiB0 byB0aGUgc2VjdXJpdHkNCmRlc2lnbiBhbmQgdGhlIHVuaWNhc3Qgc2VjdXJpdHkgcHJvcGVydGll cyBpbiBnZW5lcmFsIHRvIHRoaXMgZHJhZnQuDQoNCg0KTW9yZSBsYXRlci4NCg0KR8O2cmFuDQoN Cg0KDQoNCk9uIDIwMTgtMDMtMDggMDM6NTgsICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29t PG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KPkVyaWMgUmVzY29ybGEgaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ZHJhZnQtaWV0Zi1jb3JlLW9i amVjdC1zZWN1cml0eS0wOTogRGlzY3Vzcw0KPg0KPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPmVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzDQo+aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+UGxlYXNlIHJl ZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkvDQo+DQo+DQo+DQo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPkRJU0NVU1M6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPmh0dHBzOi8vbW96 cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0QzMDc1DQo+DQo+RElTQ1VTUw0KPk15IG92 ZXJhbGwgY29uY2VybiB3aXRoIHRoaXMgZG9jdW1lbnQgaXMgdGhhdCBJIGFtIHVuYWJsZSB0byBl dmFsdWF0ZQ0KPnRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRoZSBzeXN0ZW0uIEkgaGF2ZSBk ZXNjcmliZWQgYSBudW1iZXIgb2YNCj5pc3N1ZXMgYmVsb3csIGJ1dCB0aGUgYmFzaWMgcHJvYmxl bSBpcyB0aGF0IHRoaXMgc29ydCBvZiBwYXJ0aWFsDQo+cHJvdGVjdGlvbiBpcyBleHRyZW1lbHkg aGFyZCB0byByZWFzb24gYWJvdXQgYW5kIHRoZSBzZWN1cml0eQ0KPmNvbnNpZGVyYXRpb25zIGRv IG5vdCBkbyBhbiBhZGVxdWF0ZSBqb2Igb2YgZXZhbHVhdGluZyB0aGUgaW1wYWN0IG9mDQo+cHJv eGllcyBtb2RpZnlpbmcgdGhlc2UgdmFsdWVzLiBJIGFtIHNpbWlsYXJseSBjb25jZXJuZWQgYWJv dXQgdGhlDQo+SFRUUCBtYXBwaW5nIGFuZCBsaW5rIHNlY3Rpb24gd2hpY2ggc2VlbXMgZXh0cmVt ZWx5IHNrZXRjaHkgYW5kIGhhcw0KPmVzc2VudGlhbGx5IG5vIHNlY3VyaXR5IGFuYWx5c2lzLCBh bmQgeWV0IHBvdGVudGlhbGx5IGhhdmUgYSBsb3QNCj5vZiBsYW5kbWluZXMuDQo+DQo+QXQgbWlu aW11bSwgdGhpcyBkb2N1bWVudCBuZWVkcyB0byB3YWxrIHRocm91Z2ggdGhlIGltcGxpY2F0aW9u cw0KPm9mIG1vZGlmaWNhdGlvbnMgYnkgdGhlIHByb3h5IHRvIGV2ZXJ5IHVucHJvdGVjdGVkIGZp ZWxkIGluDQo+dGhlIHB1cmUgQ29BUCBjb250ZXh0IGFzIHdlbGwgYXMgdGhlIEhUVFAgY29udGV4 dCAoaWYgeW91IHdhbnQNCj50byByZXRhaW4gdGhhdCBiaW5kaW5nKS4NCj4NCj4gICBhcmUgZ2l2 ZW4gaW4gQXBwZW5kaXggQS4gIE9TQ09SRSBkb2VzIG5vdCBkZXBlbmQgb24gdW5kZXJseWluZw0K PiAgIGxheWVycywgYW5kIGNhbiBiZSB1c2VkIGFueXdoZXJlIHdoZXJlIENvQVAgb3IgSFRUUCBj YW4gYmUgdXNlZCwNCj4gICBpbmNsdWRpbmcgbm9uLUlQIHRyYW5zcG9ydHMgKGUuZy4sIFtJLUQu Ym9ybWFubi02bG8tY29hcC04MDItMTUtaWVdKS4NCj4NCj5JTVBPUlRBTlQ6IFRoaXMgZG9jdW1l bnQgY2xhaW1zIHRvIGJlIGFwcGxpY2FibGUgdG8gcHJvdG9jb2xzIG90aGVyDQo+dGhhbiBDT0FQ LCBpbiBwYXJ0aWN1bGFyIEhUVFAuIEhhcyB0aGlzIGJlZW4gcmV2aWV3ZWQgYnkgdGhlIEhUVFAN Cj53b3JraW5nIGdyb3VwPyBNYXJ0aW4gVGhvbXNvbidzIHJldmlldyBzdWdnZXN0cyB0aGF0IHRo aXMgaXMgb3V0IG9mDQo+c3RlcCB3aXRoIEhUVFAgcHJhY3RpY2UuDQo+DQo+ICAgSURzIE1VU1Qg YmUgbG9uZyB1bmlmb3JtbHkgcmFuZG9tIGRpc3RyaWJ1dGVkIGJ5dGUgc3RyaW5ncyBzdWNoIHRo YXQNCj4gICB0aGUgcHJvYmFiaWxpdHkgb2YgY29sbGlzaW9ucyBpcyBuZWdsaWdpYmxlLg0KPg0K PklNUE9SVEFOVDogSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGlzIHBhcmFncmFwaCBhbmQgdGhl IHByZXZpb3VzDQo+cGFyYWdyYXBoIGludGVyYWN0LiBZb3Ugc2F5IHRoYXQgdGhlIG1heGltdW0g bGVuZ3RoIGlzIDcgb2N0ZXRzIGluIHRoZQ0KPnByZXZpb3VzIHBhcmFncmFwaCwgd2hpY2ggSSBk b24ndCB0aGluayBxdWFsaWZpZXMgYXMgImxvbmciLg0KPg0KPiAgICAgICAgICAgICAgICAgICAg IHwgICAxIHwgSWYtTWF0Y2ggICAgICAgIHwgeCB8ICAgfA0KPiAgICAgICAgICAgICAgICAgICAg IHwgICAzIHwgVXJpLUhvc3QgICAgICAgIHwgICB8IHggfA0KPiAgICAgICAgICAgICAgICAgICAg IHwgICA0IHwgRVRhZyAgICAgICAgICAgIHwgeCB8ICAgfA0KPklNUE9SVEFOVDogV2h5IGRvIHlv dSB0aGluayB0aGF0IGl0J3Mgbm90IGltcG9ydGFudCB0byBoYXZlIGludGVncml0eQ0KPnByb3Rl Y3Rpb24gZm9yIFVyaS1Ib3N0IGFuZCBVcmktcG9ydD8NCj4NCj4gICBPdXRlciBvcHRpb24gbWVz c2FnZSBmaWVsZHMgKENsYXNzIFUgb3IgSSkgYXJlIHVzZWQgdG8gc3VwcG9ydCBwcm94eQ0KPiAg IG9wZXJhdGlvbnMuDQo+SU1QT1JUQU5UOiBUaGlzIHNlZW1zIHByb2JsZW1hdGljIGJlY2F1c2Ug dGhlIHByb3h5IGNhbm5vdCB2ZXJpZnkgY2xhc3MgSQ0KPmZpZWxkcy4NCj4NCj4gICBsYXllciBv bmx5LCBhbmQgbm90IHRoZSBNZXNzYWdpbmcgTGF5ZXIgKFNlY3Rpb24gMiBvZiBbUkZDNzI1Ml0p LCBzbw0KPiAgIGZpZWxkcyBzdWNoIGFzIFR5cGUgYW5kIE1lc3NhZ2UgSUQgYXJlIG5vdCBwcm90 ZWN0ZWQgd2l0aCBPU0NPUkUuDQo+DQo+SU1QT1JUQU5UOiBUaGlzIHNlZW1zIGV4dHJlbWVseSBo YXJkIHRvIHJlYXNvbiBhYm91dC4gV2hhdCBhcmUgdGhlDQo+aW1wbGljYXRpb25zIG9mIHRoZSBw cm94eSBiZWluZyBhYmxlIHRvIGNoYW5nZSB0aGVzZT8NCj4NCj4gICBvICByZXF1ZXN0X3Bpdjog Y29udGFpbnMgdGhlIHZhbHVlIG9mIHRoZSAnUGFydGlhbCBJVicgaW4gdGhlIENPU0UNCj4gICAg ICBvYmplY3Qgb2YgdGhlIHJlcXVlc3QgKHNlZSBTZWN0aW9uIDUpLg0KPg0KPklNUE9SVEFOVDog SSB0aGluayB3aGF0IEkgYW0gZ2V0dGluZyBoZXJlIGlzIHRoYXQgdGhlIHJlcXVlc3RfcGl2IGlz DQo+dXNlZCB0byB2ZXJpZnkgdGhhdCB0aGUgcmVxdWVzdCBhbmQgcmVzcG9uc2UgbWF0Y2guIEhv d2V2ZXIsIEkgZG8gbm90DQo+c2VlIHRoaXMgZXhwbGljaXRseSBzdGF0ZWQgYW55d2hlcmUsIGFu ZCBpdCdzIG5vdCBjbGVhciB0byBtZSBob3cgdGhlDQo+Y2xpZW50IGlzIHN1cHBvc2VkIHRvIHJl Y292ZXIgdGhlIHJlcXVlc3RfcGl2IGFuZCB0aGUgdGV4dCBpcyBwcmV0dHkNCj51bmNsZWFyIGhl cmU/IElzIHRoZSBleHRlcm5hbF9hYWQgY2FycmllZCBzb21ld2hlcmUgaW4gdGhlIG1lc3NhZ2U/ IEFtDQo+SSBzdXBwb3NlZCB0byByZWNvbnN0cnVjdCBpdCBmcm9tIHRoZSBtZXNzYWdlIGlkPw0K Pg0KPiAgIEZvciByZXNwb25zZXMsIHRoZSBtZXNzYWdlIGJpbmRpbmcgZ3VhcmFudGVlcyB0aGF0 IGEgcmVzcG9uc2UgaXMgbm90DQo+ICAgb2xkZXIgdGhhbiBpdHMgcmVxdWVzdC4gIEZvciByZXNw b25zZXMgd2l0aG91dCBPYnNlcnZlLCB0aGlzIGdpdmVzDQo+DQo+SU1QT1JUQU5UOiBJIGFtIG5v dCBzdXJlIHRoYXQgdGhpcyBpcyB0cnVlLiBXaGF0IGhhcHBlbnMgb2YgdGhlDQo+Y291bnRlcnBh cnR5IGxpZXM/IFdoYXQgaXMgeW91ciB0aHJlYXQgbW9kZWw/DQo+DQo+ICAgQW4gZXh0ZW5zaW9u IG9mIE9TQ09SRSBtYXkgYWxzbyBiZSB1c2VkIHRvIHByb3RlY3QgZ3JvdXANCj4gICBjb21tdW5p Y2F0aW9uIGZvciBDb0FQIFtJLUQudGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcF0uICBUaGUg dXNlDQo+ICAgb2YgT1NDT1JFIGRvZXMgbm90IGFmZmVjdCB0aGUgVVJJIHNjaGVtZSBhbmQgT1ND T1JFIGNhbiB0aGVyZWZvcmUgYmUNCj4gICB1c2VkIHdpdGggYW55IFVSSSBzY2hlbWUgZGVmaW5l ZCBmb3IgQ29BUCBvciBIVFRQLiAgVGhlIGFwcGxpY2F0aW9uDQo+ICAgZGVjaWRlcyB0aGUgY29u ZGl0aW9ucyBmb3Igd2hpY2ggT1NDT1JFIGlzIHJlcXVpcmVkLg0KPg0KPlRoaXMgaXMgcHJldHR5 IHN1cnByaXNpbmcgdG8ganVzdCBkcm9wIGluIGhlcmUuIE11bHRpY2FzdCBoYXMgdG90YWxseQ0K PmRpZmZlcmVudA0KPnNlY3VyaXR5IHByb3BlcnRpZXMgZnJvbSBub24tbXVsdGljYXN0Lg0KPg0K Pg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj5DT01NRU5UOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4NCj4NCj4g ICBidXQgaXMgYWxzbyBhYmxlIHRvIGVhdmVzZHJvcCBvbiwgb3IgbWFuaXB1bGF0ZSBhbnkgcGFy dCBvZiB0aGUNCj4gICBtZXNzYWdlIHBheWxvYWQgYW5kIG1ldGFkYXRhLCBpbiB0cmFuc2l0IGJl dHdlZW4gdGhlIGVuZHBvaW50cy4gIFRoZQ0KPiAgIHByb3h5IGNhbiBhbHNvIGluamVjdCwgZGVs ZXRlLCBvciByZW9yZGVyIHBhY2tldHMgc2luY2UgdGhleSBhcmUgbm8NCj5OaXQ6IHlvdSB3YW50 DQo+ImVhdmVzZHJvcCBvbiwgb3IgbWFuaXB1bGF0ZSBhbnkgcGFydCBvZiwgdGhlIG1lc3NhZ2Ug cGF5bG9hZCBhbmQNCj5tZXRhZGF0YSBpbg0KPnRyYW5zaXQiDQo+DQo+SS5lLiwgbW92ZSB0aGUg c2Vjb25kIGNvbW1hDQo+DQo+ICAgdGhlIGVuZHBvaW50cywgYW5kIHRob3NlIGFyZSB0aGVyZWZv cmUgcHJvY2Vzc2VkIGFzIGRlZmluZWQgaW4NCj4gICBbUkZDNzI1Ml0uICBBZGRpdGlvbmFsbHks IHNpbmNlIHRoZSBtZXNzYWdlIGZvcm1hdHMgZm9yIENvQVAgb3Zlcg0KPiAgIHVucmVsaWFibGUg dHJhbnNwb3J0IFtSRkM3MjUyXSBhbmQgZm9yIENvQVAgb3ZlciByZWxpYWJsZSB0cmFuc3BvcnQN Cj5OaXQ6ICJPU0NPUkUgcHJvdGVjdHMgbmVpdGhlciAuLi4uIG5vci4uLi4iDQo+DQo+ICAgICAg U2FsdC4gIExlbmd0aCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBBRUFEIEFsZ29yaXRobS4gIEl0cyB2 YWx1ZSBpcw0KPj4gICAgICBpbW11dGFibGUgb25jZSB0aGUgc2VjdXJpdHkgY29udGV4dCBpcyBl c3RhYmxpc2hlZC4NCj5OaXQ6IHlvdSBtaWdodCBqdXN0IHNheSBhYm92ZSBvciBiZWxvdyB0aGlz IGxpc3QgdGhhdCBhbGwgdGhlIHZhbHVlcyBhcmUNCj5pbW11dGFibGUsDQo+DQo+ICAgZGlmZmVy ZW50IG9wZXJhdGlvbnMuICBPbmUgbWVjaGFuaXNtIGVuYWJsaW5nIHRoaXMgaXMgc3BlY2lmaWVk IGluDQo+ICAgW0ktRC5pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZ10uDQo+SXMgdGhpcyBhIHNl Y3VyaXR5IGNvbmRpdGlvbj8NCj4NCj4gICAgICBvZiBbUkZDNzI1Ml0sIHdoZXJlIHRoZSBkZWx0 YSBpcyB0aGUgZGlmZmVyZW5jZSB0byB0aGUgcHJldmlvdXNseQ0KPiAgICAgIGluY2x1ZGVkIGNs YXNzIEkgb3B0aW9uLg0KPklzIHRoZSBkZWx0YSBoZXJlIHRoZSBwcmV2aW91c2x5IGluY2x1ZGVk IENsYXNzIEkgb3B0aW9uIG9yIHRoZSBwcmV2aW91c2x5DQo+aW5jbHVkZWQgaW5zdGFuY2Ugb2Yg dGhlIHNhbWUgb3B0aW9uLCBhcyBpdCBhcHBlYXJzIHRvIHNheSBpbiBTIDMuMS4NCj4NCj4gICAg ICAgICBjb21wcmVzc2VkIENPU0Ugb2JqZWN0LiAgVGhlIHZhbHVlcyBuID0gNiBhbmQgbiA9IDcg YXJlDQo+ICAgICAgICAgcmVzZXJ2ZWQuDQo+SG93IGNhbiBQYXJ0aWFsIElWIG5vdCBiZSBwcmVz ZW50PyBpdCdzIHRoZSBzZXF1ZW5jZSBudW1iZXIuIElzIHRoZQ0KPmFuc3dlciB0aGF0DQo+aXQg aXMgdGhlIDAgdmFsdWU/DQo+DQo+ICAgcmVzcG9uc2UuICBUaGUgc2VydmVyIHRoZXJlZm9yZSBu ZWVkcyB0byBzdG9yZSB0aGUga2lkIGFuZCBQYXJ0aWFsIElWDQo+ICAgb2YgdGhlIHJlcXVlc3Qg dW50aWwgYWxsIHJlc3BvbnNlcyBoYXZlIGJlZW4gc2VudC4NCj5JdCB3YXMgbXkgdW5kZXJzdGFu ZGluZyB0aGF0IHRoZSBraWQgd2FzIG5lZWRlZCB0byBsb29rIHVwIHRoZSBrZXkuIFdoeQ0KPmFy ZSBraWQNCj5zdWJzdGl0dXRpb24gYXR0YWNrcyBhbiBpc3N1ZT8NCj4NCj4gICBUaGUgbWF4aW11 bSBTZW5kZXIgU2VxdWVuY2UgTnVtYmVyIGlzIGFsZ29yaXRobSBkZXBlbmRlbnQgKHNlZQ0KPiAg IFNlY3Rpb24gMTEpLCBhbmQgbm8gZ3JlYXRlciB0aGFuIDJeNDAgLSAxLiAgSWYgdGhlIFNlbmRl ciBTZXF1ZW5jZQ0KPiAgIE51bWJlciBleGNlZWRzIHRoZSBtYXhpbXVtLCB0aGUgZW5kcG9pbnQg TVVTVCBOT1QgcHJvY2VzcyBhbnkgbW9yZQ0KPklmIHlvdSB0YWtlIG15IHN1Z2dlc3Rpb24gYWJv dXQgcmVtb3Zpbmcgc2VuZGVySUQgZnJvbSB0aGUgbm9uY2UgeW91IHdpbGwNCj5iZQ0KPmFibGUg dG8gcmVsYXggdGhpcy4NCj4NCj4gICBBZnRlciBib290LCBhbiBlbmRwb2ludCBNQVkgcmVqZWN0 IHRvIHVzZSBleGlzdGluZyBzZWN1cml0eSBjb250ZXh0cw0KPiAgIGZyb20gYmVmb3JlIGl0IGJv b3RlZCBhbmQgTUFZIGVzdGFibGlzaCBhIG5ldyBzZWN1cml0eSBjb250ZXh0IHdpdGgNCj5OaXQ6 IHRoaXMgaXMgdW5ncmFtbWF0aWNhbA0KPg0KPiAgICAgICBpbmNsdWRlZCBpbiB0aGUgbWVzc2Fn ZS4gIElmIHRoZSBBRUFEIG5vbmNlIGZyb20gdGhlIHJlcXVlc3Qgd2FzDQo+ICAgICAgIHVzZWQs IHRoZSBQYXJ0aWFsIElWIE1VU1QgTk9UIGJlIGluY2x1ZGVkIGluIHRoZSBtZXNzYWdlLg0KPklN UE9SVEFOVDogWW91IGFyZSBub3cgdmlvbGF0aW5nIHRoZSBpbnZhcmlhbnQgb2YgdXNpbmcgdGhl IHNhbWUgbm9uY2UNCj50d2ljZS4NCj5UaGF0J3MgZmluZSBpbiB0aGlzIGNhc2UsIGJlY2F1c2Ug eW91IGhhdmUgcGVyLXNlbmRlciBrZXlzIGJ1dCBpdA0KPmRlbW9uc3RyYXRlcw0KPnRoYXQgaXQg aXMgdW5uZWNlc3NhcnkgdG8gZW5jb2RlIHRoZSBzZW5kZXJfaWQgaW4gdGhlIG5vbmNlIGZpZWxk Lg0KPg0KPiAgIFNlY3VyaXR5IGxldmVsIGhlcmUgbWVhbnMgdGhhdCBhbiBhdHRhY2tlciBjYW4g cmVjb3ZlciBvbmUgb2YgdGhlIG0NCj4gICBrZXlzIHdpdGggY29tcGxleGl0eSAyXihrICsgbikg LyBtLiAgUHJvdGVjdGlvbiBhZ2FpbnN0IHN1Y2ggYXR0YWNrcw0KPiAgIGNhbiBiZSBwcm92aWRl ZCBieSBpbmNyZWFzaW5nIHRoZSBzaXplIG9mIHRoZSBrZXlzIG9yIHRoZSBlbnRyb3B5IG9mDQo+ VGhpcyBwYXJhZ3JhcGggaXMgZXh0cmVtZWx5IGhhcmQgdG8gZm9sbG93IGJ1dCBJIGFtIG5vdCBw ZXJzdWFkZWQgdGhhdCBpdA0KPmlzDQo+Y29ycmVjdC4gRG8geW91IGhhdmUgYSBjaXRhdGlvbiBm b3IgdGhlIGNsYWltIHRoYXQgeW91IGNhbiBhZGQgdGhlIGtleQ0KPmVudHJvcHkNCj5hbmQgdGhl IG5vbmNlIGVudHJvcHkgbGlrZSB0aGlzLg0KPg0KPiAgIHN0eWxlIG9mIHBhZGRpbmcgbWVhbnMg dGhhdCBhbGwgdmFsdWVzIG5lZWQgdG8gYmUgcGFkZGVkLiAgU2ltaWxhcg0KPiAgIGFyZ3VtZW50 cyBhcHBseSB0byBvdGhlciBtZXNzYWdlIGZpZWxkcyBzdWNoIGFzIHJlc291cmNlIG5hbWVzLg0K PlRoZSBQS0NTIzcgcGFkZGluZyBzY2hlbWUgYXQgbWluaW11bSBoYXMgcG90ZW50aWFsIHRpbWlu ZyBjaGFubmVscw0KPg0KPiAgIFRoZSBzZXJ2ZXIgdmVyaWZpZXMgdGhhdCB0aGUgUGFydGlhbCBJ ViBoYXMgbm90IGJlZW4gcmVjZWl2ZWQgYmVmb3JlLg0KPiAgIFRoZSBjbGllbnQgdmVyaWZpZXMg dGhhdCB0aGUgcmVzcG9uc2UgaXMgYm91bmQgdG8gdGhlIHJlcXVlc3QuDQo+SG93IGRvZXMgdGhl IGNsaWVudCB2ZXJpZnkgdGhpcw0KPg0KPiAgICAgICBQYXJ0aWFsIElWIChpbiBuZXR3b3JrIGJ5 dGUgb3JkZXIpIHdpdGggemVyb2VzIHRvIGV4YWN0bHkgbm9uY2UNCj4gICAgICAgbGVuZ3RoIC0g NiBieXRlcywNCj4NCj5JTVBPUlRBTlQ6IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmVhc29uIGZv ciB0aGlzIGNvbnN0cnVjdGlvbi4gWW91DQo+YWxyZWFkeSByZXF1aXJlIHRoYXQgdGhlIGtleSBi ZSBkZXJpdmVkIHZpYSBIS0RGIGZyb20gdGhlIHxtYXN0ZXIga2V5fA0KPmFuZCB8c2VuZGVyIElE fCB0aGVyZWZvcmUsIGl0IGlzIG5vdCBuZWNlc3NhcmlseSB0byBzZXBhcmF0ZWx5IGVuY29kZQ0K PnRoZSBzZW5kZXIgSUQgaW4gdGhlIG5vbmNlLiBUaGlzIHdvdWxkIG9yZGluYXJpbHkgbm90IGJl IGEgbGFyZ2UNCj5pc3N1ZSwgYnV0IGFzIGl0IHJlcXVpcmVzIHZlcnkgZXh0cmVtZSByZXN0cmlj dGlvbnMgb24gdGhlIHNlbmRlciBJRA0KPihhbmQgZXNzZW50aWFsbHkgcHJlY2x1ZGVzIHJhbmRv bSBzZW5kZXIgSURzKSBJIGJlbGlldmUgaXQgaXMgd29ydGgNCj5jb25zaWRlcmluZyBjaGFuZ2lu ZywgYnV0IGl0J3MgdWx0aW1hdGVseSBhIFdHIGRlY2lzaW9uLCBoZW5jZSBub3QNCj5pbiBteSBk aXNjdXNzLg0KPg0KPg0KDQoNCg0KDQo= --_000_D6C73674A1630goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <2727267F899D604F98889FB03E44B537@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5IDggTWFyY2ggMjAxOCBh dCAxODowNTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkfD tnJhbiBTZWxhbmRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbSI+Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5UaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmciPmRyYWZ0LWll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZyI+ZHJhZnQtaWV0 Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzwvYT4mZ3Q7LA0KIENhcnN0ZW4gQm9ybWFu biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+Y2Fib0B0emkub3JnPC9hPiZndDss IEphaW1lIEppbcOpbmV6ICZsdDs8YSBocmVmPSJtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nv bi5jb20iPmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpjb3JlLWNoYWlyc0BpZXRmLm9yZyI+Y29yZS1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmciPmNvcmUtY2hhaXJz QGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmci PmNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogRXJpYyBSZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIE1hciA4LCAyMDE4IGF0IDg6MjQgQU0sIEfDtnJh biBTZWxhbmRlciA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNl bGFuZGVyQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdvcmFuLnNlbGFuZGVyQGVyaWNz c29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk O2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Im1fOTA0Njc2Mzk4MTcyMTYwOTM4N09MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjExcHQ7dGV4dC1hbGlnbjpsZWZ0O2NvbG9y OmJsYWNrO0JPUkRFUi1CT1RUT006bWVkaXVtIG5vbmU7Qk9SREVSLUxFRlQ6bWVkaXVtIG5vbmU7 UEFERElORy1CT1RUT006MGluO1BBRERJTkctTEVGVDowaW47UEFERElORy1SSUdIVDowaW47Qk9S REVSLVRPUDojYjVjNGRmIDFwdCBzb2xpZDtCT1JERVItUklHSFQ6bWVkaXVtIG5vbmU7UEFERElO Ry1UT1A6M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+ RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSA4IE1hcmNoIDIwMTggYXQgMTY6Mzk8c3BhbiBj bGFzcz0iIj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5H w7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nv bi5jb20iIHRhcmdldD0iX2JsYW5rIj5nb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPlRoZSBJRVNH ICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2dA aWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY29yZS1v YmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLWNvcmUt b2JqZWN0LTx3YnI+c2VjdXJpdHlAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmRyYWZ0LWlldGYtY29yZS1vYmplY3QtPHdicj5zZWN1cml0eUBpZXRmLm9yZzwvYT4mZ3Q7 LA0KIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7LCBKYWltZSBKaW3DqW5leiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ amFpbWUuamltZW5lekBlcmljc3Nvbi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OmNvcmUtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29yZS1jaGFpcnNAaWV0Zi5v cmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlLWNoYWlyc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmNvcmUtY2hhaXJzQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhy ZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogRXJpYyBSZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC08d2JyPnNlY3VyaXR5LTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKTxicj4NCjwvc3Bhbj48L2Rpdj4NCjxzcGFuIGNsYXNzPSIiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIGlkPSJtXzkwNDY3NjM5ODE3MjE2MDkzODdNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BB RERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gVGh1LCBNYXIgOCwgMjAxOCBhdCA3OjIzIEFNLCBHw7ZyYW4gU2VsYW5kZXIg PHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmlj c3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5nb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208L2E+ Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGlu Zy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2Io MCwwLDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJtXzkwNDY3NjM5 ODE3MjE2MDkzODdtXy0zODM2OTk0MDM2NzkxOTIwNzkwT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0ZXh0LWFsaWdu OmxlZnQ7Y29sb3I6YmxhY2s7Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JERVItTEVGVDpt ZWRpdW0gbm9uZTtQQURESU5HLUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQQURESU5HLVJJ R0hUOjBpbjtCT1JERVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdIVDptZWRpdW0g bm9uZTtQQURESU5HLVRPUDozcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZy b206IDwvc3Bhbj5FcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29t IiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5IDggTWFyY2ggMjAxOCBhdCAx NjowNjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkfDtnJh biBTZWxhbmRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+VGhlIElFU0cgJmx0 OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWVzZ0BpZXRm Lm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVj dC1zZWN1cml0eUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpPHdicj50eUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cmk8d2JyPnR5QGlldGYub3JnPC9hPiZndDssDQog Q2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9 Il9ibGFuayI+Y2Fib0B0emkub3JnPC9hPiZndDssIEphaW1lIEppbcOpbmV6ICZsdDs8YSBocmVm PSJtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5qYWlt ZS5qaW1lbmV6QGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y29y ZS1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3JlLWNoYWlyc0BpZXRmLm9yZzwv YT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+Y29yZS1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3JlQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5j b3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U3ViamVjdDogPC9zcGFuPlJlOiBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LWNvcmUtb2JqZWN0LXNlY3VyaXQ8d2JyPnktMDk6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQp PGJyPg0KPC9kaXY+DQo8c3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i bV85MDQ2NzYzOTgxNzIxNjA5Mzg3bV8tMzgzNjk5NDAzNjc5MTkyMDc5ME1BQ19PVVRMT09LX0FU VFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7 UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBUaHUsIE1hciA4LCAyMDE4IGF0IDY6NTkgQU0sIEfDtnJhbiBTZWxhbmRl ciA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVy aWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTwv YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij4NCkFub3RoZXIgcmVjdXJyaW5nIGNvbW1lbnQgaXMgdGhlIGltcGFjdCBv ZiBhIHByb3h5IGNoYW5naW5nIGNlcnRhaW4gQ29BUDxicj4NCm1lc3NhZ2UgZmllbGRzIGxpa2Ug ZS5nLiBNZXNzYWdlIElELCBUb2tlbiBvciBVcmktSG9zdC4gU2luY2UgQ29BUCBkZWZpbmVzPGJy Pg0KbGVnaXRpbWF0ZSBwcm94eSBvcGVyYXRpb25zLCB0aGVzZSBtZXNzYWdlIGZpZWxkcyBjYW5u b3QgYmUgaW50ZWdyaXR5PGJyPg0KcHJvdGVjdGVkIGVuZC10by1lbmQuIEN1cnJlbnQgc2VjdXJp dHkgc29sdXRpb25zIGVpdGhlciBkb2VzIG5vdCBhbGxvdzxicj4NCnByb3h5IG9wZXJhdGlvbnMg b3IgbGVhdmUgYWxsIG1lc3NhZ2UgZmllbGRzIHVucHJvdGVjdGVkIGluIHRoZSBwcm94eS4gV2U8 YnI+DQp3aWxsIHRyeSB0byBtYWtlIHRoaXMgbW9yZSBjbGVhci48YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcXVlc3Rpb24gaXMgd2hhdCB0aGUgc2VjdXJp dHkgaW1wYWN0IG9mIHRoZXNlIGlzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L3NwYW4+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5ZZXMsIGFuZCB3ZSB3aWxsIHRyeSB0byBhZGRyZXNzIHRoaXMuIEJ1dCBpdCBp cyBhIGdlbmVyYWwgcHJvcGVydHkgb2YgQ29BUCB3aGVuIHByb3hpZXMgYXJlIHVzZWQuPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlllcywgYnV0 IHRoZSB3aG9sZSBwb2ludCBvZiB0aGlzIGRlc2lnbiBpcyB0byBwcm90ZWN0IHRvIHNvbWUgZXh0 ZW50IGFnYWluc3QgbWFsaWNpb3VzIHByb3hpZXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvc3Bhbj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlllcywgYnV0IG5vdCBhZ2FpbnN0IHByb3h5IG9wZXJhdGlvbnMg d2hpY2ggYXJlIGRlZmluZWQgYXMgbGVnaXRpbWF0ZSBieSBDb0FQIGFuZC9vciB3aGVyZSB0aGVy ZSBhcmUgb3RoZXIgbWVhbnMgdG8gdmVyaWZ5IHRoZSBvcGVyYXRpb24uPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoZXRoZXIgdGhlc2Ugb3Bl cmF0aW9ucyBhcmUgaW4gZmFjdCBzYWZlIGlzIHRoZSBxdWVzdGlvbiBhdCBoYW5kLiBJIHdpbGwg d2FpdCBmb3IgeW91ciBkZXRhaWxlZCBhbmFseXNpcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5NZWFud2hpbGUsIHBlb3BsZSBpbnRlcmVzdGVkIGluIHRoZSBwcm9ibGVt IHN0YXRlbWVudCBjYW4gcmVhZCB0aGlzOjwvZGl2Pg0KPGRpdj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJlcXMtMDM8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkfDtnJhbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tRWtyPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQt c2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0i Ij48c3BhbiBpZD0ibV85MDQ2NzYzOTgxNzIxNjA5Mzg3T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGJsb2NrcXVvdGUgaWQ9Im1fOTA0Njc2Mzk4MTcyMTYwOTM4N01BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7UEFERElO RzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv cmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWYiPg0KPHNwYW4+PHNwYW4gaWQ9Im1fOTA0Njc2Mzk4MTcyMTYwOTM4N21fLTM4MzY5 OTQwMzY3OTE5MjA3OTBPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0ibV85 MDQ2NzYzOTgxNzIxNjA5Mzg3bV8tMzgzNjk5NDAzNjc5MTkyMDc5ME1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7UEFE RElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkEgdGhpcmQg dGhpbmcgaW4gRXJpY+KAmXMgcmV2aWV3IGlzIHRoZSBjb25zdHJ1Y3Rpb24gb2YgdGhlIG5vbmNl IHdoZXJlIHRoZTxicj4NCklEIGlzIGluY2x1ZGVkLiBUaGUgcmVhc29uIGZvciB0aGlzIGlzIHRv IGhhbmRsZSBlbmRwb2ludHMgc3dpdGNoaW5nIHJvbGVzPGJyPg0KKENvQVAgY2xpZW50ICZsdDst Jmd0OyBDb0FQIHNlcnZlcikmbmJzcDsgd2hpY2ggaXMgc3VwcG9ydGVkIGJ5IENvQVAsIGFuZCBp bjxicj4NCnBhcnRpY3VsYXI8YnI+DQpncm91cCBjb21tdW5pY2F0aW9ucyB3aXRoIG9uZSBzZW5k ZXIgYW5kIG11bHRpcGxlIHJlY2lwaWVudHM8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5JIGRvbid0IHNlZSBob3cgdGhhdCBpcyByZWxldmFudCwgZ2l2ZW4gdGhhdCB5b3Ug YWxyZWFkeSBoYXZlIGtleSBzZXBhcmF0aW9uPC9kaXY+DQo8ZGl2PmZvciB0aGUgc2VuZGVyIGtl eSwgd2hhdCBzZXBhcmF0ZSBpbmZvcm1hdGlvbiBpcyB0aGVyZSBpbiB0aGUgbm9uY2U/PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+VGhlIHNlbmRlciBrZXkg aXMgdXNlZCBib3RoIGluIHRoZSByb2xlIG9mIGNsaWVudCBtYWtpbmcgYSByZXF1ZXN0ICh3aXRo IG93biBwYXJ0aWFsIElWKSBhbmQgaW4gdGhlIHJvbGUgb2Ygc2VydmVyIHJlc3BvbmRpbmcgdG8g YSByZXF1ZXN0ICh3aXRoIHRoZSBvdGhlciBlbmRwb2ludOKAmXMgcGFydGlhbCBJVikuPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgc2Vl bXMgZXh0cmVtZWx5IGhhcmQgdG8gYW5hbHl6ZS4gWW91IHNob3VsZCBqdXN0IHVzZSBzZXBhcmF0 ZSBrZXlzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PlRo YXQgaXMgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gd2hpY2ggaXMgbGVzcyBvcHRpbWlzZWQgZS5n LiBpbiB0ZXJtcyBvZiBzaXplIG9mIGdyb3VwIGNvbW11bmljYXRpb24gc2VjdXJpdHkgY29udGV4 dC4gTGV0IHVzIGNvbWUgYmFjayBvbiB0aGF0LjwvZGl2Pg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+ PGZvbnQgY29sb3I9IiM4ODg4ODgiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+R8O2cmFuPC9k aXY+DQo8L2ZvbnQ+PC9zcGFuPg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0ibV85MDQ2NzYzOTgxNzIxNjA5Mzg3T0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGJsb2NrcXVvdGUgaWQ9Im1fOTA0Njc2Mzk4MTcyMTYwOTM4N01BQ19PVVRMT09LX0FU VFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7 UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tRWtyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4 O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0ibV85MDQ2NzYz OTgxNzIxNjA5Mzg3SE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5Hw7ZyYW48L2Rpdj4NCjwvZm9udD48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBjbGFz cz0ibV85MDQ2NzYzOTgxNzIxNjA5Mzg3aDUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJtXzkwNDY3NjM5ODE3MjE2MDkzODdtXy0zODM2OTk0MDM2NzkxOTIwNzkwT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Im1fOTA0Njc2Mzk4MTcyMTYwOTM4N21fLTM4MzY5 OTQwMzY3OTE5MjA3OTBNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i Qk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BBRERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAg NSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ LUVrcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCi4gV2hpbGUgdGhlPGJyPg0K bGF0dGVyIGlzIHRoZSB0b3BpYyBvZiBhIHNlcGFyYXRlIGRyYWZ0PGJyPg0KKGRyYWZ0LXRpbG9j YS1jb3JlLW11bHRpY2FzdC1vPHdicj5zY29hcCkgYW5kIHRoZSBwcm9wZXJ0aWVzIGluIHRoYXQg c2V0dGluZyBpczxicj4NCm91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0LCB3ZSB3aWxsIGFkZCBt b3JlIGV4cGxhbmF0aW9uIHRvIHRoZSBzZWN1cml0eTxicj4NCmRlc2lnbiBhbmQgdGhlIHVuaWNh c3Qgc2VjdXJpdHkgcHJvcGVydGllcyBpbiBnZW5lcmFsIHRvIHRoaXMgZHJhZnQuPGJyPg0KPGJy Pg0KPGJyPg0KTW9yZSBsYXRlci48YnI+DQo8c3BhbiBjbGFzcz0ibV85MDQ2NzYzOTgxNzIxNjA5 Mzg3bV8tMzgzNjk5NDAzNjc5MTkyMDc5MEhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxi cj4NCkfDtnJhbjxicj4NCjwvZm9udD48L3NwYW4+DQo8ZGl2IGNsYXNzPSJtXzkwNDY3NjM5ODE3 MjE2MDkzODdtXy0zODM2OTk0MDM2NzkxOTIwNzkwSE9FblpiIj4NCjxkaXYgY2xhc3M9Im1fOTA0 Njc2Mzk4MTcyMTYwOTM4N21fLTM4MzY5OTQwMzY3OTE5MjA3OTBoNSI+PGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KT24gMjAxOC0wMy0wOCAwMzo1OCwgJnF1b3Q7RXJpYyBSZXNjb3JsYSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZt LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDtFcmljIFJlc2NvcmxhIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCiZndDtkcmFmdC1pZXRm LWNvcmUtb2JqZWN0LXNlY3VyaTx3YnI+dHktMDk6IERpc2N1c3M8YnI+DQomZ3Q7PGJyPg0KJmd0 O1doZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbDxicj4NCiZndDtlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxicj4NCiZndDtpbnRyb2R1Y3Rv cnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtQbGVh c2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdDx3YnI+ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sPC9hPjxicj4NCiZndDtmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O1Ro ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZTo8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS8iIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdicj5kb2MvZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWM8d2JyPnVyaXR5LzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS08YnI+DQomZ3Q7RElTQ1VT Uzo8YnI+DQomZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxh IGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0QzMDc1IiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21venBoYWItaWV0Zi5kZXZz dmNkZTx3YnI+di5tb3phd3MubmV0L0QzMDc1PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7RElTQ1VT Uzxicj4NCiZndDtNeSBvdmVyYWxsIGNvbmNlcm4gd2l0aCB0aGlzIGRvY3VtZW50IGlzIHRoYXQg SSBhbSB1bmFibGUgdG8gZXZhbHVhdGU8YnI+DQomZ3Q7dGhlIHNlY3VyaXR5IHByb3BlcnRpZXMg b2YgdGhlIHN5c3RlbS4gSSBoYXZlIGRlc2NyaWJlZCBhIG51bWJlciBvZjxicj4NCiZndDtpc3N1 ZXMgYmVsb3csIGJ1dCB0aGUgYmFzaWMgcHJvYmxlbSBpcyB0aGF0IHRoaXMgc29ydCBvZiBwYXJ0 aWFsPGJyPg0KJmd0O3Byb3RlY3Rpb24gaXMgZXh0cmVtZWx5IGhhcmQgdG8gcmVhc29uIGFib3V0 IGFuZCB0aGUgc2VjdXJpdHk8YnI+DQomZ3Q7Y29uc2lkZXJhdGlvbnMgZG8gbm90IGRvIGFuIGFk ZXF1YXRlIGpvYiBvZiBldmFsdWF0aW5nIHRoZSBpbXBhY3Qgb2Y8YnI+DQomZ3Q7cHJveGllcyBt b2RpZnlpbmcgdGhlc2UgdmFsdWVzLiBJIGFtIHNpbWlsYXJseSBjb25jZXJuZWQgYWJvdXQgdGhl PGJyPg0KJmd0O0hUVFAgbWFwcGluZyBhbmQgbGluayBzZWN0aW9uIHdoaWNoIHNlZW1zIGV4dHJl bWVseSBza2V0Y2h5IGFuZCBoYXM8YnI+DQomZ3Q7ZXNzZW50aWFsbHkgbm8gc2VjdXJpdHkgYW5h bHlzaXMsIGFuZCB5ZXQgcG90ZW50aWFsbHkgaGF2ZSBhIGxvdDxicj4NCiZndDtvZiBsYW5kbWlu ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDtBdCBtaW5pbXVtLCB0aGlzIGRvY3VtZW50IG5lZWRzIHRv IHdhbGsgdGhyb3VnaCB0aGUgaW1wbGljYXRpb25zPGJyPg0KJmd0O29mIG1vZGlmaWNhdGlvbnMg YnkgdGhlIHByb3h5IHRvIGV2ZXJ5IHVucHJvdGVjdGVkIGZpZWxkIGluPGJyPg0KJmd0O3RoZSBw dXJlIENvQVAgY29udGV4dCBhcyB3ZWxsIGFzIHRoZSBIVFRQIGNvbnRleHQgKGlmIHlvdSB3YW50 PGJyPg0KJmd0O3RvIHJldGFpbiB0aGF0IGJpbmRpbmcpLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO2FyZSBnaXZlbiBpbiBBcHBlbmRpeCBBLiZuYnNwOyBPU0NPUkUgZG9lcyBub3Qg ZGVwZW5kIG9uIHVuZGVybHlpbmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2xheWVycywgYW5kIGNh biBiZSB1c2VkIGFueXdoZXJlIHdoZXJlIENvQVAgb3IgSFRUUCBjYW4gYmUgdXNlZCw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwO2luY2x1ZGluZyBub24tSVAgdHJhbnNwb3J0cyAoZS5nLiwgW0ktRC5i b3JtYW5uLTZsby1jb2FwLTgwMi0xNS1pPHdicj5lXSkuPGJyPg0KJmd0Ozxicj4NCiZndDtJTVBP UlRBTlQ6IFRoaXMgZG9jdW1lbnQgY2xhaW1zIHRvIGJlIGFwcGxpY2FibGUgdG8gcHJvdG9jb2xz IG90aGVyPGJyPg0KJmd0O3RoYW4gQ09BUCwgaW4gcGFydGljdWxhciBIVFRQLiBIYXMgdGhpcyBi ZWVuIHJldmlld2VkIGJ5IHRoZSBIVFRQPGJyPg0KJmd0O3dvcmtpbmcgZ3JvdXA/IE1hcnRpbiBU aG9tc29uJ3MgcmV2aWV3IHN1Z2dlc3RzIHRoYXQgdGhpcyBpcyBvdXQgb2Y8YnI+DQomZ3Q7c3Rl cCB3aXRoIEhUVFAgcHJhY3RpY2UuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7SURz IE1VU1QgYmUgbG9uZyB1bmlmb3JtbHkgcmFuZG9tIGRpc3RyaWJ1dGVkIGJ5dGUgc3RyaW5ncyBz dWNoIHRoYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3RoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNp b25zIGlzIG5lZ2xpZ2libGUuPGJyPg0KJmd0Ozxicj4NCiZndDtJTVBPUlRBTlQ6IEkgZG9uJ3Qg dW5kZXJzdGFuZCBob3cgdGhpcyBwYXJhZ3JhcGggYW5kIHRoZSBwcmV2aW91czxicj4NCiZndDtw YXJhZ3JhcGggaW50ZXJhY3QuIFlvdSBzYXkgdGhhdCB0aGUgbWF4aW11bSBsZW5ndGggaXMgNyBv Y3RldHMgaW4gdGhlPGJyPg0KJmd0O3ByZXZpb3VzIHBhcmFncmFwaCwgd2hpY2ggSSBkb24ndCB0 aGluayBxdWFsaWZpZXMgYXMgJnF1b3Q7bG9uZyZxdW90Oy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOzEgfCBJZi1NYXRjaCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8IHggfCZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8Jm5ic3A7ICZuYnNwOzMgfCBVcmktSG9zdCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8Jm5ic3A7ICZuYnNwO3wgeCB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7 ICZuYnNwOzQgfCBFVGFnJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCB4IHwmbmJzcDsgJm5ic3A7fDxicj4NCiZndDtJTVBPUlRBTlQ6IFdoeSBkbyB5b3UgdGhpbmsg dGhhdCBpdCdzIG5vdCBpbXBvcnRhbnQgdG8gaGF2ZSBpbnRlZ3JpdHk8YnI+DQomZ3Q7cHJvdGVj dGlvbiBmb3IgVXJpLUhvc3QgYW5kIFVyaS1wb3J0Pzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwO091dGVyIG9wdGlvbiBtZXNzYWdlIGZpZWxkcyAoQ2xhc3MgVSBvciBJKSBhcmUgdXNl ZCB0byBzdXBwb3J0IHByb3h5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtvcGVyYXRpb25zLjxicj4N CiZndDtJTVBPUlRBTlQ6IFRoaXMgc2VlbXMgcHJvYmxlbWF0aWMgYmVjYXVzZSB0aGUgcHJveHkg Y2Fubm90IHZlcmlmeSBjbGFzcyBJPGJyPg0KJmd0O2ZpZWxkcy48YnI+DQomZ3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDtsYXllciBvbmx5LCBhbmQgbm90IHRoZSBNZXNzYWdpbmcgTGF5ZXIgKFNl Y3Rpb24gMiBvZiBbUkZDNzI1Ml0pLCBzbzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ZmllbGRzIHN1 Y2ggYXMgVHlwZSBhbmQgTWVzc2FnZSBJRCBhcmUgbm90IHByb3RlY3RlZCB3aXRoIE9TQ09SRS48 YnI+DQomZ3Q7PGJyPg0KJmd0O0lNUE9SVEFOVDogVGhpcyBzZWVtcyBleHRyZW1lbHkgaGFyZCB0 byByZWFzb24gYWJvdXQuIFdoYXQgYXJlIHRoZTxicj4NCiZndDtpbXBsaWNhdGlvbnMgb2YgdGhl IHByb3h5IGJlaW5nIGFibGUgdG8gY2hhbmdlIHRoZXNlPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO28mbmJzcDsgcmVxdWVzdF9waXY6IGNvbnRhaW5zIHRoZSB2YWx1ZSBvZiB0aGUg J1BhcnRpYWwgSVYnIGluIHRoZSBDT1NFPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IG9i amVjdCBvZiB0aGUgcmVxdWVzdCAoc2VlIFNlY3Rpb24gNSkuPGJyPg0KJmd0Ozxicj4NCiZndDtJ TVBPUlRBTlQ6IEkgdGhpbmsgd2hhdCBJIGFtIGdldHRpbmcgaGVyZSBpcyB0aGF0IHRoZSByZXF1 ZXN0X3BpdiBpczxicj4NCiZndDt1c2VkIHRvIHZlcmlmeSB0aGF0IHRoZSByZXF1ZXN0IGFuZCBy ZXNwb25zZSBtYXRjaC4gSG93ZXZlciwgSSBkbyBub3Q8YnI+DQomZ3Q7c2VlIHRoaXMgZXhwbGlj aXRseSBzdGF0ZWQgYW55d2hlcmUsIGFuZCBpdCdzIG5vdCBjbGVhciB0byBtZSBob3cgdGhlPGJy Pg0KJmd0O2NsaWVudCBpcyBzdXBwb3NlZCB0byByZWNvdmVyIHRoZSByZXF1ZXN0X3BpdiBhbmQg dGhlIHRleHQgaXMgcHJldHR5PGJyPg0KJmd0O3VuY2xlYXIgaGVyZT8gSXMgdGhlIGV4dGVybmFs X2FhZCBjYXJyaWVkIHNvbWV3aGVyZSBpbiB0aGUgbWVzc2FnZT8gQW08YnI+DQomZ3Q7SSBzdXBw b3NlZCB0byByZWNvbnN0cnVjdCBpdCBmcm9tIHRoZSBtZXNzYWdlIGlkPzxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwO0ZvciByZXNwb25zZXMsIHRoZSBtZXNzYWdlIGJpbmRpbmcgZ3Vh cmFudGVlcyB0aGF0IGEgcmVzcG9uc2UgaXMgbm90PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtvbGRl ciB0aGFuIGl0cyByZXF1ZXN0LiZuYnNwOyBGb3IgcmVzcG9uc2VzIHdpdGhvdXQgT2JzZXJ2ZSwg dGhpcyBnaXZlczxicj4NCiZndDs8YnI+DQomZ3Q7SU1QT1JUQU5UOiBJIGFtIG5vdCBzdXJlIHRo YXQgdGhpcyBpcyB0cnVlLiBXaGF0IGhhcHBlbnMgb2YgdGhlPGJyPg0KJmd0O2NvdW50ZXJwYXJ0 eSBsaWVzPyBXaGF0IGlzIHlvdXIgdGhyZWF0IG1vZGVsPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO0FuIGV4dGVuc2lvbiBvZiBPU0NPUkUgbWF5IGFsc28gYmUgdXNlZCB0byBwcm90 ZWN0IGdyb3VwPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtjb21tdW5pY2F0aW9uIGZvciBDb0FQIFtJ LUQudGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zYzx3YnI+b2FwXS4mbmJzcDsgVGhlIHVzZTxicj4N CiZndDsmbmJzcDsgJm5ic3A7b2YgT1NDT1JFIGRvZXMgbm90IGFmZmVjdCB0aGUgVVJJIHNjaGVt ZSBhbmQgT1NDT1JFIGNhbiB0aGVyZWZvcmUgYmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3VzZWQg d2l0aCBhbnkgVVJJIHNjaGVtZSBkZWZpbmVkIGZvciBDb0FQIG9yIEhUVFAuJm5ic3A7IFRoZSBh cHBsaWNhdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ZGVjaWRlcyB0aGUgY29uZGl0aW9ucyBm b3Igd2hpY2ggT1NDT1JFIGlzIHJlcXVpcmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhpcyBpcyBw cmV0dHkgc3VycHJpc2luZyB0byBqdXN0IGRyb3AgaW4gaGVyZS4gTXVsdGljYXN0IGhhcyB0b3Rh bGx5PGJyPg0KJmd0O2RpZmZlcmVudDxicj4NCiZndDtzZWN1cml0eSBwcm9wZXJ0aWVzIGZyb20g bm9uLW11bHRpY2FzdC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4t LS0tLS0tLS0tLTxicj4NCiZndDtDT01NRU5UOjxicj4NCiZndDstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0t LS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 YnV0IGlzIGFsc28gYWJsZSB0byBlYXZlc2Ryb3Agb24sIG9yIG1hbmlwdWxhdGUgYW55IHBhcnQg b2YgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDttZXNzYWdlIHBheWxvYWQgYW5kIG1ldGFkYXRh LCBpbiB0cmFuc2l0IGJldHdlZW4gdGhlIGVuZHBvaW50cy4mbmJzcDsgVGhlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDtwcm94eSBjYW4gYWxzbyBpbmplY3QsIGRlbGV0ZSwgb3IgcmVvcmRlciBwYWNr ZXRzIHNpbmNlIHRoZXkgYXJlIG5vPGJyPg0KJmd0O05pdDogeW91IHdhbnQ8YnI+DQomZ3Q7JnF1 b3Q7ZWF2ZXNkcm9wIG9uLCBvciBtYW5pcHVsYXRlIGFueSBwYXJ0IG9mLCB0aGUgbWVzc2FnZSBw YXlsb2FkIGFuZDxicj4NCiZndDttZXRhZGF0YSBpbjxicj4NCiZndDt0cmFuc2l0JnF1b3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDtJLmUuLCBtb3ZlIHRoZSBzZWNvbmQgY29tbWE8YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDt0aGUgZW5kcG9pbnRzLCBhbmQgdGhvc2UgYXJlIHRoZXJlZm9y ZSBwcm9jZXNzZWQgYXMgZGVmaW5lZCBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7W1JGQzcyNTJd LiZuYnNwOyBBZGRpdGlvbmFsbHksIHNpbmNlIHRoZSBtZXNzYWdlIGZvcm1hdHMgZm9yIENvQVAg b3Zlcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7dW5yZWxpYWJsZSB0cmFuc3BvcnQgW1JGQzcyNTJd IGFuZCBmb3IgQ29BUCBvdmVyIHJlbGlhYmxlIHRyYW5zcG9ydDxicj4NCiZndDtOaXQ6ICZxdW90 O09TQ09SRSBwcm90ZWN0cyBuZWl0aGVyIC4uLi4gbm9yLi4uLiZxdW90Ozxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU2FsdC4mbmJzcDsgTGVuZ3RoIGlzIGRldGVybWlu ZWQgYnkgdGhlIEFFQUQgQWxnb3JpdGhtLiZuYnNwOyBJdHMgdmFsdWUgaXM8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGltbXV0YWJsZSBvbmNlIHRoZSBzZWN1cml0eSBjb250ZXh0 IGlzIGVzdGFibGlzaGVkLjxicj4NCiZndDtOaXQ6IHlvdSBtaWdodCBqdXN0IHNheSBhYm92ZSBv ciBiZWxvdyB0aGlzIGxpc3QgdGhhdCBhbGwgdGhlIHZhbHVlcyBhcmU8YnI+DQomZ3Q7aW1tdXRh YmxlLDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2RpZmZlcmVudCBvcGVyYXRpb25z LiZuYnNwOyBPbmUgbWVjaGFuaXNtIGVuYWJsaW5nIHRoaXMgaXMgc3BlY2lmaWVkIGluPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDtbSS1ELmlldGYtY29yZS1lY2hvLXJlcXVlc3QtdDx3YnI+YWddLjxi cj4NCiZndDtJcyB0aGlzIGEgc2VjdXJpdHkgY29uZGl0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgb2YgW1JGQzcyNTJdLCB3aGVyZSB0aGUgZGVsdGEgaXMgdGhl IGRpZmZlcmVuY2UgdG8gdGhlIHByZXZpb3VzbHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgaW5jbHVkZWQgY2xhc3MgSSBvcHRpb24uPGJyPg0KJmd0O0lzIHRoZSBkZWx0YSBoZXJlIHRo ZSBwcmV2aW91c2x5IGluY2x1ZGVkIENsYXNzIEkgb3B0aW9uIG9yIHRoZSBwcmV2aW91c2x5PGJy Pg0KJmd0O2luY2x1ZGVkIGluc3RhbmNlIG9mIHRoZSBzYW1lIG9wdGlvbiwgYXMgaXQgYXBwZWFy cyB0byBzYXkgaW4gUyAzLjEuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Y29tcHJlc3NlZCBDT1NFIG9iamVjdC4mbmJzcDsgVGhlIHZhbHVlcyBu ID0gNiBhbmQgbiA9IDcgYXJlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtyZXNlcnZlZC48YnI+DQomZ3Q7SG93IGNhbiBQYXJ0aWFsIElWIG5vdCBiZSBwcmVzZW50 PyBpdCdzIHRoZSBzZXF1ZW5jZSBudW1iZXIuIElzIHRoZTxicj4NCiZndDthbnN3ZXIgdGhhdDxi cj4NCiZndDtpdCBpcyB0aGUgMCB2YWx1ZT88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDtyZXNwb25zZS4mbmJzcDsgVGhlIHNlcnZlciB0aGVyZWZvcmUgbmVlZHMgdG8gc3RvcmUgdGhl IGtpZCBhbmQgUGFydGlhbCBJVjxicj4NCiZndDsmbmJzcDsgJm5ic3A7b2YgdGhlIHJlcXVlc3Qg dW50aWwgYWxsIHJlc3BvbnNlcyBoYXZlIGJlZW4gc2VudC48YnI+DQomZ3Q7SXQgd2FzIG15IHVu ZGVyc3RhbmRpbmcgdGhhdCB0aGUga2lkIHdhcyBuZWVkZWQgdG8gbG9vayB1cCB0aGUga2V5LiBX aHk8YnI+DQomZ3Q7YXJlIGtpZDxicj4NCiZndDtzdWJzdGl0dXRpb24gYXR0YWNrcyBhbiBpc3N1 ZT88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtUaGUgbWF4aW11bSBTZW5kZXIgU2Vx dWVuY2UgTnVtYmVyIGlzIGFsZ29yaXRobSBkZXBlbmRlbnQgKHNlZTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7U2VjdGlvbiAxMSksIGFuZCBubyBncmVhdGVyIHRoYW4gMl40MCAtIDEuJm5ic3A7IElm IHRoZSBTZW5kZXIgU2VxdWVuY2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO051bWJlciBleGNlZWRz IHRoZSBtYXhpbXVtLCB0aGUgZW5kcG9pbnQgTVVTVCBOT1QgcHJvY2VzcyBhbnkgbW9yZTxicj4N CiZndDtJZiB5b3UgdGFrZSBteSBzdWdnZXN0aW9uIGFib3V0IHJlbW92aW5nIHNlbmRlcklEIGZy b20gdGhlIG5vbmNlIHlvdSB3aWxsPGJyPg0KJmd0O2JlPGJyPg0KJmd0O2FibGUgdG8gcmVsYXgg dGhpcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtBZnRlciBib290LCBhbiBlbmRw b2ludCBNQVkgcmVqZWN0IHRvIHVzZSBleGlzdGluZyBzZWN1cml0eSBjb250ZXh0czxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ZnJvbSBiZWZvcmUgaXQgYm9vdGVkIGFuZCBNQVkgZXN0YWJsaXNoIGEg bmV3IHNlY3VyaXR5IGNvbnRleHQgd2l0aDxicj4NCiZndDtOaXQ6IHRoaXMgaXMgdW5ncmFtbWF0 aWNhbDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW5jbHVk ZWQgaW4gdGhlIG1lc3NhZ2UuJm5ic3A7IElmIHRoZSBBRUFEIG5vbmNlIGZyb20gdGhlIHJlcXVl c3Qgd2FzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZWQsIHRoZSBQYXJ0 aWFsIElWIE1VU1QgTk9UIGJlIGluY2x1ZGVkIGluIHRoZSBtZXNzYWdlLjxicj4NCiZndDtJTVBP UlRBTlQ6IFlvdSBhcmUgbm93IHZpb2xhdGluZyB0aGUgaW52YXJpYW50IG9mIHVzaW5nIHRoZSBz YW1lIG5vbmNlPGJyPg0KJmd0O3R3aWNlLjxicj4NCiZndDtUaGF0J3MgZmluZSBpbiB0aGlzIGNh c2UsIGJlY2F1c2UgeW91IGhhdmUgcGVyLXNlbmRlciBrZXlzIGJ1dCBpdDxicj4NCiZndDtkZW1v bnN0cmF0ZXM8YnI+DQomZ3Q7dGhhdCBpdCBpcyB1bm5lY2Vzc2FyeSB0byBlbmNvZGUgdGhlIHNl bmRlcl9pZCBpbiB0aGUgbm9uY2UgZmllbGQuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7U2VjdXJpdHkgbGV2ZWwgaGVyZSBtZWFucyB0aGF0IGFuIGF0dGFja2VyIGNhbiByZWNvdmVy IG9uZSBvZiB0aGUgbTxicj4NCiZndDsmbmJzcDsgJm5ic3A7a2V5cyB3aXRoIGNvbXBsZXhpdHkg Ml4oayAmIzQzOyBuKSAvIG0uJm5ic3A7IFByb3RlY3Rpb24gYWdhaW5zdCBzdWNoIGF0dGFja3M8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2NhbiBiZSBwcm92aWRlZCBieSBpbmNyZWFzaW5nIHRoZSBz aXplIG9mIHRoZSBrZXlzIG9yIHRoZSBlbnRyb3B5IG9mPGJyPg0KJmd0O1RoaXMgcGFyYWdyYXBo IGlzIGV4dHJlbWVseSBoYXJkIHRvIGZvbGxvdyBidXQgSSBhbSBub3QgcGVyc3VhZGVkIHRoYXQg aXQ8YnI+DQomZ3Q7aXM8YnI+DQomZ3Q7Y29ycmVjdC4gRG8geW91IGhhdmUgYSBjaXRhdGlvbiBm b3IgdGhlIGNsYWltIHRoYXQgeW91IGNhbiBhZGQgdGhlIGtleTxicj4NCiZndDtlbnRyb3B5PGJy Pg0KJmd0O2FuZCB0aGUgbm9uY2UgZW50cm9weSBsaWtlIHRoaXMuPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7c3R5bGUgb2YgcGFkZGluZyBtZWFucyB0aGF0IGFsbCB2YWx1ZXMgbmVl ZCB0byBiZSBwYWRkZWQuJm5ic3A7IFNpbWlsYXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2FyZ3Vt ZW50cyBhcHBseSB0byBvdGhlciBtZXNzYWdlIGZpZWxkcyBzdWNoIGFzIHJlc291cmNlIG5hbWVz Ljxicj4NCiZndDtUaGUgUEtDUyM3IHBhZGRpbmcgc2NoZW1lIGF0IG1pbmltdW0gaGFzIHBvdGVu dGlhbCB0aW1pbmcgY2hhbm5lbHM8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtUaGUg c2VydmVyIHZlcmlmaWVzIHRoYXQgdGhlIFBhcnRpYWwgSVYgaGFzIG5vdCBiZWVuIHJlY2VpdmVk IGJlZm9yZS48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1RoZSBjbGllbnQgdmVyaWZpZXMgdGhhdCB0 aGUgcmVzcG9uc2UgaXMgYm91bmQgdG8gdGhlIHJlcXVlc3QuPGJyPg0KJmd0O0hvdyBkb2VzIHRo ZSBjbGllbnQgdmVyaWZ5IHRoaXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1BhcnRpYWwgSVYgKGluIG5ldHdvcmsgYnl0ZSBvcmRlcikgd2l0aCB6ZXJvZXMg dG8gZXhhY3RseSBub25jZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZW5n dGggLSA2IGJ5dGVzLDxicj4NCiZndDs8YnI+DQomZ3Q7SU1QT1JUQU5UOiBJIGRvbid0IHVuZGVy c3RhbmQgdGhlIHJlYXNvbiBmb3IgdGhpcyBjb25zdHJ1Y3Rpb24uIFlvdTxicj4NCiZndDthbHJl YWR5IHJlcXVpcmUgdGhhdCB0aGUga2V5IGJlIGRlcml2ZWQgdmlhIEhLREYgZnJvbSB0aGUgfG1h c3RlciBrZXl8PGJyPg0KJmd0O2FuZCB8c2VuZGVyIElEfCB0aGVyZWZvcmUsIGl0IGlzIG5vdCBu ZWNlc3NhcmlseSB0byBzZXBhcmF0ZWx5IGVuY29kZTxicj4NCiZndDt0aGUgc2VuZGVyIElEIGlu IHRoZSBub25jZS4gVGhpcyB3b3VsZCBvcmRpbmFyaWx5IG5vdCBiZSBhIGxhcmdlPGJyPg0KJmd0 O2lzc3VlLCBidXQgYXMgaXQgcmVxdWlyZXMgdmVyeSBleHRyZW1lIHJlc3RyaWN0aW9ucyBvbiB0 aGUgc2VuZGVyIElEPGJyPg0KJmd0OyhhbmQgZXNzZW50aWFsbHkgcHJlY2x1ZGVzIHJhbmRvbSBz ZW5kZXIgSURzKSBJIGJlbGlldmUgaXQgaXMgd29ydGg8YnI+DQomZ3Q7Y29uc2lkZXJpbmcgY2hh bmdpbmcsIGJ1dCBpdCdzIHVsdGltYXRlbHkgYSBXRyBkZWNpc2lvbiwgaGVuY2Ugbm90PGJyPg0K Jmd0O2luIG15IGRpc2N1c3MuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D6C73674A1630goranselanderericssoncom_-- From nobody Sun Mar 11 03:08:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4578A124D6C for ; Sun, 11 Mar 2018 03:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] 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 3Qs7h70X7y-G for ; Sun, 11 Mar 2018 03:08:45 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162C9124B0A for ; Sun, 11 Mar 2018 03:08:44 -0700 (PDT) Received: from mail-qk0-f171.google.com ([209.85.220.171]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1euxuE-0003sD-HS; Sun, 11 Mar 2018 11:08:42 +0100 Received: by mail-qk0-f171.google.com with SMTP id s188so8438464qkb.2 for ; Sun, 11 Mar 2018 03:08:42 -0700 (PDT) X-Gm-Message-State: AElRT7HLN1WKqzy08s1rtFY9v541EFPmQ4YoCXfSOjFKsw26/TibixnP vEJpsc/HdmGAEOXDBNEFTVbNEGL5ritTCHWHJ6k= X-Google-Smtp-Source: AG47ELttozE/t89ByCqQwhr0adGgtf3fCeAXGz8YlGBFJBY2btZU7krkgMelh8vX7pxGtbhZ8Q6zb8wKDeTtd1fi7Ho= X-Received: by 10.55.74.17 with SMTP id x17mr6208796qka.201.1520762921538; Sun, 11 Mar 2018 03:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.134.195 with HTTP; Sun, 11 Mar 2018 03:08:01 -0700 (PDT) In-Reply-To: <4B71C39D-7D53-4B86-8C96-2D7FE4A5DA00@ericsson.com> References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> <4B71C39D-7D53-4B86-8C96-2D7FE4A5DA00@ericsson.com> From: Klaus Hartke Date: Sun, 11 Mar 2018 11:08:01 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1520762925; 78e8df47; X-HE-SMSGID: 1euxuE-0003sD-HS Archived-At: Subject: Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Mar 2018 10:08:47 -0000 Ari Ker=C3=A4nen wrote: > I guess it depends on the use case and how much logic we would have in th= e client. For many cases just backing-off is probably enough. But for examp= le for a case where shooting measurement data at high speed is causing over= load but updating RD registration would be fine, making a difference betwee= n C and A&B could be useful. What about using 5.03 for C and 4.29 for A? It's perfectly fine that a server tells one client it's overloaded while continuing to serve other clients. Alternatively: Define a content-format that provides more detailed informat= ion. >> --> "A server MAY return a 4.29 (Too Many Requests) response if a CoAP >> client request messages more often than the server is capable or >> willing to handle." > > The SHOULD of course only applies to who ever has implemented this spec. Right. It therefore sounds a bit like: "You MAY implement the spec. If you decide to implement the spec, you SHOULD implement the spec." That's weird :-) >>> If a client receives the 4.29 Response Code from a CoAP server to a >>> request, it SHOULD NOT send the same request to the server before the >>> time indicated in the Max-Age option has passed. >> >> Not sure if this can be required. It's more like the client is >> encouraged to not retry before Max-Age expires. > > Do you mean it can't be required for implementations that don't understan= d the code or in general? In general, judging by the (lack of) use of KEYWORDS in [1] and [2]. Klaus [1] https://tools.ietf.org/html/rfc7252#section-5.9.3.4 [2] https://tools.ietf.org/html/rfc6585#section-4 From nobody Sun Mar 11 03:15:18 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987F3124B0A for ; Sun, 11 Mar 2018 03:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] 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 hVm2vkSA6Fe5 for ; Sun, 11 Mar 2018 03:15:16 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323871201FA for ; Sun, 11 Mar 2018 03:15:16 -0700 (PDT) Received: from mail-qk0-f180.google.com ([209.85.220.180]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1euy0Y-0002gR-HV; Sun, 11 Mar 2018 11:15:14 +0100 Received: by mail-qk0-f180.google.com with SMTP id s198so8438367qke.5 for ; Sun, 11 Mar 2018 03:15:14 -0700 (PDT) X-Gm-Message-State: AElRT7EnLJFgd597wqVkHsHSGzVHuN2XKO9ebartww2uske07UKj+Pd+ 4sHfdJGsWzIP07Ohd8rENq+JXzMX2a0EmnQWj/4= X-Google-Smtp-Source: AG47ELvKZpGbPTtTm0URoWsBpxw/e/5EUEW7EXwRdi1dhZI1oEg1KontZpPZYOwJfSLZlJqnqO6qD5VwFArufTWv+mc= X-Received: by 10.55.58.6 with SMTP id h6mr6504084qka.291.1520763313500; Sun, 11 Mar 2018 03:15:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.134.195 with HTTP; Sun, 11 Mar 2018 03:14:33 -0700 (PDT) In-Reply-To: <753934EB-16DB-4AD9-915E-1A9298FAA1A1@ericsson.com> References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> <2599BFCF-9A26-40BE-95E1-FBFF6B1ECDD4@gmail.com> <753934EB-16DB-4AD9-915E-1A9298FAA1A1@ericsson.com> From: Klaus Hartke Date: Sun, 11 Mar 2018 11:14:33 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1520763316; 6dee4959; X-HE-SMSGID: 1euy0Y-0002gR-HV Archived-At: Subject: Re: [core] "No Content" CoAP option (was Re: "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Mar 2018 10:15:17 -0000 Ari Ker=C3=A4nen wrote: > But the dual use of the "X" vs. "X pending" was a bit unclear in the draf= t now. Agreed; the wording in the draft has some room for improvement. >> We had that in the -01 version of the draft, but that didn't seem to >> gain traction, so we've switched to a new content-format to indicate >> this status. Would this work for pub/sub? > > Do you remember what was the reason for lack of traction? Not sure since I wasn't at IETF 100 where it was discussed. But there are some notes in the meeting minutes [1]. Klaus [1] https://datatracker.ietf.org/meeting/100/materials/minutes-100-core.md (search for "13:35") From nobody Mon Mar 12 00:48:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D279B1270A3 for ; Mon, 12 Mar 2018 00:48:31 -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, 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 62T2DqRGfon4 for ; Mon, 12 Mar 2018 00:48:29 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (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 8D1041270A0 for ; Mon, 12 Mar 2018 00:48:29 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud7.xs4all.net with ESMTPA id vIC2eFrBU8U07vIC2eXiWI; Mon, 12 Mar 2018 08:48:27 +0100 Received: from 2001:983:a264:1:5ddc:c088:1025:584f by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 12 Mar 2018 08:48:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 12 Mar 2018 08:48:26 +0100 From: peter van der Stok To: Klaus Hartke Cc: =?UTF-8?Q?Ari_Ker=C3=A4nen?= , core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <152025806136.14652.11784946748337213501.idtracker@ietfa.amsl.com> <225023B8-B663-482A-93E6-8DD054606A79@ericsson.com> <2599BFCF-9A26-40BE-95E1-FBFF6B1ECDD4@gmail.com> <753934EB-16DB-4AD9-915E-1A9298FAA1A1@ericsson.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfEGzkd7rTmaIw8VY2a103AMnQD38rfbMjWkth8eZyuynbGEsO7FcJxbVV9UnmmxQ0sjmQtis3wos3YfpVo9Tjw5R73RksFl3AdSn9vZRQmndZzcl9oxJ 9DWN0llHUtq08fZevASLK5RcaFYFzdHAaGXKQk5OZvYOK2GmQIJVXymouWXSnEC00CK2h4iYIcdEzKwURpwyBwvjlQiLcol943uRJM0qLB2HPfLIxmioA32N or2cZeB0RwqYz/P1+n+hYQ== Archived-At: Subject: Re: [core] "No Content" CoAP option (was Re: "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Mar 2018 07:48:32 -0000 > >>> We had that in the -01 version of the draft, but that didn't seem to >>> gain traction, so we've switched to a new content-format to indicate >>> this status. Would this work for pub/sub? >> >> Do you remember what was the reason for lack of traction? > > Not sure since I wasn't at IETF 100 where it was discussed. But there > are some notes in the meeting minutes [1]. > I was at ietf100, presenting the pending draft. In short, a new response code was not encouraged; so the suggested 2.06 was out. Response code 5.03 (service unavailable) was suggested by Carsten, but we are clearly not talking about an unavailable service: the service is available but slow......... Not seeing any other obvious response code, Klaus suggested the content-format option. Cheerio, peter From nobody Tue Mar 13 02:46:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245CB12D7FC for ; Tue, 13 Mar 2018 02:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Nw02CppGWNLd for ; Tue, 13 Mar 2018 02:46:39 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 5D5E212D72F for ; Tue, 13 Mar 2018 02:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520934396; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YBv9VpoPtoIpcjn5iNnwANfSOgdCw6I9M+QTK8rT22A=; b=EDcpHnHsulyq0M8mh0bBQmZ+qqdc5kXUG7GGLBSvwU/04Oc4ouxpVtyMGpjzXW25 qk6deLKg9UyC8DzbYxMp0tluA3DCJU924yhTBf8vd2WBE85+Kigor31ct0aajMA9 aIqBdrufe1QZ3ll1ELkSRiLazMGckTe00EoZ0+PbL+c=; X-AuditID: c1b4fb25-44ba69c000002d5f-e7-5aa79dfc76d4 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.E8.11615.CFD97AA5; Tue, 13 Mar 2018 10:46:36 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 10:46:35 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Esko Dijk , "core@ietf.org WG (core@ietf.org)" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRp?= =?utf-8?Q?loca-core-multicast-oscoap?= Thread-Index: AQHTZHxj03czjYXRo0S+1fPiVy/2UaMzOsHggI+LMgCAAj0qAIAJlEGA Date: Tue, 13 Mar 2018 09:46:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D6C5CECEA1342goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2J7uO6fucujDE6ulLLY93Y9s8WlZfMZ LVZ+ec3uwOyxZMlPJo8DB3YzeSxt2swUwBzFZZOSmpNZllqkb5fAlTGvaStbwetTLBWL/zxl a2A8s5uli5GTQ0LARGLb8unMXYxcHEIChxklfrxdwgLhLGGUmNA4nRWkik3AReJBwyMmEFtE IFpi/Yo/YHFmAVWJj4e3sYPYwgJ1EnfXH2WEqKmXmPvpMxuE7SaxbvULMJsFqH73u0Ng9bwC FhLXup+yQSybxCTRdnoXWBGnQIzExYOzwQYxCohJfD+1hglimbjErSfzmSDOFpBYsuc8M4Qt KvHy8T+wg0QF9CT29rSzQcSVJH5suMQC0Rsr8bK1mwVisaDEyZlPWCYwis5CMnYWkrJZSMpm MXIAxTUl1u/ShyhRlJjS/ZAdwtaQaJ0zlx2ixFqieYMdspIFjByrGEWLU4uTctONjPVSizKT i4vz8/TyUks2MQLj8+CW36o7GC+/cTzEKMDBqMTD2z5heZQQa2JZcWXuIUYJDmYlEV6zHqAQ b0piZVVqUX58UWlOavEhRmkOFiVx3jnC7VFCAumJJanZqakFqUUwWSYOTqkGRunVb9r2bRHS L3uqx7f68Od3DJG+Zs8+5x78dD8222LxnYoZoU/m7Fvce9yX9WGtnmrzr383vtms0ctj9p2d di57DeOmjxeF427cWfV5AUv3pvcGy6zu85TuF/yWyf36RNS7W/c9ehUk7Gp2zv94bMeRTRnR y4PfRTaGyB0RYnK/ann+47dw5SIlluKMREMt5qLiRADhD+NZywIAAA== Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-tilo?= =?utf-8?q?ca-core-multicast-oscoap?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Mar 2018 09:46:42 -0000 --_000_D6C5CECEA1342goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXNrbywNCg0KVGhhbmtzIGZvciBnb29kIGNvbW1lbnRzIQ0KDQpMZXTigJlzIHJlY2FwIHRo ZSBzZXR0aW5nOiBUaGUgc2VuZGVyIGFuZCByZWNpcGllbnQgb2YgYSBncm91cCBPU0NPUkUgbWVz c2FnZSBuZWVkcyB0byByZXRyaWV2ZS9kZXJpdmUgdGhlIHJpZ2h0IHNlY3VyaXR5IGNvbnRleHQg Zm9yIHNlbmRpbmcgYW5kIHJlY2VpdmluZyByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLCBhbmQgdGhl IGFtb3VudCBvZiBkYXRhIHNlbnQgZm9yIHRoaXMgcHVycG9zZSBzaG91bGQgYmUgYXMgc21hbGwg YXMgcG9zc2libGUuIFRoaXMgc2hvdWxkIGFwcGx5IHRvIGFsbCBwaGFzZXMgb2YgY29tbXVuaWNh dGlvbjsgZmlyc3QgdGltZSwgbm9ybWFsIG9wZXJhdGlvbiwgYWZ0ZXIgbWVtYmVyIGhhcyBiZWVu IGV4Y2x1ZGVkLCBldGMuDQoNCg0KVGhlIE9TQ09SRSBtZXNzYWdlIGZvcm1hdCBpbmNsdWRlcyB0 aGUgJ2tpZCcgYW5kIHRoZSAna2lkIGNvbnRleHQnLiBGb3IgdGhlIGdyb3VwIHNldHRpbmc6DQoN CiogdGhlIGtpZCBjb250YWlucyB0aGUgSUQgb2YgdGhlIHNlbmRpbmcgZ3JvdXAgbWVtYmVyIChT ZW5kZXIgSUQpLCB1bmlxdWUgaW4gdGhlIGdyb3VwLCBhc3NpZ25lZCBieSB0aGUgZ3JvdXAgbWFu YWdlciAod2hpY2ggY291bGQgYmUganVzdCBhIHNob3J0IGJ5dGUgc3RyaW5nKS4NCg0KKiBUaGUg a2lkIGNvbnRleHQgY29udGFpbnMgdGhlIGdyb3VwIGlkZW50aWZpZXIsIGFsc28gYXNzaWduZWQg YnkgdGhlIGdyb3VwIG1hbmFnZXIgYW5kIHVuaXF1ZSBmb3IgdGhpcyBncm91cCBtYW5hZ2VyLiBU aGUga2lkIGNvbnRleHQgaXMgYSAiY29udGV4dCBoaW504oCdIGhlbHBpbmcgdGhlIHJlY2lwaWVu dCBlbmRwb2ludCBmaW5kIHRoZSBzZWN1cml0eSBjb250ZXh0LiBJZiBlbmRwb2ludHMgYXJlIGRl cGxveWVkIHdpdGggbXVsdGlwbGUgdW5jb29yZGluYXRlZCBncm91cCBtYW5hZ2VycyB0aGVuIHRo ZXkgbmVlZCB0byBiZSBhYmxlIHRvIGhhbmRsZSBjb2luY2lkaW5nIGdyb3VwIGlkZW50aWZpZXJz LCBlLmcuIGJ5IHRyeWluZyBtdWx0aXBsZSBzZWN1cml0eSBjb250ZXh0cyB0byBzZWUgaWYgaWYg YW55IHZlcmlmaWVzLiBBcyBsb25nIGFzIHRoZSBNYXN0ZXIgU2VjcmV0IGlzIGRpZmZlcmVudCBm b3IgZGlmZmVyZW50IGdyb3VwcyAoYW5kIGRpZmZlcmVudCBlcG9jaHMgb2YgYSBncm91cCkgYW5k IHRoZSBTZW5kZXIgSURzIHdpdGhpbiB0aGUgZ3JvdXAgYXJlIHVuaXF1ZSwgdGhhdCBpcyBzdWZm aWNpZW50IHRvIG1ha2UgQUVBRCBrZXkgYW5kIG5vbmNlIGRpZmZlcmVudC4NCg0KDQpTbyB0aGVy ZSBpcyBubyBuZWVkIGZvciBuZWdsaWdhYmxlIHByb2JhYmlsdHkgb2YgY29pbmNpZGluZyBncm91 cCBpZGVudGlmaWVycyBhcyBsb25nIGFzIHRoZSByZWNpcGllbnQgY2FuIGZpbmQgaXRzIHdheSB0 byB0aGUgcmlnaHQgc2VjdXJpdHkgY29udGV4dC4gQnV0IGluIHRoZSBjYXNlIG9mIGFuIGVuZHBv aW50IGJlaW5nIGluIG11bHRpcGxlIGdyb3VwcyBtYW5hZ2VkIGJ5IGRpZmZlcmVudCBncm91cCBt YW5hZ2VycywgaXQgaXMgb2YgY291cnNlIGZhdm91cmFibGUgaWYgdGhlIGdyb3VwIGlkZW50aWZp ZXJzIGFyZSBkaWZmZXJlbnQuIFNvIHdlIHNob3VsZCByZXBocmFzZSB0aGlzIGFjY29yZGluZ2x5 Lg0KDQoNCkZ1cnRoZXIgY29tbWVudHMgaW5saW5lLg0KDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBF c2tvIERpamsgPGVza28uZGlqa0BwaGlsaXBzLmNvbTxtYWlsdG86ZXNrby5kaWprQHBoaWxpcHMu Y29tPj4NCkRhdGU6IFdlZG5lc2RheSA3IE1hcmNoIDIwMTggYXQgMDk6MjkNClRvOiBNYXJjbyBU aWxvY2EgPG1hcmNvLnRpbG9jYUByaS5zZTxtYWlsdG86bWFyY28udGlsb2NhQHJpLnNlPj4sIEph aW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbTxtYWlsdG86amFpbWUuamlt ZW5lekBlcmljc3Nvbi5jb20+PiwgImNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+ IFdHIChjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPikiIDxjb3JlQGlldGYub3Jn PG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBDYWxs IGZvciBBZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwDQoNClRo YW5rcyBNYXJjbywNCg0KVGhpcyB1cGRhdGUgc29sdmVzIHRoZSBpc3N1ZXMgSSB0aGluayBhbmQg YW5zd2VycyBteSBxdWVzdGlvbnMsIGV4Y2VwdCBmb3IgdGhlIHJhbmRvbW5lc3MgaW4gdGhlIEdp ZDogIOKAnEEgR2lkIE1VU1QgaGF2ZSBhIHJhbmRvbSBjb21wb25lbnQgYW5kIGJlIGxvbmcgZW5v dWdoLCBpbiBvcmRlciB0byBhY2hpZXZlIGEgbmVnbGlnaWJsZSBwcm9iYWJpbGl0eSBvZiBjb2xs aXNpb25zIGJldHdlZW4gR3JvdXAgSWRlbnRpZmllcnMgZnJvbSBkaWZmZXJlbnQgR3JvdXAgTWFu YWdlcnPigJ07IGFuZCBBcHBlbmRpeCBDLg0KDQpUaGUgZXhhbXBsZSBBcHBlbmRpeCBDIHVzZXMg YSBzaW5nbGUgcmFuZG9tIGJ5dGUuICBNb3N0IHBlb3BsZSB3b3VsZCB0aGluayB0aGUgY29sbGlz aW9uIHByb2JhYmlsaXR5IGlzIHF1aXRlIGhpZ2ggaW4gdGhpcyBjYXNlOyBzbyBob3cgY2FuIHRo aXMgY2hvaWNlIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50Pw0KDQpTZWUgYWJvdmUuDQoNCk1heWJl IGluIHRoaXMgZXhhbXBsZSB0aGUgR3JvdXAgTWFuYWdlcnMgcGljayBhIHJhbmRvbSB2YWx1ZSBh bmQgdGhlbiBtdXR1YWxseSB2ZXJpZnkgdGhhdCB0aGVyZSBhcmUgbm8gY29sbGlzc2lvbnM/DQoN Cg0KWWVzLCBpZiB0aGVyZSBpcyBjb29yZGluYXRpb24gYmV0d2VlbiBncm91cCBtYW5hZ2Vycywg YnV0IHRoaXMgaXMgbm90IG5lY2Vzc2FyeSBmb3IgdGhlIHNjaGVtZSB0byB3b3JrIGFzIG5vdGVk IGFib3ZlLg0KDQpUaGUgbmFtZSDigJxHcm91cCBFcG9jaOKAnSBjb3VsZCBiZSBzbGlnaHRseSBj b25mdXNpbmcgaGVyZSDigJMgQXBwZW5kaXggQyBzdGF0ZXMgdGhlIGVwb2NoIGFwcGxpZXMgdG8g YSBzaW5nbGUgZ3JvdXAuIEhvd2V2ZXIgdGhlIGV4YW1wbGUgdGhlcmUgc2hvd3MgdGhlIGVwb2No IGFwcGxpZXMgdG8gYWxsIGdyb3VwcyBmcm9tIHRoZSBzYW1lIEdyb3VwIE1hbmFnZXIsIG9yIGlu IG90aGVyIHdvcmRzIHRoZSBlcG9jaCAqaXMqIHRoZSBncm91cC4gKEJlY2F1c2UgdGhlcmUgaXMg bm8gdGhpbmcgbGlrZSDigJxHcm91cCBJROKAnSBpbiB0aGUgZXhhbXBsZSwgb25seSBHTSByYW5k b20gYnl0ZSBhbmQgR3JvdXAgRXBvY2ggYnl0ZXMuKSAgV2FzIGl0IGludGVuZGVkIHRvIGFkZCBh IGJ5dGUgb3Igc28gZm9yIOKAnEdyb3VwIElE4oCdID8gU28gdGhhdCBlYWNoIGdyb3VwIGNhbiBo YXZlIGl0cyBvd24gZXBvY2ggY291bnRlci4NCg0KDQpUaGUgaW50ZW50IHdhcyB0aGF0IHRoZSBH cm91cCBJRCBjb25zaXN0cyBvZiBhIEdyb3VwIFByZWZpeCBhbmQgYSBHcm91cCBFcG9jaC4gVGhl IG5lZWQgZm9yIGEgZ3JvdXAgcHJlZml4IGlzIHRvIGFsbG93IGEgY29uc3RhbnQgaWRlbnRpZmll ciBvZiB0aGUgZ3JvdXAuIFRoZSBuZWVkIGZvciBncm91cCBlcG9jaCBpcyB0byBhbGxvdyBlbmRw b2ludHMgdG8gZmluZCB0aGUgcmlnaHQgTWFzdGVyIEtleXMgdXNlZCBpbiB0aGUgZ3JvdXAgYXQg YSBjZXJ0YWluIHRpbWUuDQoNCiBHcm91cCBpZGVudGlmaWVycyBtYXkgYmUgY29uc3RydWN0ZWQg aW4gb3RoZXIgd2F5cyB0aGF0IG1ha2VzIHRoZSByZWNpcGllbnQgZmluZCB0aGUgcmlnaHQgc2Vj dXJpdHkgY29udGV4dC4NCg0KSG9wZSB0aGF0IGhlbHBzLg0KDQpUaGFua3MsDQpHw7ZyYW4NCg0K DQpFc2tvDQoNCg0KDQpGcm9tOiBNYXJjbyBUaWxvY2EgPG1hcmNvLnRpbG9jYUByaS5zZTxtYWls dG86bWFyY28udGlsb2NhQHJpLnNlPj4NClNlbnQ6IE1vbmRheSwgTWFyY2ggNSwgMjAxOCAyMzox OA0KVG86IEVza28gRGlqayA8ZXNrby5kaWprQHBoaWxpcHMuY29tPG1haWx0bzplc2tvLmRpamtA cGhpbGlwcy5jb20+PjsgSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29t PG1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbT4+OyBjb3JlQGlldGYub3JnPG1haWx0 bzpjb3JlQGlldGYub3JnPiBXRyAoY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4p IDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbY29y ZV0g8J+UlCBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNh c3Qtb3Njb2FwDQoNCg0KSGVsbG8gRXNrbywNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBzdXBwb3J0 IGFuZCBjb21tZW50cywgd2UgaGF2ZSBjb25zaWRlcmVkIHRoZW0gd2hlbiBwcm9kdWNpbmcgdGhl IGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSAgZHJhZnQgWzFdLg0KDQoNCg0KUGxlYXNlLCBmaW5kIGlu IGxpbmUgc29tZSBhbnN3ZXJzIHRvIHlvdXIgY29tbWVudHMuDQoNCg0KDQpCZXN0LA0KDQovTWFy Y28NCg0KDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LW9zY29yZS1ncm91cGNvbW0tMDENCg0KT24gMjAxNy0xMi0wNCAxNDozNSwgRXNrbyBEaWprIHdy b3RlOg0KSSBhbHNvIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgYSB3b3Jr IGl0ZW0gZm9yIENvUkUuIEJlbG93IGFyZSB0aGUgcmVzdWx0cyBvZiBhIHF1aWNrIHJldmlldywg YWxzby4NCg0KQmVzdCByZWdhcmRzDQpFc2tvIERpamsNCg0KDQpPdmVyYWxsIGNvbW1lbnRzIOKA kyBvciB3b3JrIHRoYXQgdGhlIFdHIGNvdWxkIHRha2UgdXAgbmV4dA0KwrcgICAgICAgICBEZXRh aWxlZCBleGFtcGxlIHdpdGggbWVzc2FnZSBzaXplcyB3b3VsZCBiZSB1c2VmdWwuIFNpbmNlIGl0 4oCZcyBpbXBvcnRhbnQgZm9yIG11bHRpY2FzdCBvdmVyIDZsb3dwYW4gcGVyZm9ybWFuY2UgdGhh dCB0aGUgSVB2NiBwYWNrZXRzIHN0YXkgc21hbGwgZW5vdWdoIChvbmUgODAyLjE1LjQgZnJhbWUp LiBBdCB0aGlzIG1vbWVudCwgSSBjYW7igJl0IGp1ZGdlIHRoYXQgeWV0IGVhc2lseSBiYXNlZCBv biB0aGUgZHJhZnQuDQoNCg0KW01UXSBXZSBoYXZlIG5vdyBpbmNsdWRlZCBkZXRhaWxlZCBleGFt cGxlcyBpbiBTZWN0aW9ucyAzLjEgKFJlcXVlc3QpIGFuZCBTZWN0aW9uIDMuMiAoUmVzcG9uc2Up Lg0KDQoNCsK3ICAgICAgICAgTm9ybWFsbHksIGZvciBhcHBsaWNhdGlvbnMgKGUuZy4gQnVpbGRp bmcgYXV0b21hdGlvbiBhbmQgbGlnaHRpbmcpIGdyb3VwcyBkbyBuZWVkIGEgc3RhYmxlIGFuZCBu b24tcmFuZG9tIGdyb3VwIElELCB0aGF0IGlkZW50aWZpZXMgdGhlIGdyb3VwIG92ZXIgdGltZSBl dmVuIGFzIGNoYW5nZXMgb2NjdXIsIGUuZy4gbWVtYmVycyBhZGRlZC9yZW1vdmVkLiBUaGUg4oCc R2lk4oCdIGluIHRoZSBkcmFmdCBob3dldmVyIGNoYW5nZXMuIFRoZXJlIGNvdWxkIGJlIHNvbWUg dGV4dCBhZGRlZCB0byBleHBsYWluIGhvdyBHaWQgaXMgbGlua2VkIHRvIGEgc3RhYmxlIElELiBF LmcuLCB0aGlzIGNvdWxkIGJlIGNvbmZpZ3VyZWQgYnkgdGhlIEdyb3VwIE1hbmFnZXIuIFRoZSBz dGFibGUgZ3JvdXAgSUQgaXMgdGhlbiBub3QgdXNlZCBvdmVyLXRoZS13aXJlIGZvciBtdWx0aWNh c3QgT1NDT1JFLg0KDQoNCltNVF0gSXQgaXMgdHJ1ZSB0aGF0IHRoZSBHaWQgaW4gdGhpcyBkcmFm dCBjaGFuZ2VzIG92ZXIgdGltZSwgZXNwZWNpYWxseSB1cG9uIHJlbmV3aW5nIHRoZSBncm91cCBr ZXlpbmcgbWF0ZXJpYWwsIGFuZCB0aGUgR3JvdXAgTWFuYWdlciBpcyB0aGUgb25seSByZXNwb25z aWJsZSBmb3IgbWFuYWdpbmcgaXRzIHZhbHVlIHVwZGF0ZS4gSG93ZXZlciwgdGhpcyBHaWQgaGFz IHRvIGJlIGludGVuZGVkIGFzIHRoZSBpZGVudGlmaWVyIG9mIHRoZSBPU0NPUkUg4oCcc2VjdXJp dHkgZ3JvdXDigJ0sIGluY2x1ZGluZyBhcyBtZW1iZXJzIHRoZSBlbmRwb2ludHMgdGhhdCBzaGFy ZSB0aGUgc2FtZSBDb21tb24gU2VjdXJpdHkgQ29udGV4dC4NCg0KW01UXSBBcyB5b3Ugc2F5LCBh cHBsaWNhdGlvbnMgZG8gcmVseSBvbiBhIHN0YWJsZSBhbmQgbm9uLXJhbmRvbSBncm91cCBJRCwg d2hpY2ggaXMgbm90IHVzZWQgb3Zlci10aGUtd2lyZSBmb3IgZ3JvdXAgT1NDT1JFLCBhbmQgaW5z dGVhZCBpZGVudGlmaWVzIGFuIOKAnGFwcGxpY2F0aW9uIGdyb3Vw4oCdIGhhdmluZyBhcyBtZW1i ZXJzIHRoZSBlbmRwb2ludHMgdGhhdCBwYXJ0aWNpcGF0ZSBpbiBhIHNhbWUgZ3JvdXAgYXBwbGlj YXRpb24uIFRoZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW4gdGhpcyBhcHBsaWNhdGlvbi1sZXZl bCBncm91cCBJRCBhbmQgdGhlIE9TQ09SRSBHaWQgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0LiBIb3dl dmVyLCBvbmUgbWF5IHBvc3NpYmx5IG1hcCBtdWx0aXBsZSDigJxhcHBsaWNhdGlvbiBncm91cHPi gJ0gdG8gdGhlIHNhbWUg4oCcc2VjdXJpdHkgZ3JvdXDigJ0uDQoNCltNVF0gSW4gb3JkZXIgdG8g Y2xhcmlmeSB0aGlzIHBvaW50LCB3ZSBpbmNsdWRlZCBhbHNvIGEgZGVmaW5pdGlvbiBvZiDigJxH cm91cOKAnSBhbmQg4oCcR3JvdXAgSUTigJ0gaW4gU2VjdGlvbiAxLjEuDQoNCg0KwrcgICAgICAg ICBUaGVyZSBpcyBub3JtYXRpdmUgdGV4dCBpbiB0aGUgQXBwZW5kaWNlczsgaXQgY291bGQgYmUg Y2xhcmlmaWVkIHdoYXQgdGhlIHN0YXR1cyBvZiB0aGlzIGlzLiBFLmcuIG9ubHkgbm9ybWF0aXZl IGlmIG9uZSBjaG9vc2VzIHRvIGltcGxlbWVudCB0aGUgb3B0aW9uYWwgZWxlbWVudCBkZXNjcmli ZWQgaW4gdGhlIEFwcGVuZGl4P0kgaGF2ZSBhIHByZWZlcmVuY2UgZm9yIGF2b2lkaW5nIG5vcm1h dGl2ZSB0ZXh0IGluIHRoZSBBcHBlbmRpY2VzLCBidXQgSeKAmW0gY3VyaW91cyB0byBoZWFyIHdo YXQgb3RoZXJzIHRoaW5rLg0KDQpbTVRdIFdlIHJlbGF4ZWQgdGhlIHRleHQgaW4gQXBwZW5kaWNl cyB0byBhdm9pZCBub3JtYXRpdmUgcmVmZXJlbmNlcywgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIGEg 4oCcTk9UIFJFQ09NTUVOREVE4oCdIGluIGN1cnJlbnQgQXBwZW5kaXggRiDigJxObyBWZXJpZmlj YXRpb24gb2YgU2lnbmF0dXJlc+KAnS4NCg0KDQrCtyAgICAgICAgIFRoZSB0ZXh0IHNvbWV0aW1l cyBzdWdnZXN0cyB0aGF0IGEgc2VjdXJlIGdyb3VwIGNvbnRleHQgaXMgbGlua2VkIHRvIG9uZSBh bmQgb25seSBvbmUgbXVsdGljYXN0IElQIGFkZHJlc3MuIEluIHByYWN0aWNlLCB0aGVyZSBtYXkg YmUgbW9yZSB2YXJpZXR5IOKAkyBlLmcuIG9uZSBtdWx0aWNhc3QgSVAgYWRkcmVzcyBwbHVzIG9u ZSBvciBtb3JlIHVuaWNhc3QgSVAgYWRkcmVzc2VzIHRvIHdoaWNoIHRoZSBncm91cCBtZXNzYWdl IGlzIHN1YnNlcXVlbnRseSBkZWxpdmVyZWQuIEUuZy4gcmVwZWF0IG9mIHRoZSBncm91cCBtZXNz YWdlIHRvIG1lbWJlcnMgd2hpY2ggZGlkIG5vdCBnZXQgaXQgeWV0LiBUaGUgcHJvcG9zZWQgc29s dXRpb24gY291bGQgYmUgcmV2aWV3ZWQgd2l0aCB0aGF0IHZpZXcgaW4gbWluZCwgdGhhdCB0aGVy ZSBtYXkgYmUgbXVsdGlwbGUgKG11bHRpY2FzdC91bmljYXN0KSBJUCBkZXN0aW5hdGlvbiBhZGRy ZXNzZXMgdG8gd2hpY2ggYSBncm91cCBtZXNzYWdlIHdpbGwgYmUgc2VudC4gSSBkaWQgbm90IGRv IHRoYXQgeWV0OyBjYW4gZG8gc28gaW4gYSBmdXR1cmUgaW4tZGVwdGggcmV2aWV3Lg0KDQoNCltN VF0gVGhhbmtzLCB0aGF04oCZcyBhIHZlcnkgZ29vZCBjb21tZW50LiBXZeKAmWxsIHRoaW5rIG1v cmUgb24gdGhlIHBvc3NpYmxlIHZpZXcgeW91IHByb3Bvc2UuIEl0IHNob3VsZCBiZSBmaW5lIGFz IGxvbmcgYXMgYSByZWNpcGllbnQgaXMgYWJsZSB0byByZXRyaWV2ZSB0aGUgcmlnaHQgZ3JvdXAg U2VjdXJpdHkgQ29udGV4dCwgYnkgdXNpbmcgdGhlIEdpZC4NCg0KDQoNClNlY3Rpb24gMi4xDQpT b21lIHRoaW5ncyBoZXJlIGFyZSBsaXN0ZWQgYXMgb3V0IG9mIHNjb3BlLCBidXQgdGhleSBkbyBj b21lIGJhY2sgbGF0ZXIgaW4gdGhlIGRvYyDigJMgc3VjaCBhcyBmb3J3YXJkIHNlY3VyaXR5IGFu ZCBiYWNrd2FyZCBzZWN1cml0eSAsIHdoaWNoIGFyZSBhZGRyZXNzZWQgSSB0aGluayDigJMgY2Vy dGFpbmx5IG5vdCBvdXQgb2Ygc2NvcGUuDQoNCg0KW01UXSBHcm91cCBPU0NPUkUgZG9lcyBub3Qg ZW5zdXJlIGZvcndhcmQgc2VjdXJpdHkgYW5kIGJhY2t3YXJkIHNlY3VyaXR5IGl0c2VsZi4gSW5z dGVhZCwgdGhleSBhcmUgZW50cnVzdGVkIHRvIHRoZSBzcGVjaWZ5aW5nIGdyb3VwIHJla2V5aW5n IHByb3RvY29sIGVuZm9yY2VkIGJ5IHRoZSBHcm91cCBNYW5hZ2VyLiBUaGUgc3BlY2lmaWMgcmVr ZXlpbmcgcHJvdG9jb2wgaWYgb3V0IG9mIHNjb3BlIGZvciBHcm91cCBPU0NPUkUsIHdoaWNoIGhv d2V2ZXIgcmVjb21tZW5kcyB0aGUgdXNlIG9mIG9uZSBhYmxlIHRvIGVuc3VyZSBiYWNrd2FyZCBh bmQgZm9yd2FyZCBzZWN1cml0eSBpbiB0aGUgZ3JvdXAuDQoNCg0KDQpTZWN0aW9uIDMNCiIgR2lk IE1VU1QgYmUgcmFuZG9tICIgLT4gc2VlbXMgdG8gY29udHJhZGljdCBBcHBlbmRpeCBCIHdoaWNo IHVzZXMgYW4gRXBvY2ggY291bnRlciBpbiB0aGUgR2lkLiAgU2hvdWxkIGl0IHNheSDigJxNVVNU IGhhdmUgYSByYW5kb20gY29tcG9uZW504oCdID8NCg0KDQpbTVRdIFJpZ2h0LCBub3cgZml4ZWQg KGluIGN1cnJlbnQgQXBwZW5kaXggQykuDQoNCg0KDQpBcHBlbmRpY2VzDQoNCiAgKiAgIEFwcGVu ZGl4IEIsIGEgY29uY3JldGUgZXhhbXBsZSBpbnN0YW5jZSBpcyBtaXNzaW5nLiBFLmcuIOKAnHcz Zmo5MGYwYV8wMDQy4oCdIG9yIGl0cyBic3RyIGVxdWl2YWxlbnQgIChqdXN0IGd1ZXNzaW5nIGhl cmUgdG8gdGhlIGZvcm1hdCkNCg0KDQpbTVRdIFdlIGFkZGVkIGFuIGV4YW1wbGUsIGluIGN1cnJl bnQgQXBwZW5kaXggQy4NCg0KDQoNCiAgKg0KICAqICAgQXBwZW5kaXggQywgaXMgdGhpcyBhbiBl eGFtcGxlIGJsdWVwcmludCBvZiBob3cgdG8gZG8gaXQg4oCTIGZ1bGx5IG9wdGlvbmFsIHRvIGZv bGxvdyBvciBub3QgZm9sbG93IHRoaXM/DQoNCg0KW01UXSBXZSByZWxheGVkIHRoZSB0ZXh0IGlu IGN1cnJlbnQgQXBwZW5kaXggRCwgYXMgZm9yIHRoZSB0aW1lIGJlaW5nIGl0IGlzIGludGVuZGVk IHRvIGJlIGEgZ3VpZGVsaW5lIGV4YW1wbGUuDQoNCg0KDQogICoNCg0KTWlub3INCg0KICAqICAg bGlndGhpbmcgLT4gbGlnaHRpbmcNCiAgKiAgIGVucG9pbnQgIC0+IGVuZHBvaW50DQogICogICBQ ZyAyNSAsIFtJLUQuaWV0Zi1hY2UtZHRscy1hdXRob3JpemVdIHJlZmVyZW5jZSBicmVha3MgYWNy b3NzIGxpbmUgYW5kIGFzIHN1Y2ggYmVjb21lcyBub24tc2VhcmNoYWJsZSBpbiB0aGUgYnJvd3Nl ci4gQW5kIEkgbGlrZSB0aGVzZSByZWZzIHRvIGJlIHNlYXJjaGFibGUg8J+YiQ0KDQoNCg0KDQoN CkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBK YWltZSBKaW3DqW5leg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIzLCAyMDE3IDE3OjU5DQpU bzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4gV0cgKGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOmNvcmVAaWV0Zi5vcmc+KSA8Y29yZUBpZXRmLm9yZz48bWFpbHRvOmNvcmVAaWV0Zi5v cmc+DQpDYzogamkteWUucGFya0B1bmktZHVlLmRlPG1haWx0bzpqaS15ZS5wYXJrQHVuaS1kdWUu ZGU+DQpTdWJqZWN0OiBbY29yZV0g8J+UlCBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10 aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwDQoNCkRlYXIgYWxsLA0KDQpUaGUgZHJhZnQgb24g IlNlY3VyZSBncm91cCBjb21tdW5pY2F0aW9uIGZvciBDb0FQIiAoIGRyYWZ0LXRpbG9jYS1jb3Jl LW11bHRpY2FzdC1vc2NvYXA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9j YS1jb3JlLW11bHRpY2FzdC1vc2NvYXAvPiApIGhhZCBpbiByb29tIGNvbnNlbnN1cyBmb3IgYWRv cHRpb24gZHVyaW5nIElFVEY5OSBhbHJlYWR5LCBub3cgd2UgYXJlIGNsZWFyIHRvIGNvbmZpcm0g aXQgb24gdGhlIG1haWxpbmcgbGlzdC4NCg0KUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGgg eW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRoZXIg b3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLiBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxseSBl bmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQoNClRhcmdldCB0byBlbmQgdGhlIFdHQSBpcyAxNHRoIG9m IERlY2VtYmVyLg0KDQpDaWFvLA0KLSAtIEphaW1lIEppbcOpbmV6DQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBl bWFpbCBtYXkgYmUgY29uZmlkZW50aWFsIGFuZC9vciBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBh cHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRk cmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24s IG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFs bCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIGVtYWlsLg0KDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpjb3JlIG1haWxpbmcgbGlzdA0KDQpj b3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KDQoNCi0tDQoNCk1hcmNvIFRpbG9jYSwgUGhEDQoN ClJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuDQoNClJJU0UgSUNUL1NJQ1MNCg0KSXNhZmpv cmRzZ2F0YW4gMjIgLyBLaXN0YWfDpW5nZW4gMTYNCg0KU0UtMTY0IDQwIEtpc3RhIChTd2VkZW4p DQoNClBob25lOiArNDYgKDApNzAgNjAgNDYgNTAxDQoNCmh0dHBzOi8vd3d3LnNpY3Muc2UNCg0K DQoNClRoZSBSSVNFIGluc3RpdHV0ZXMgSW5udmVudGlhLCBTUCBhbmQgU3dlZGlzaCBJQ1QNCg0K aGF2ZSBtZXJnZWQgaW4gb3JkZXIgdG8gYmVjb21lIGEgc3Ryb25nZXIgcmVzZWFyY2gNCg0KYW5k IGlubm92YXRpb24gcGFydG5lciBmb3IgYnVzaW5lc3NlcyBhbmQgc29jaWV0eS4NCg0KDQoNClNJ Q1MgU3dlZGlzaCBJQ1QgQUIsIGhhcyBub3cgY2hhbmdlZCBuYW1lIHRvIFJJU0UgU0lDUyBBQi4N Cg== --_000_D6C5CECEA1342goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9209064372FACF46B8651A89C4EDC818@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGZvbnQgZmFjZT0iQ2FsaWJyaSI+SGkgRXNrbyw8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIj5UaGFu a3MgZm9yIGdvb2QgY29tbWVudHMhPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpMZXTi gJlzIHJlY2FwIHRoZSBzZXR0aW5nOiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaTsiPlRoZSBzZW5kZXIgYW5kIHJlY2lwaWVudCBvZiBhIGdyb3VwIE9TQ09SRSBtZXNzYWdl IG5lZWRzIHRvIHJldHJpZXZlL2Rlcml2ZSB0aGUgcmlnaHQgc2VjdXJpdHkgY29udGV4dCBmb3Ig c2VuZGluZyBhbmQgcmVjZWl2aW5nIHJlcXVlc3RzIGFuZCByZXNwb25zZXMsIGFuZCB0aGUgYW1v dW50IG9mIGRhdGEgc2VudCBmb3IgdGhpcyBwdXJwb3NlDQogc2hvdWxkIGJlIGFzIHNtYWxsIGFz IHBvc3NpYmxlLiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7 Ij5UaGlzIHNob3VsZCBhcHBseSB0byBhbGwgcGhhc2VzIG9mIGNvbW11bmljYXRpb247IGZpcnN0 IHRpbWUsIG5vcm1hbCBvcGVyYXRpb24sIGFmdGVyIG1lbWJlciBoYXMgYmVlbiBleGNsdWRlZCwg ZXRjLjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgbWFyZ2lu OiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7Ij4NCjxmb250IGZh Y2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg bWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxmb250IGZhY2U9IkNhbGlicmki PlRoZSBPU0NPUkUgbWVzc2FnZSBmb3JtYXQgaW5jbHVkZXMgdGhlICdraWQnIGFuZCB0aGUgJ2tp ZCBjb250ZXh0Jy4gRm9yIHRoZSBncm91cCBzZXR0aW5nOjwvZm9udD48L3A+DQo8cCBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsgbWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxmb250 IGZhY2U9IkNhbGlicmkiPiogdGhlIGtpZCBjb250YWlucyB0aGUgSUQgb2YgdGhlIHNlbmRpbmcg Z3JvdXAgbWVtYmVyIChTZW5kZXIgSUQpLCB1bmlxdWUgaW4gdGhlIGdyb3VwLCBhc3NpZ25lZCBi eSB0aGUgZ3JvdXAgbWFuYWdlciAod2hpY2gmbmJzcDtjb3VsZCBiZSBqdXN0IGEgc2hvcnQgYnl0 ZSBzdHJpbmcpLiZuYnNwOzwvZm9udD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUt aGVpZ2h0OiBub3JtYWw7Ij48Zm9udCBmYWNlPSJDYWxpYnJpIiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPiogVGhlJm5ic3A7a2lkIGNvbnRleHQgY29udGFpbnMgdGhlIGdyb3VwIGlkZW50aWZpZXIs IGFsc28gYXNzaWduZWQgYnkgdGhlIGdyb3VwIG1hbmFnZXIgYW5kIHVuaXF1ZSBmb3IgdGhpcyBn cm91cCBtYW5hZ2VyLg0KIFRoZSBraWQgY29udGV4dCBpcyBhICZxdW90O2NvbnRleHQgaGludOKA nSBoZWxwaW5nIHRoZSByZWNpcGllbnQgZW5kcG9pbnQmbmJzcDs8L2ZvbnQ+PHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBmb250LXNpemU6IDE0 cHg7Ij5maW5kIHRoZSBzZWN1cml0eSBjb250ZXh0LiZuYnNwOzwvc3Bhbj48Zm9udCBmYWNlPSJD YWxpYnJpIj5JZiBlbmRwb2ludHMgYXJlIGRlcGxveWVkIHdpdGggbXVsdGlwbGUgdW5jb29yZGlu YXRlZA0KIGdyb3VwIG1hbmFnZXJzIHRoZW4gdGhleSBuZWVkIHRvIGJlIGFibGUgdG8gaGFuZGxl IGNvaW5jaWRpbmcgZ3JvdXAgaWRlbnRpZmllcnMsIGUuZy4gYnkgdHJ5aW5nIG11bHRpcGxlIHNl Y3VyaXR5IGNvbnRleHRzIHRvIHNlZSBpZiZuYnNwO2lmIGFueSB2ZXJpZmllcy4gQXMgbG9uZyBh cyB0aGUgTWFzdGVyIFNlY3JldCBpcyBkaWZmZXJlbnQgZm9yIGRpZmZlcmVudCBncm91cHMgKGFu ZCBkaWZmZXJlbnQgZXBvY2hzIG9mIGEgZ3JvdXApIGFuZCB0aGUgU2VuZGVyDQogSURzIHdpdGhp biB0aGUgZ3JvdXAgYXJlIHVuaXF1ZSwgdGhhdCBpcyBzdWZmaWNpZW50IHRvIG1ha2UgQUVBRCBr ZXkgYW5kIG5vbmNlIGRpZmZlcmVudC48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyI+ DQo8Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8Zm9udCBmYWNl PSJDYWxpYnJpIj5TbyB0aGVyZSBpcyBubyBuZWVkIGZvciBuZWdsaWdhYmxlIHByb2JhYmlsdHkg b2YgY29pbmNpZGluZyBncm91cCBpZGVudGlmaWVycyBhcyBsb25nIGFzIHRoZSByZWNpcGllbnQg Y2FuIGZpbmQgaXRzIHdheSB0byB0aGUgcmlnaHQgc2VjdXJpdHkgY29udGV4dC4mbmJzcDs8L2Zv bnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+QnV0IGluIHRoZSBjYXNlIG9m IGFuIGVuZHBvaW50IGJlaW5nIGluIG11bHRpcGxlDQogZ3JvdXBzIG1hbmFnZWQgYnkgZGlmZmVy ZW50IGdyb3VwIG1hbmFnZXJzLCBpdCBpcyBvZiZuYnNwO2NvdXJzZSZuYnNwO2Zhdm91cmFibGUg aWYgdGhlIGdyb3VwIGlkZW50aWZpZXJzIGFyZSBkaWZmZXJlbnQuIFNvIHdlIHNob3VsZCByZXBo cmFzZSB0aGlzIGFjY29yZGluZ2x5Ljwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsgbWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaTsiPjxicj4NCjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsgbWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxmb250IGZhY2U9IkNh bGlicmkiPkZ1cnRoZXIgY29tbWVudHMgaW5saW5lLjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Ymxh Y2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAw aW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu b25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G cm9tOiA8L3NwYW4+Y29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9y ZyI+Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEVza28gRGlqayAm bHQ7PGEgaHJlZj0ibWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbSI+ZXNrby5kaWprQHBoaWxp cHMuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTog PC9zcGFuPldlZG5lc2RheSA3IE1hcmNoIDIwMTggYXQgMDk6Mjk8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5NYXJjbyBUaWxvY2EgJmx0OzxhIGhyZWY9Im1h aWx0bzptYXJjby50aWxvY2FAcmkuc2UiPm1hcmNvLnRpbG9jYUByaS5zZTwvYT4mZ3Q7LCBKYWlt ZSBKaW3DqW5leiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29t Ij5qYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4NCiBXRyAoPGEgaHJlZj0ibWFpbHRv OmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtjb3JlXSDwn5SUIFdHIENh bGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXA8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tf QVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29s aWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2Uv MjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8 bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJl ZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0 aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6 NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIEVtb2ppIjsNCglwYW5vc2UtMToyIDEx IDUgMiA0IDIgNCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWxpbmUtaGVpZ2h0Om5vcm1hbDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJs YWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWxpbmUtaGVpZ2h0Om5v cm1hbDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMjAlOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJbGluZS1oZWlnaHQ6MTIwJTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0NzgxNTIwOTY7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTI5MTE0NTI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDoxNDkyOTg0NTcxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMjEzNzQ3OTIzNCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlz dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXtt c28tbGlzdC1pZDoxNjMyMTI1NjMxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY5ODkwMjcy NDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE2OTk2MTgxNDY7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0yMjIxMTg1ODY7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNA0KCXttc28tbGlz dC1pZDoxOTczMjkxNTMwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA3NTk0NTUzNjt9DQpA bGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjIwNDIyNDIwMzY7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi01MzM0MDkyMjg7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPlRoYW5rcyBNYXJjbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPlRoaXMgdXBkYXRlIHNvbHZlcyB0aGUgaXNzdWVzIEkgdGhpbmsgYW5kIGFuc3dlcnMgbXkg cXVlc3Rpb25zLCBleGNlcHQgZm9yIHRoZSByYW5kb21uZXNzIGluIHRoZSBHaWQ6ICZuYnNwO+KA nEEgR2lkIE1VU1QgaGF2ZSBhIHJhbmRvbSBjb21wb25lbnQgYW5kIGJlIGxvbmcgZW5vdWdoLCBp biBvcmRlciB0byBhY2hpZXZlIGEgbmVnbGlnaWJsZSBwcm9iYWJpbGl0eSBvZg0KIGNvbGxpc2lv bnMgYmV0d2VlbiBHcm91cCBJZGVudGlmaWVycyBmcm9tIGRpZmZlcmVudCBHcm91cCBNYW5hZ2Vy c+KAnTsgYW5kIEFwcGVuZGl4IEMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0Ij5UaGUgZXhhbXBsZSBBcHBlbmRpeCBDIHVzZXMgYSBzaW5nbGUgcmFuZG9tIGJ5dGUu Jm5ic3A7IE1vc3QgcGVvcGxlIHdvdWxkIHRoaW5rIHRoZSBjb2xsaXNpb24gcHJvYmFiaWxpdHkg aXMgcXVpdGUgaGlnaCBpbiB0aGlzIGNhc2U7IHNvIGhvdyBjYW4gdGhpcyBjaG9pY2Ugc2F0aXNm eSB0aGUgcmVxdWlyZW1lbnQ/Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N Cjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KU2VlIGFib3ZlLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2tx dW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRF Ui1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7 Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5v cmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPk1heWJlIGlu IHRoaXMgZXhhbXBsZSB0aGUgR3JvdXAgTWFuYWdlcnMgcGljayBhIHJhbmRvbSB2YWx1ZSBhbmQg dGhlbiBtdXR1YWxseSB2ZXJpZnkgdGhhdCB0aGVyZSBhcmUgbm8gY29sbGlzc2lvbnM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KWWVzLCBp ZiB0aGVyZSBpcyBjb29yZGluYXRpb24gYmV0d2VlbiBncm91cCBtYW5hZ2VycywgYnV0IHRoaXMg aXMgbm90IG5lY2Vzc2FyeSBmb3IgdGhlIHNjaGVtZSB0byB3b3JrIGFzIG5vdGVkIGFib3ZlLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2tx dW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRF Ui1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7 Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5v cmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoZSBuYW1l IOKAnEdyb3VwIEVwb2No4oCdIGNvdWxkIGJlIHNsaWdodGx5IGNvbmZ1c2luZyBoZXJlIOKAkyBB cHBlbmRpeCBDIHN0YXRlcyB0aGUgZXBvY2ggYXBwbGllcyB0byBhIHNpbmdsZSBncm91cC4gSG93 ZXZlciB0aGUgZXhhbXBsZSB0aGVyZSBzaG93cyB0aGUgZXBvY2ggYXBwbGllcyB0byBhbGwgZ3Jv dXBzIGZyb20gdGhlIHNhbWUgR3JvdXAgTWFuYWdlciwNCiBvciBpbiBvdGhlciB3b3JkcyB0aGUg ZXBvY2ggKjxiPmlzPC9iPiogdGhlIGdyb3VwLiAoQmVjYXVzZSB0aGVyZSBpcyBubyB0aGluZyBs aWtlIOKAnEdyb3VwIElE4oCdIGluIHRoZSBleGFtcGxlLCBvbmx5IEdNIHJhbmRvbSBieXRlIGFu ZCBHcm91cCBFcG9jaCBieXRlcy4pJm5ic3A7IFdhcyBpdCBpbnRlbmRlZCB0byBhZGQgYSBieXRl IG9yIHNvIGZvciDigJxHcm91cCBJROKAnSA/IFNvIHRoYXQgZWFjaCBncm91cCBjYW4gaGF2ZSBp dHMgb3duIGVwb2NoIGNvdW50ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bh bj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmkiPjxi cj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZh Y2U9IkNhbGlicmkiPlRoZSBpbnRlbnQgd2FzIHRoYXQgdGhlIEdyb3VwIElEIGNvbnNpc3RzIG9m IGEgR3JvdXAgUHJlZml4IGFuZCBhIEdyb3VwIEVwb2NoLiZuYnNwOzwvZm9udD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij5UaGUgbmVlZCBmb3IgYSBncm91cCBwcmVmaXggaXMg dG8gYWxsb3cgYSBjb25zdGFudCBpZGVudGlmaWVyIG9mIHRoZSBncm91cC4gVGhlIG5lZWQgZm9y IGdyb3VwIGVwb2NoIGlzIHRvIGFsbG93IGVuZHBvaW50cw0KIHRvIGZpbmQgdGhlIHJpZ2h0IE1h c3RlciBLZXlzIHVzZWQgaW4gdGhlIGdyb3VwIGF0IGEgY2VydGFpbiB0aW1lLjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7R3JvdXAgaWRl bnRpZmllcnMgbWF5IGJlIGNvbnN0cnVjdGVkIGluIG90aGVyIHdheXMgdGhhdCBtYWtlcyB0aGUg cmVjaXBpZW50IGZpbmQgdGhlIHJpZ2h0IHNlY3VyaXR5IGNvbnRleHQuPC9mb250PjwvZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSG9wZSB0aGF0IGhl bHBzLjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpUaGFua3MsPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQpHw7ZyYW48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1 IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2Zm aWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAi Pg0KPGRpdiBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Fc2tvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBNYXJjbyBUaWxvY2Eg Jmx0OzxhIGhyZWY9Im1haWx0bzptYXJjby50aWxvY2FAcmkuc2UiPm1hcmNvLnRpbG9jYUByaS5z ZTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCA1LCAyMDE4IDIzOjE4 PGJyPg0KPGI+VG86PC9iPiBFc2tvIERpamsgJmx0OzxhIGhyZWY9Im1haWx0bzplc2tvLmRpamtA cGhpbGlwcy5jb20iPmVza28uZGlqa0BwaGlsaXBzLmNvbTwvYT4mZ3Q7OyBKYWltZSBKaW3DqW5l eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tIj5qYWltZS5q aW1lbmV6QGVyaWNzc29uLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5v cmciPmNvcmVAaWV0Zi5vcmc8L2E+IFdHICg8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+ Y29yZUBpZXRmLm9yZzwvYT4pICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29y ZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPvCflJQ8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQiPiBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29yZS1tdWx0 aWNhc3Qtb3Njb2FwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5Ij5IZWxsbyBFc2tvLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnkiPlRoYW5rcyBmb3IgeW91ciBzdXBwb3J0IGFuZCBjb21tZW50cywg d2UgaGF2ZSBjb25zaWRlcmVkIHRoZW0gd2hlbiBwcm9kdWNpbmcgdGhlIGxhdGVzdCB2ZXJzaW9u IG9mIHRoZSZuYnNwOyBkcmFmdCBbMV0uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+UGxlYXNlLCBmaW5kIGluIGxpbmUgc29tZSBhbnN3ZXJzIHRvIHlv dXIgY29tbWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+QmVzdCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij4vTWFyY288bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij5bMV0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y29yZS1vc2NvcmUtZ3JvdXBjb21tLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1jb3JlLW9zY29yZS1ncm91cGNvbW0tMDE8L2E+PG86cD48L286cD48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDIwMTctMTItMDQgMTQ6MzUsIEVza28gRGlqayB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gc3VwcG9ydCB0 aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBhIHdvcmsgaXRlbSBmb3IgQ29SRS4gQmVsb3cg YXJlIHRoZSByZXN1bHRzIG9mIGEgcXVpY2sgcmV2aWV3LCBhbHNvLg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RXNrbyBEaWprPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3ZlcmFsbCBjb21tZW50cyDigJMgb3Igd29yayB0aGF0 IHRoZSBXRyBjb3VsZCB0YWtlIHVwIG5leHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0Omw0IGxldmVsMSBsZm8yO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IS0tW2lmICFzdXBw b3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT5EZXRhaWxlZCBleGFtcGxlIHdpdGggbWVzc2FnZSBz aXplcyB3b3VsZCBiZSB1c2VmdWwuIFNpbmNlIGl04oCZcyBpbXBvcnRhbnQgZm9yIG11bHRpY2Fz dCBvdmVyIDZsb3dwYW4gcGVyZm9ybWFuY2UgdGhhdCB0aGUgSVB2NiBwYWNrZXRzIHN0YXkgc21h bGwgZW5vdWdoIChvbmUgODAyLjE1LjQgZnJhbWUpLiBBdCB0aGlzIG1vbWVudCwgSSBjYW7igJl0 IGp1ZGdlIHRoYXQgeWV0IGVhc2lseSBiYXNlZA0KIG9uIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01UXSBXZSBoYXZlIG5vdyBpbmNs dWRlZCBkZXRhaWxlZCBleGFtcGxlcyBpbiBTZWN0aW9ucyAzLjEgKFJlcXVlc3QpIGFuZCBTZWN0 aW9uIDMuMiAoUmVzcG9uc2UpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps NCBsZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCEtLVtpZiAhc3VwcG9ydExp c3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhLS1bZW5kaWZdLS0+Tm9ybWFsbHksIGZvciBhcHBsaWNhdGlvbnMgKGUuZy4gQnVp bGRpbmcgYXV0b21hdGlvbiBhbmQgbGlnaHRpbmcpIGdyb3VwcyBkbyBuZWVkIGEgc3RhYmxlIGFu ZCBub24tcmFuZG9tIGdyb3VwIElELCB0aGF0IGlkZW50aWZpZXMgdGhlIGdyb3VwIG92ZXIgdGlt ZSBldmVuIGFzIGNoYW5nZXMgb2NjdXIsIGUuZy4gbWVtYmVycyBhZGRlZC9yZW1vdmVkLiBUaGUg 4oCcR2lk4oCdIGluIHRoZSBkcmFmdA0KIGhvd2V2ZXIgY2hhbmdlcy4gVGhlcmUgY291bGQgYmUg c29tZSB0ZXh0IGFkZGVkIHRvIGV4cGxhaW4gaG93IEdpZCBpcyBsaW5rZWQgdG8gYSBzdGFibGUg SUQuIEUuZy4sIHRoaXMgY291bGQgYmUgY29uZmlndXJlZCBieSB0aGUgR3JvdXAgTWFuYWdlci4g VGhlIHN0YWJsZSBncm91cCBJRCBpcyB0aGVuIG5vdCB1c2VkIG92ZXItdGhlLXdpcmUgZm9yIG11 bHRpY2FzdCBPU0NPUkUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPltNVF0gSXQgaXMgdHJ1ZSB0aGF0IHRoZSBHaWQgaW4gdGhpcyBkcmFmdCBjaGFuZ2Vz IG92ZXIgdGltZSwgZXNwZWNpYWxseSB1cG9uIHJlbmV3aW5nIHRoZSBncm91cCBrZXlpbmcgbWF0 ZXJpYWwsIGFuZCB0aGUgR3JvdXAgTWFuYWdlciBpcyB0aGUgb25seSByZXNwb25zaWJsZSBmb3Ig bWFuYWdpbmcgaXRzIHZhbHVlDQogdXBkYXRlLiBIb3dldmVyLCB0aGlzIEdpZCBoYXMgdG8gYmUg aW50ZW5kZWQgYXMgdGhlIGlkZW50aWZpZXIgb2YgdGhlIE9TQ09SRSDigJxzZWN1cml0eSBncm91 cOKAnSwgaW5jbHVkaW5nIGFzIG1lbWJlcnMgdGhlIGVuZHBvaW50cyB0aGF0IHNoYXJlIHRoZSBz YW1lIENvbW1vbiBTZWN1cml0eSBDb250ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNVF0gQXMgeW91IHNheSwgYXBwbGljYXRpb25zIGRv IHJlbHkgb24gYSBzdGFibGUgYW5kIG5vbi1yYW5kb20gZ3JvdXAgSUQsIHdoaWNoIGlzIG5vdCB1 c2VkIG92ZXItdGhlLXdpcmUgZm9yIGdyb3VwIE9TQ09SRSwgYW5kIGluc3RlYWQgaWRlbnRpZmll cyBhbiDigJxhcHBsaWNhdGlvbiBncm91cOKAnSBoYXZpbmcgYXMNCiBtZW1iZXJzIHRoZSBlbmRw b2ludHMgdGhhdCBwYXJ0aWNpcGF0ZSBpbiBhIHNhbWUgZ3JvdXAgYXBwbGljYXRpb24uIFRoZXJl IGlzIG5vIHJlbGF0aW9uIGJldHdlZW4gdGhpcyBhcHBsaWNhdGlvbi1sZXZlbCBncm91cCBJRCBh bmQgdGhlIE9TQ09SRSBHaWQgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0LiBIb3dldmVyLCBvbmUgbWF5 IHBvc3NpYmx5IG1hcCBtdWx0aXBsZSDigJxhcHBsaWNhdGlvbiBncm91cHPigJ0gdG8gdGhlIHNh bWUg4oCcc2VjdXJpdHkgZ3JvdXDigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+W01UXSBJbiBvcmRlciB0byBjbGFyaWZ5IHRoaXMgcG9pbnQs IHdlIGluY2x1ZGVkIGFsc28gYSBkZWZpbml0aW9uIG9mIOKAnEdyb3Vw4oCdIGFuZCDigJxHcm91 cCBJROKAnSBpbiBTZWN0aW9uIDEuMS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzI7dmVydGlj YWwtYWxpZ246bWlkZGxlIj4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0t PlRoZXJlIGlzIG5vcm1hdGl2ZSB0ZXh0IGluIHRoZSBBcHBlbmRpY2VzOyBpdCBjb3VsZCBiZSBj bGFyaWZpZWQgd2hhdCB0aGUgc3RhdHVzIG9mIHRoaXMgaXMuIEUuZy4gb25seSBub3JtYXRpdmUg aWYgb25lIGNob29zZXMgdG8gaW1wbGVtZW50IHRoZSBvcHRpb25hbCBlbGVtZW50IGRlc2NyaWJl ZCBpbiB0aGUgQXBwZW5kaXg/SSBoYXZlIGEgcHJlZmVyZW5jZSBmb3IgYXZvaWRpbmcgbm9ybWF0 aXZlDQogdGV4dCBpbiB0aGUgQXBwZW5kaWNlcywgYnV0IEnigJltIGN1cmlvdXMgdG8gaGVhciB3 aGF0IG90aGVycyB0aGluay48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpbTVRdIFdlIHJlbGF4ZWQgdGhlIHRleHQgaW4g QXBwZW5kaWNlcyB0byBhdm9pZCBub3JtYXRpdmUgcmVmZXJlbmNlcywgd2l0aCB0aGUgZXhjZXB0 aW9uIG9mIGEg4oCcTk9UIFJFQ09NTUVOREVE4oCdIGluIGN1cnJlbnQgQXBwZW5kaXggRiDigJxO byBWZXJpZmljYXRpb24gb2YgU2lnbmF0dXJlc+KAnS48L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoyNy4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omw0IGxldmVsMSBsZm8yO3ZlcnRp Y2FsLWFsaWduOm1pZGRsZSI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0t LT5UaGUgdGV4dCBzb21ldGltZXMgc3VnZ2VzdHMgdGhhdCBhIHNlY3VyZSBncm91cCBjb250ZXh0 IGlzIGxpbmtlZCB0byBvbmUgYW5kIG9ubHkgb25lIG11bHRpY2FzdCBJUCBhZGRyZXNzLiBJbiBw cmFjdGljZSwgdGhlcmUgbWF5IGJlIG1vcmUgdmFyaWV0eSDigJMgZS5nLiBvbmUgbXVsdGljYXN0 IElQIGFkZHJlc3MgcGx1cyBvbmUgb3IgbW9yZSB1bmljYXN0IElQIGFkZHJlc3NlcyB0byB3aGlj aA0KIHRoZSBncm91cCBtZXNzYWdlIGlzIHN1YnNlcXVlbnRseSBkZWxpdmVyZWQuIEUuZy4gcmVw ZWF0IG9mIHRoZSBncm91cCBtZXNzYWdlIHRvIG1lbWJlcnMgd2hpY2ggZGlkIG5vdCBnZXQgaXQg eWV0LiBUaGUgcHJvcG9zZWQgc29sdXRpb24gY291bGQgYmUgcmV2aWV3ZWQgd2l0aCB0aGF0IHZp ZXcgaW4gbWluZCwgdGhhdCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgKG11bHRpY2FzdC91bmljYXN0 KSBJUCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgdG8gd2hpY2gNCiBhIGdyb3VwIG1lc3NhZ2Ugd2ls bCBiZSBzZW50LiBJIGRpZCBub3QgZG8gdGhhdCB5ZXQ7IGNhbiBkbyBzbyBpbiBhIGZ1dHVyZSBp bi1kZXB0aCByZXZpZXcuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPltNVF0gVGhhbmtzLCB0aGF04oCZcyBhIHZlcnkgZ29vZCBjb21tZW50LiBXZeKAmWxs IHRoaW5rIG1vcmUgb24gdGhlIHBvc3NpYmxlIHZpZXcgeW91IHByb3Bvc2UuIEl0IHNob3VsZCBi ZSBmaW5lIGFzIGxvbmcgYXMgYSByZWNpcGllbnQgaXMgYWJsZSB0byByZXRyaWV2ZSB0aGUgcmln aHQgZ3JvdXAgU2VjdXJpdHkgQ29udGV4dCwNCiBieSB1c2luZyB0aGUgR2lkLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMi4xPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Tb21lIHRoaW5ncyBoZXJlIGFyZSBsaXN0ZWQgYXMgb3V0IG9mIHNjb3BlLCBidXQg dGhleSBkbyBjb21lIGJhY2sgbGF0ZXIgaW4gdGhlIGRvYyDigJMgc3VjaCBhcyBmb3J3YXJkIHNl Y3VyaXR5IGFuZCBiYWNrd2FyZCBzZWN1cml0eSAsIHdoaWNoIGFyZSBhZGRyZXNzZWQgSSB0aGlu ayDigJMgY2VydGFpbmx5IG5vdCBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNVF0gR3JvdXAgT1NDT1JFIGRvZXMgbm90IGVuc3Vy ZSBmb3J3YXJkIHNlY3VyaXR5IGFuZCBiYWNrd2FyZCBzZWN1cml0eSBpdHNlbGYuIEluc3RlYWQs IHRoZXkgYXJlIGVudHJ1c3RlZCB0byB0aGUgc3BlY2lmeWluZyBncm91cCByZWtleWluZyBwcm90 b2NvbCBlbmZvcmNlZCBieSB0aGUgR3JvdXAgTWFuYWdlci4NCiBUaGUgc3BlY2lmaWMgcmVrZXlp bmcgcHJvdG9jb2wgaWYgb3V0IG9mIHNjb3BlIGZvciBHcm91cCBPU0NPUkUsIHdoaWNoIGhvd2V2 ZXIgcmVjb21tZW5kcyB0aGUgdXNlIG9mIG9uZSBhYmxlIHRvIGVuc3VyZSBiYWNrd2FyZCBhbmQg Zm9yd2FyZCBzZWN1cml0eSBpbiB0aGUgZ3JvdXAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U2VjdGlvbiAzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDsgR2lk IE1VU1QgYmUgcmFuZG9tICZxdW90OyAtJmd0OyBzZWVtcyB0byBjb250cmFkaWN0IEFwcGVuZGl4 IEIgd2hpY2ggdXNlcyBhbiBFcG9jaCBjb3VudGVyIGluIHRoZSBHaWQuJm5ic3A7IFNob3VsZCBp dCBzYXkg4oCcTVVTVCBoYXZlIGEgcmFuZG9tIGNvbXBvbmVudOKAnSA/PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNVF0gUmlnaHQsIG5vdyBmaXhlZCAo aW4gY3VycmVudCBBcHBlbmRpeCBDKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcHBlbmRp Y2VzIDxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVsMSBsZm8y O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+QXBwZW5kaXggQiwgYSBjb25jcmV0ZSBleGFtcGxlIGlu c3RhbmNlIGlzIG1pc3NpbmcuIEUuZy4g4oCcdzNmajkwZjBhXzAwNDLigJ0gb3IgaXRzIGJzdHIg ZXF1aXZhbGVudCZuYnNwOyAoanVzdCBndWVzc2luZyBoZXJlIHRvIHRoZSBmb3JtYXQpPG86cD48 L286cD48L2xpPjwvdWw+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUt aGVpZ2h0OjEyMCU7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNVF0gV2Ug YWRkZWQgYW4gZXhhbXBsZSwgaW4gY3VycmVudCBBcHBlbmRpeCBDLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlk ZGxlIj48bzpwPiZuYnNwOzwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbGlzdDpsNCBsZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPkFwcGVuZGl4IEMs IGlzIHRoaXMgYW4gZXhhbXBsZSBibHVlcHJpbnQgb2YgaG93IHRvIGRvIGl0IOKAkyBmdWxseSBv cHRpb25hbCB0byBmb2xsb3cgb3Igbm90IGZvbGxvdyB0aGlzPzxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMjAlO2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTVRdIFdlIHJlbGF4ZWQgdGhlIHRl eHQgaW4gY3VycmVudCBBcHBlbmRpeCBELCBhcyBmb3IgdGhlIHRpbWUgYmVpbmcgaXQgaXMgaW50 ZW5kZWQgdG8gYmUgYSBndWlkZWxpbmUgZXhhbXBsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1saXN0Omw0IGxldmVsMSBsZm8yO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PG86 cD4mbmJzcDs8L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pbm9yPG86cD48L286cD48L3A+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzgiPmxpZ3RoaW5nIC0mZ3Q7IGxpZ2h0 aW5nPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzgiPmVucG9pbnQmbmJzcDsgLSZndDsgZW5kcG9pbnQ8bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvOCI+ UGcgMjUgLCBbSS1ELmlldGYtYWNlLWR0bHMtYXV0aG9yaXplXSByZWZlcmVuY2UgYnJlYWtzIGFj cm9zcyBsaW5lIGFuZCBhcyBzdWNoIGJlY29tZXMgbm9uLXNlYXJjaGFibGUgaW4gdGhlIGJyb3dz ZXIuIEFuZCBJIGxpa2UgdGhlc2UgcmVmcyB0byBiZSBzZWFyY2hhYmxlDQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+8J+YiTwv c3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI3 LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IGNvcmUgWzxhIGhyZWY9Im1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYWltZSBKaW3DqW5l ejxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMjMsIDIwMTcgMTc6NTk8YnI+ DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3Jn PC9hPiBXRyAoPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+ KQ0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPiZsdDtjb3JlQGlldGYub3JnJmd0Ozwv YT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqaS15ZS5wYXJrQHVuaS1kdWUuZGUi PmppLXllLnBhcmtAdW5pLWR1ZS5kZTwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIDxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNl cmlmIj7wn5SUPC9zcGFuPiBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29y ZS1tdWx0aWNhc3Qtb3Njb2FwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EZWFyIGFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgZHJhZnQgb24gJnF1b3Q7U2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24gZm9yIENvQVAm cXVvdDsgKCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLyI+ZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0 LW9zY29hcDwvYT4mbmJzcDspIGhhZCBpbiByb29tIGNvbnNlbnN1cyBmb3IgYWRvcHRpb24gZHVy aW5nIElFVEY5OSBhbHJlYWR5LCBub3cgd2UgYXJlDQogY2xlYXIgdG8gY29uZmlybSBpdCBvbiB0 aGUgbWFpbGluZyBsaXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGgg eW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCZuYnNwO2xpbWl0ZWQgdG8gd2hl dGhlciZuYnNwO29yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVz cGVjaWFsbHkmbmJzcDtlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFyZ2V0IHRvIGVuZCB0 aGUgV0dBIGlzIDE0dGggb2YgRGVjZW1iZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW8sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIC0gSmFpbWUgSmltw6luZXo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpncmF5Ij5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZW1haWwgbWF5IGJlIGNv bmZpZGVudGlhbCBhbmQvb3IgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcu IFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYg eW91DQogYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVj dGlvbiBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRh Y3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZA0KIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgZW1haWwuPGJyPg0KPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvcmUgbWFpbGluZyBsaXN0PG86cD48L286 cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NvcmU8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5NYXJjbyBUaWxvY2EsIFBoRDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PlJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+UklT RSBJQ1QvU0lDUzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklzYWZqb3Jkc2dhdGFuIDIyIC8gS2lz dGFnw6VuZ2VuIDE2PG86cD48L286cD48L3ByZT4NCjxwcmU+U0UtMTY0IDQwIEtpc3RhIChTd2Vk ZW4pPG86cD48L286cD48L3ByZT4NCjxwcmU+UGhvbmU6ICYjNDM7NDYgKDApNzAgNjAgNDYgNTAx PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuc2ljcy5zZSI+aHR0 cHM6Ly93d3cuc2ljcy5zZTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT5UaGUgUklTRSBpbnN0aXR1dGVzIElubnZlbnRpYSwgU1AgYW5kIFN3 ZWRpc2ggSUNUPG86cD48L286cD48L3ByZT4NCjxwcmU+aGF2ZSBtZXJnZWQgaW4gb3JkZXIgdG8g YmVjb21lIGEgc3Ryb25nZXIgcmVzZWFyY2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW5u b3ZhdGlvbiBwYXJ0bmVyIGZvciBidXNpbmVzc2VzIGFuZCBzb2NpZXR5LjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNJQ1MgU3dlZGlzaCBJQ1Qg QUIsIGhhcyBub3cgY2hhbmdlZCBuYW1lIHRvIFJJU0UgU0lDUyBBQi48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_D6C5CECEA1342goranselanderericssoncom_-- From nobody Tue Mar 13 04:29:28 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FC012D88A for ; Tue, 13 Mar 2018 04:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 hFbcAaB7LJ47 for ; Tue, 13 Mar 2018 04:29:23 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 2E4FD12D77B for ; Tue, 13 Mar 2018 04:29:23 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id v9-v6so28174758lfa.11 for ; Tue, 13 Mar 2018 04:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=7OSkWdJFfEHPxDYeB7mvc55o6Q3bxPTGg7Y+QBVmyj4=; b=moEyjFwlj63XKjGL11tLwn9cuwZ7rkcxhnf5aWaDL5jHIlFA7ulK36np8zbytEKkzx mpTmb0PralqUWSMaDWrv166dduK+ztm0MBgDia0GluKynJlmrnQf5aO1W9unUprpNYNY uWTAnuCPb8RLKPHjbk7xzUWuw3QuSxfVuV/NAvhZf1C1vBWx+9K3ZioD2PyP345WS6p8 wjx/IVaEH/xvx0u4uXxQ1pNqouwol4ZgmJclGJWlqZHoGvzgRtbIt+HTRxwYHiPnYdFX smDTqXNQytdGslqUoaliivl5VbWT6E4Y2/3zuuj6DpgdYC1HGtTuN0OE3m7SNOcAJ5U4 iffA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=7OSkWdJFfEHPxDYeB7mvc55o6Q3bxPTGg7Y+QBVmyj4=; b=L6rt/6Rkd0imbL+ymyjcqW+43Bhvr8izJ81LRGG6QINgrcR0+/nzpOirMzrvYDijoU k+T+5Opbx9exzELxoJx+ErTPBrOwiup6kAV2dFPxEMZcwFLRWf2STFSn2JxMV/tciM2z 8MQ5u2c/98iIlomhkgpmLKFwDIYdnDHXdYOrMcndCHoO/8IEIg7fokRk2X4pOUrcGLVX csbYJi2oZj/WdxdhWqNa0Dgwh3O7F0BplC9bry1x2af1K8iXCFp9nlziXAtXbSP+LynB E0prEV4tjzSBdugHo43SkCPNV1EyHf/cTHkiz18HZK3dkC5i88E4p5GtCrntvVVECm3N ogGA== X-Gm-Message-State: AElRT7FRfZl0P0IkXdyMHxq0//QtrQOjgLmfwLjZ1LR8PIWHwp8oLjuE VT06dlMDVEBnxKC7huOSchtaty1fbbMBjmg2s1M= X-Google-Smtp-Source: AG47ELueBDVeB2MV8M/SDMuwU9CSIMQ/8QUwH6zv1/CT50yIeMRN+5l2TrhFMlX8eLhFsbelgAkYg58rtR/BKbvkZ5Y= X-Received: by 10.46.68.138 with SMTP id b10mr198974ljf.123.1520940561242; Tue, 13 Mar 2018 04:29:21 -0700 (PDT) MIME-Version: 1.0 From: JinHyeock Choi Date: Tue, 13 Mar 2018 11:29:10 +0000 Message-ID: To: Bill Silverajan Cc: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="94eb2c1cdc02e0a0670567499136" Archived-At: Subject: Re: [core] Review of draft-silverajan-core-coap-protocol-negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Mar 2018 11:29:26 -0000 --94eb2c1cdc02e0a0670567499136 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bill >> - OCF uses a similar link attribute called =E2=80=9Ceps=E2=80=9D. > > The idea was to align "ol" with OCF's "eps" > so that per-resource alternate locations can also be supported. > This came from Dave's slides in IETF 99. See slide 19: > https://datatracker.ietf.org/meeting/99/materials/slides-99-core-consolidat= ed-slides / good that "ol" & "eps" would be aligned. They are almost equivalent. For example, ol=3Dhttp://[FDFD::123]:61616, coap://[2001:db8:f1::2]:5683 corresponds to "eps": [ {"ep": "http://[FDFD::123]:61616"}, {"ep": "coaps://[2001:db8:f1::2]:5683"} ] There still exisit some differences (e.g., URI in "ep" shall have IP address in its authority.), which, I hope, we would discuss in joint meeting next FRI. best regards JinHyeock 2018=EB=85=84 3=EC=9B=94 8=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 2:47, Bi= ll Silverajan =EB=8B=98=EC=9D=B4 =EC=9E=91=EC= =84=B1: > Hi Jaime, > > Thanks for reviewing the document! Below are responses to what you wrote: > > > Jaime Jim=C3=A9nez wrote: > > Dear authors, > > I had some time to review > draft-silverajan-core-coap-protocol-negotiation-07, below is the feedback= . > > * The RD option: > - have you thought about using this mechanism as a NAT traversal tool? > > It potentially can, if the RD is reachable by both client and server, and > there is some sort of keep-alive mechanism at the NAT. There was also a > discussion about a potential "coap+at", or an "all-transports" happy > eyeballs approach based on Thin ICE which might also help. > > - what happens if any of the context on =E2=80=9Cat=E2=80=9D is different= than the one > used to register the endpoint. > > If you're referring to the usage of "at" to the use of "con", it's > specifically because we wanted to avoid overloading the semantics of "con= ", > which can be used by commissioning tools. So, you can have both parameter= s > present. > > - is the lifetime of the registration also carried to the other transport > (is the ep being registered on both transports)? > > In short, yes. We thought of introducing lifetime per transport but it > turned out to make it more complicated. The current approach allows the > server to update the "at" list every time it sends a registration update = on > RD. This way, transports discovered from RD are always available. > > - are security associations between client and server reset when switchin= g > transport? > > Currently, yes. There are no session resumption/information exchanged > between transports defined yet. > > - I think the lookup example could benefit from a more complex lookup, fo= r > instance using =E2=80=9Crt=E2=80=9D or =E2=80=9Cet=E2=80=9D with =E2=80= =9Ctt=E2=80=9D. > > That's a good idea and we introduced that now in version -08 > > > * Alternative transports option: > - I=E2=80=99m not sure about this but wouldn=E2=80=99t this force to mand= ate specific CoAP > ports per transport? > > Yes they should be standard, but the idea was also to show non-standard > ports as there will always be endpoints exposing transports on different > ports than the standard ones > > - How large can the payload get? How many alternative transports are > there? Can=E2=80=99t we assume that we keep the scheme and simply answer = with the > transport supported? > > We can't do that all the time and elide the authority. For example > supporting sms, you'd have a different authority. There could also be man= y > alternative transports available, e.g. exposing on different ports. > > * =E2=80=9Col=E2=80=9D attribute: > - typo: availabilty > > Thanks, fixed. > > - this option, with no comment to how the context should be the same can > redirect a client to another server, right? Is that what we want? > > Not necessarily to another server but to another location, could be hoste= d > on the same server. Obviously, if the authority changes, the security > considerations for these kinds of alternate endpoints (that OCF also > proposed) should be looked at more carefully. > > - OCF uses a similar link attribute called =E2=80=9Ceps=E2=80=9D. > > The idea was to align "ol" with OCF's "eps" so that per-resource alternat= e > locations can also be supported. This came from Dave's slides in IETF 99. > See slide 19: > https://datatracker.ietf.org/meeting/99/materials/slides-99-core-consolid= ated-slides/ > > > - there should at least exist an informative ref to core-link format. > > I missed this comment for -08, sorry. Will be added for -09. > > > The security considerations part will require quite a bit of work. > > Particularly for alternate locations, agree on this. > > Implications on ETCH? > > Did you mean using FETCH to request for alternate locations? That would > work as a substitute for the Alternative-transports Option, if we can > devise a CoRE link that can express alternate transport endpoints on a > server. > > This draft is intended as informational, however at some point we should > have some normative text too for implementors, right? > > That would be great. Also for some feedback from implementers! > > Best regards, > Bill > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --94eb2c1cdc02e0a0670567499136 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bill

>> - OCF uses a similar link attribute called =E2=80= =9Ceps=E2=80=9D.
>
> The idea was to align "ol" with OCF's "eps" > so that per-resource alternate locations can also be supported.
> This came from Dave's slides in IETF 99. See slide 19:
> https://datatracker.ietf.org/meeting/99/material= s/slides-99-core-consolidated-slides/

good that "ol" & "eps" would be alig= ned. They are almost equivalent.=C2=A0
For example,

=C2=A0=C2=A0=C2=A0 ol=3Dhttp://[FDFD::123]:61616, coap://[20= 01:db8:f1::2]:5683

corresponds to

=C2=A0=C2=A0=C2=A0 "eps": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {"ep": "http://[FDFD::123]:61= 616"},
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {"ep": "coaps://[2001:db8:f1:= :2]:5683"}
=C2=A0=C2=A0=C2=A0 ]

There still exisit some differences
(e.g., URI in "ep" shall have IP address in its authority.),
which, I hope, we would discuss in joint meeting next FRI.

best regards

JinHyeock


=C2=A0


2018=EB=85=84 3=EC= =9B=94 8=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 2:47, Bill Silverajan <= bilhanan.silverajan@tut.fi>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
=20 =20 =20

Hi Jaime,

Thanks for reviewing the document! Below are responses to what you wrote:


Jaime Jim=C3=A9nez wrote:
=20
Dear authors,

I had some time to review draft-silverajan-core-coap-protocol-negotiation-07, below is the feedback.

* The RD option:=C2=A0
- have you thought about using this mechanism as a NAT traversal tool?
It potentially can, if the RD is reachable by both client and server, and there is some sort of keep-alive mechanism at the NAT. There was also a discussion about a potential "coap+at", or a= n "all-transports" happy eyeballs approach based on Thin ICE wh= ich might also help.
- what happens if any of the context on =E2=80=9Cat=E2=80=9D is different than the one used to register the endpoint.
If you're referring to the usage of "at" to the use of &q= uot;con", it's specifically because we wanted to avoid overloading the semantics of "con", which can be used by commissioning tools. So, you can = have both parameters present.

- is the lifetime of the registration also carried to the other transport (is the ep being registered on both transports)?
In short, yes. We thought of introducing lifetime per transport but it turned out to make it more complicated. The current approach allows the server to update the "at" list every time it sends= a registration update on RD. This way, transports discovered from RD are always available.
- are security associations between client and server reset when switching transport?
Currently, yes. There are no session resumption/information exchanged between transports defined yet.
- I think the lookup example could benefit from a more complex lookup, for instance using =E2=80=9Crt=E2=80=9D or =E2= =80=9Cet=E2=80=9D with =E2=80=9Ctt=E2=80=9D.
That's a good idea and we introduced that now in version -08


* Alternative transports option:
- I=E2=80=99m not sure about this but wouldn=E2=80=99t this forc= e to mandate specific CoAP ports per transport?
Yes they should be standard, but the idea was also to show non-standard ports as there will always be endpoints exposing transports on different ports than the standard ones

- How large can the payload get? How many alternative transports are there? Can=E2=80=99t we assume that we k= eep the scheme and simply answer with the transport supported?

We can't do that all the time and elide the authority. For example supporting sms, you'd have a different authority. There could also be many alternative transports available, e.g. exposing on different ports.

* =E2=80=9Col=E2=80=9D attribute:
- typo: availabilty
Thanks, fixed.

- this option, with no comment to how the context should be the same can redirect a client to another server, right? Is that what we want?
Not necessarily to another server but to another location, could be hosted on the same server. Obviously, if the authority changes, the security considerations for these kinds of alternate endpoints (that OCF also proposed) should be looked at more carefully.

- OCF uses a similar link attribute called =E2=80=9Ceps=E2=80=9D= .
The idea was to align "ol" with OCF's "eps" so = that per-resource alternate locations can also be supported. This came from Dave's slides in IETF 99. See slide 19: https://datatracker.ietf.org/meeting/99/materials/s= lides-99-core-consolidated-slides/


-=C2=A0ther= e should at least exist an informative ref to core-link format.
I missed this comment for -08, sorry. Will be added for -09.


The security considerations part will require quite a bit of work.
Particularly for alternate locations, agree on this.
Implications on ETCH?
Did you mean using FETCH to request for alternate locations? That would work as a substitute for the Alternative-transports Option, if we can devise a CoRE link that can express alternate transport endpoints on a server.

This draft is intended as informational, however at some point we should have some normative text too for implementors, right?

That would be great. Also for some feedback from implementers!

Best regards,
Bill

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

--94eb2c1cdc02e0a0670567499136-- From nobody Tue Mar 13 12:29:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356FC129C6C for ; Fri, 9 Mar 2018 01:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 366mhBC-QJq6 for ; Fri, 9 Mar 2018 01:34:44 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC88126C83 for ; Fri, 9 Mar 2018 01:34:44 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 91095B81706; Fri, 9 Mar 2018 01:34:25 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, cabo@tzi.org, jaime@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: mohamed.boucadair@orange.com, core@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180309093425.91095B81706@rfc-editor.org> Date: Fri, 9 Mar 2018 01:34:25 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 13 Mar 2018 12:29:45 -0700 Subject: [core] [Technical Errata Reported] RFC7252 (5284) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Mar 2018 09:34:46 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5284 -------------------------------------- Type: Technical Reported by: Mohamed Boucadair Section: 5.3.1 Original Text ------------- The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique. Corrected Text -------------- The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique per request. Notes ----- Multiple requests may be active for a given source/destination endpoint pair. The OLD text is thus broken. The NEW text is aligned with the definition of the Token: A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID". Further, using the same token for a given source/destination endpoint pair have some implications, for example, for applications which require the support of multiple observe queries because RFC7641 states the following: The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Mar 14 01:08:37 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00A412025C for ; Wed, 14 Mar 2018 01:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 8hRU5gD2ghSa for ; Wed, 14 Mar 2018 01:08:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 5D60E1200C5 for ; Wed, 14 Mar 2018 01:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521014909; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1ZdkQedAUFylBAx5E6ZiHfBA8AXjKZ5+nLSX1eByvQ8=; b=bfc7EGXh4mVJY9X5Avci4S7GlOch5UIickaALUK7hQS/ZuWS+01AsmJ3XYvCw7a8 rrtzFX+1/pstoPBaHNBNwfToh0iUD28+X2o43vumNh2jxPg4r4BlXJQ13HmB9s8t GmjpnnhkfBAppQvHP0F7rNfrPtNE9qnpJ1P8fNb3wVY=; X-AuditID: c1b4fb30-6ebff7000000095a-1e-5aa8d87dce2c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.CC.02394.D78D8AA5; Wed, 14 Mar 2018 09:08:29 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 09:07:19 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: Need for random OSCORE Sender IDs? Thread-Index: AQHTu2t50GyYRARGo0+FjCNvNmdxzg== Date: Wed, 14 Mar 2018 08:07:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.252.126.178] Content-Type: text/plain; charset="utf-8" Content-ID: <5EC4D872EE5BB64AB09758D227D57CA6@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7t27tjRVRBnen6Fnse7ue2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGeePvGIq+MFW8e3+FPYGxgdsXYycHBICJhJrz/1lBrGFBA4z StxdmARhL2GU2L2eH8RmE3CReNDwiAnEFhFQlth85jUjiC0soC1x5uRkRoi4gcSqBR+hbD2J KfOfgs1kEVCVWHB4NwuIzStgIfFzwyKwOKOAmMT3U2vAZjILiEvcejKfCeIeAYkle84zQ9ii Ei8f/2MFsUWBZu7taYe6WUni9uYG9i5GDqBeTYn1u/QhxlhLbOvpZYGwFSWmdD9kh1grKHFy 5hOWCYwis5Bsm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERgN B7f8NtjB+PK54yFGAQ5GJR7eyxdWRAmxJpYVV+YeYpTgYFYS4d0qAxTiTUmsrEotyo8vKs1J LT7EKM3BoiTOe9KTN0pIID2xJDU7NbUgtQgmy8TBKdXAOPtG1z6jk09XXH6d/05k5aIfO+O1 ri70/vnOrJyHfdaxY3w25pqNjWu4JzJlPWe2f5HOOs0t/5rKEjvxmz535t0yb912/eAss8/M UnHL99Yk3p4z1adia9yrtQbndvvm2LDs04tMEvZqSzmc37rORD7xS6rmnkdy9bveK2g2Hn/8 csGv9afmPFJiKc5INNRiLipOBAATFKXUggIAAA== Archived-At: Subject: [core] Need for random OSCORE Sender IDs? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Mar 2018 08:08:35 -0000 QWxsLA0KDQpPbmUgSUVTRyByZXZpZXcgY29tbWVudCBvbiBPU0NPUkUgcmVsYXRlZCB0byB0aGUg dXNlIG9mIHJhbmRvbSBTZW5kZXIgSURzLg0KDQpBcyBhIHJlbW5hbnQgZnJvbSBwcmV2aW91cyB2 ZXJzaW9ucyB0aGUgZHJhZnQgc3BlYWtzIGFib3V0ICJ1bmlmb3JtbHkNCnJhbmRvbSBkaXN0cmli dXRlZCBieXRlIHN0cmluZ3MgaWYgdGhlIHByb2JhYmlsaXR5IG9mIGNvbGxpc2lvbnMgaXMNCm5l Z2xpZ2libGXigJ0uIFdpdGggdGhlIGRlZmF1bHQgQUVBRCBhbGdvcml0aG0gdGhlIGN1cnJlbnQg YXZhaWxhYmxlIHNpemUgb2YNClNlbmRlciBJRCBpcyA3IGJ5dGVzLg0KDQpRdWVzdGlvbjogSXMg YW55b25lIGludGVyZXN0ZWQgaW4gZGVwbG95bWVudHMgd2hpY2ggbXVzdCBoYXZlIGxhcmdlIHJh bmRvbQ0KU2VuZGVyIElEcywgb3IgY2FuIHdlIGFzc3VtZSB0aGF0IHVuaXF1ZSBTZW5kZXIgSURz IGFyZSBhdmFpbGFibGUgb3INCmFzc2lnbmVkL2FncmVlZCwgZS5nLiBhdCB0aGUgc2FtZSB0aW1l IHdoZW4gdGhlIE1hc3RlciBTZWNyZXQgaXM/DQoNClVubGVzcyBzb21lb25lIG9iamVjdHMgd2Ug d2lsbCByZW1vdmUgdGhlIGZvcm11bGF0aW9uIGFib3V0IHJhbmRvbSBTZW5kZXINCklEcy4NCg0K DQpSZWdhcmRzDQpHw7ZyYW4NCg0K From nobody Wed Mar 14 07:38:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B3F1273B1 for ; Wed, 14 Mar 2018 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 OS2xId3ONmqI for ; Wed, 14 Mar 2018 07:38:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 A6653127337 for ; Wed, 14 Mar 2018 07:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521038281; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UKuDaE+CjMECxFAJ0tODBZxv7bFBadwXtQPfUByc6JQ=; b=DNFFUhw/cJnij9cnaZrEhQ6gT2Bjq6B8n1OvI+YKPRsbt2EdLy261bBUJwsXwQNn FEqFHI5zCW3Z0xhyQQWm3wpOj4fhmMDzk+aEEPRMYl8xKJlLAfPpXw/VZdB65PJO n00QG0yTTECYIJVdlWwzW74e1rSSD00fygVflf/La6U=; X-AuditID: c1b4fb25-a4a959c000006222-43-5aa933c9cf21 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 53.1C.25122.9C339AA5; Wed, 14 Mar 2018 15:38:01 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 15:37:58 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: OSCORE Header Compression Thread-Index: AQHTu6ILbY+2f1p+t06a9q9bWQa9bQ== Date: Wed, 14 Mar 2018 14:37:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7tO5J45VRBkfvW1nse7ue2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGS2fd7EU3OKtaJnN08C4hreLkZNDQsBE4vP/k4xdjFwcQgKH GSVmvz/ECuEsYZTY//shM0gVm4CLxIOGR0wgtoiAssTmM68ZQWxhASWJP1dfsEHE1SWWrHwA 1MwBZOtJtK5JBAmzCKhKnH2xFqycV8BC4s7qNawgNqOAmMT3U2vARjILiEvcejKfCeIgAYkl e84zQ9iiEi8f/wOrFwUaubennQ0irijx8dU+RpBVzAKaEut36UOMsZZ4MGkr1EhFiSndD9kh 1gpKnJz5hGUCo8gsJNtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWW bGIERsPBLb9VdzBefuN4iFGAg1GJh7cAGCVCrIllxZW5hxglOJiVRHid+IBCvCmJlVWpRfnx RaU5qcWHGKU5WJTEeecIt0cJCaQnlqRmp6YWpBbBZJk4OKUaGNPZp4QcSFh2m/H5scTrPVcb zBomOhQZRCge4TtzZf+EAM1PxV0KXScUVc1japdN/rgkeh/PrI+P6i9x8Wgrdro4cvV8MpAy VdwT76ei2jJtU9b9czxVv34wPjnI9pVrQQhjU3RKXGKJfIhd9LPet8ujNCfcf3t44gOL62+e a64WVc/eyL27WomlOCPRUIu5qDgRAADYmq6CAgAA Archived-At: Subject: [core] OSCORE Header Compression X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Mar 2018 14:38:06 -0000 QWxsLA0KDQpBbm90aGVyIElFU0cgcmV2aWV3IGNvbW1lbnQsIHNlZSBiZWxvdy4gV2UgY2VydGFp bmx5IGhhdmUgZGlzY3Vzc2VkDQptZXNzYWdlIHNpemUgb3B0aW1pc2F0aW9ucyBvbiB0aGUgQ09S RSBsaXN0LCBidXQgSSBjb3VsZG7igJl0IHJlY2FsbCBpZiB0aGlzDQpwYXJ0aWN1bGFyIG9wdGlt aXphdGlvbiB3YXMgZGlzY3Vzc2VkIHNvIEkgZm9yd2FyZCB0aGUgY29tbWVudDoNCg0KLSBEbyB5 b3UgYWdyZWUgdGhhdCB0aGlzIG9wdGltaXNhdGlvbiBtYXR0ZXJzPw0KDQpodHRwczovL2NvcmUt d2cuZ2l0aHViLmlvL29zY29hcC9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5Lmh0bWwj cmZjLnMNCmVjdGlvbi42DQoNCg0KKEFzIGEgY29tcGFyaXNvbiwgRFRMUyAxLjMgaW50cm9kdWNl cyBhIHNob3J0IGhlYWRlciB0byBzYXZlIG9mIHRoZSBvcmRlcg0Kb2YgNSBieXRlcy4pDQoNClJl Z2FyZHMsDQpHw7ZyYW4NCg0KDQpPbiAyMDE4LTAzLTA4IDA4OjM4LCAiQWRhbSBSb2FjaCIgPGFk YW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4tDQo+DQo+ wqc2IGFuZCBpdHMgc3Vic2VjdGlvbnM6DQo+DQo+VGhlIHVzZSBvZiBhIGJlc3Bva2UgcHJvZmls ZSBvZiBDT1NFIGFkZHMgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSB0bw0KPm9zdGVuc3RpYmx5 IHJlc291cmNlLWxpbWl0ZWQgZGV2aWNlIGZvciB3aGF0IGFwcGVhcnMgdG8gYmUgdmVyeSBsaXR0 bGUNCj5nYWluLiBJbg0KPnRoZSBleGFtcGxlcyBnaXZlbiwgc2F2aW5ncyBvZiA0IHRvIDcgYnl0 ZXMgYXJlIGRlbW9uc3RyYXRlZCwgd2hpY2ggc2VlbXMNCj50bw0KPmhhcmRseSB3YXJyYW50IHRo ZSBhZGRpdGlvbiBvZiB0aGlzIG1lY2hhbmlzbS4gVGhlc2UgZG8gbm90IGFwcGVhciB0byBiZQ0K PmRlZ2VuZXJhdGUgY2FzZXMsIHNvIEkgY2FuJ3QgaW1hZ2luZSB0aGF0IGNvbXByZXNzaW9uIHBl cmZvcm1hbmNlIHVuZGVyDQo+cmVhbC13b3JsZCBjb25kaXRpb25zIHdvdWxkIGJlIG11Y2ggYmV0 dGVyLiAgV2FzIHRoZXJlIGFuIGV4cGxpY2l0DQo+ZGlzY3Vzc2lvbg0KPmluIHRoZSB3b3JraW5n IGdyb3VwIHJlZ2FyZGluZyB0aGlzIGNvbXBsZXhpdHkvd2lyZS1zaXplIHRyYWRlLW9mZj8NCj4N Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPi0NCg0K From nobody Wed Mar 14 08:40:59 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCD412AF83 for ; Wed, 14 Mar 2018 04:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-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 f0VpNuukzM-N for ; Wed, 14 Mar 2018 04:58:54 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EF5127286 for ; Wed, 14 Mar 2018 04:58:54 -0700 (PDT) Received: from fe0vm1649.rbesz01.com (lb41g3-ha-dmz-psi-sl1-mailout.fe.ssn.bosch.com [139.15.230.188]) by si0vms0217.rbdmz01.com (Postfix) with ESMTPS id 401VcX4TBPz4f3kSC; Wed, 14 Mar 2018 12:58:52 +0100 (CET) Received: from fe0vm1740.rbesz01.com (unknown [10.58.172.176]) by fe0vm1649.rbesz01.com (Postfix) with ESMTPS id 401VcX47mGz20; Wed, 14 Mar 2018 12:58:52 +0100 (CET) X-AuditID: 0a3aad14-5cfff7000000330d-bd-5aa90e7d3d30 Received: from fe0vm1652.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm1740.rbesz01.com (SMG Outbound) with SMTP id 57.BA.13069.D7E09AA5; Wed, 14 Mar 2018 12:58:53 +0100 (CET) Received: from SI-MBX2033.de.bosch.com (si-mbx2033.de.bosch.com [10.3.230.36]) by fe0vm1652.rbesz01.com (Postfix) with ESMTPS id 401VcX2LfPzBctd; Wed, 14 Mar 2018 12:58:52 +0100 (CET) Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2033.de.bosch.com (10.3.230.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Wed, 14 Mar 2018 12:58:52 +0100 Received: from SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c]) by SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c%4]) with mapi id 15.01.1415.002; Wed, 14 Mar 2018 12:58:52 +0100 From: "Kraus Achim (INST/ECS4)" To: RFC Errata System , "zach.shelby@arm.com" , "hartke@tzi.org" , "cabo@tzi.org" , "ben@nostrum.com" , "aamelnikov@fastmail.fm" , "adam@nostrum.com" , "cabo@tzi.org" , "jaime@iki.fi" CC: "mohamed.boucadair@orange.com" , "core@ietf.org" Thread-Topic: [core] [Technical Errata Reported] RFC7252 (5284) Thread-Index: AQHTuwGrQ6udEjsE5EGyRvMUl7bu96PPoTww Date: Wed, 14 Mar 2018 11:58:51 +0000 Message-ID: <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com> References: <20180309093425.91095B81706@rfc-editor.org> In-Reply-To: <20180309093425.91095B81706@rfc-editor.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.82.203] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA22Tf0wbZRjHee+u7VF75LjC+lAhwzpcogGBzezcFI0m2hij/qExNlncYQ9a oS32Cg6cCaJjwDSZDNhWGT8mqUA62GRl3YCVlemkLE7NxupgZhuMFFjd3IS4CMQrB6N/+M/l eb/P83m+z/u8ORJnpkktabY6eLuVK9TJlYRy69GU9E/jOgyZZ0/Esb47foztXzyiYJurRxTs ubprMvZMuBtne/fPYOxQIJUdCt9SsBW+OTn72+ik4kWl3t3kRvpTgUG5vq3tAaYfmmsl9M5T k4T+i6lhub688keZvuGI+S3SoHzOyBeaS3j70zk7lKaOqV1FdSk7v/bElqNLmhoUSwK9GUYH 9hA1SEky9AEMunpnFdKhD8Hc6L2VQxjBjboAkg79CMY6g4oIL6e3Qm3L0HJVAn0Lgwr3nCyS wGkjDN5oRpFYTefA+Us+LBIn0C9Az92TK3E27B47uFxD0GngHO8mIjFFb4ObNZXLNQy9BWpa j4oGJBlLs/Bt+PWIjOgUOHbsIi5ZaeDqZDMm3YeGtn5JBzoRpieWZFKcCr3thwipPgOC9XVy KX4KXK2zuGQbD8OHJol9SOOMauuMQpxRiDMKaUFEJ0rM4zNLLFlbNmdm2HN5oSwzK+MDm+V7 JD14ghe1j7zjRzSJdCrqcEyHgZFxJUKpxY+eITFdIuWrazcwcbk2Y6mJE0zv24sLeUGnpVBM TAyjfigLxbkWsyCYbVY/AhLXJVCeZJGjjFxpGW+3SZgfPUoSOg31pXGXgaHzOQdfwPNFvH01 u40kdUAtqcQZ4u18Pr8zz1zoWE3rUiTPddGZaFuMjPWjTaRK9K6lxBaUUMRZBHP+Cp4k4cyq uoYG0Jvk/MD1SpwMhmbF7+l9X+3FGcJqs/JaDZUd6UVHKFOx9eE02mRqu8plYBKjEmsdZ1AQ iftUU5sisEr8x9bmAMqrbnyPiV8R16DsNpGha+Pgn9YCaLp/GYH7xG0E7dUeDB7s+QWDqpsh HPyuKwSM/zpPQF/LbhksnJ+XQWjqnBy8wU4F9Ax2KaBvyktC6I+LsdDc2KkC3zdiz9DSDA09 la1quBPwJEDw9lAiHGxwaWD/YhVA/fGfk6DhrlsLx13/amGh589kCF6/vB58Uz+lgmf4Sios dXmfAG+DZ+OMuGNM3LG5N/K+goNz/M+OV9S1y2nLkSM97/NPnj9QPr/I/7Wj+pXxV2caax57 JIx/yMwjx7V4r9r0bllF+KOXTycX3KtvKeCubvx43VnZaDGF3hCMBWkbxt1vf5az/kLoDJ1X 4rEtJd3/2zXxw4TDwj6+NxCzUJ3XPJA2VnWy/vftF6qe7V546TujpWlDPjcyevg1G5s+3VGt IwQTl/Ukbhe4/wARPfp+/AQAAA== Archived-At: X-Mailman-Approved-At: Wed, 14 Mar 2018 08:40:58 -0700 Subject: Re: [core] [Technical Errata Reported] RFC7252 (5284) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Mar 2018 11:58:57 -0000 Hi, if the current definition "tokens currently in use" is interpreted as for "= all pending requests", I can't see, that adding "per request" improves the = RFC.=20 If something is added, I would recommend to precise that also with the time= -scope,=20 e.g. "per simultaneous request". Mit freundlichen Gr=FC=DFen / Best regards Achim Kraus (INST/ECS4)=20 Bosch=A0Software Innovations=A0GmbH | Stuttgarter Stra=DFe 130 | 71332 Waib= lingen | GERMANY | www.bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B=20 Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L=FCcke; Gesch=E4ftsf=FChrung:= Dr. Stefan Ferber, Michael Hahn -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Freitag, 9. M=E4rz 2018 10:34 To: zach.shelby@arm.com; hartke@tzi.org; cabo@tzi.org; ben@nostrum.com; aam= elnikov@fastmail.fm; adam@nostrum.com; cabo@tzi.org; jaime@iki.fi Cc: mohamed.boucadair@orange.com; core@ietf.org; rfc-editor@rfc-editor.org Subject: [core] [Technical Errata Reported] RFC7252 (5284) The following errata report has been submitted for RFC7252, "The Constraine= d Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5284 -------------------------------------- Type: Technical Reported by: Mohamed Boucadair Section: 5.3.1 Original Text ------------- The client SHOULD generate tokens in such a way that tokens currently in us= e for a given source/destination endpoint pair are unique. Corrected Text -------------- The client SHOULD generate tokens in such a way that tokens currently in us= e for a given source/destination endpoint pair are unique per request. Notes ----- Multiple requests may be active for a given source/destination endpoint pai= r. The OLD text is thus broken. The NEW text is aligned with the definition of the Token: A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID". Further, using the same token for a given source/destination endpoint pair = have some implications, for example, for applications which require the sup= port of multiple observe queries because RFC7641 states the following: The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party can log in to change the status and ed= it the report, if necessary.=20 -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 14 08:41:04 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303581242EA; Wed, 14 Mar 2018 05:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 kp4u6wCXtHW3; Wed, 14 Mar 2018 05:23:30 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0971271DF; Wed, 14 Mar 2018 05:23:30 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id BB079A0850; Wed, 14 Mar 2018 13:23:28 +0100 (CET) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.83]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 6D26C1A0070; Wed, 14 Mar 2018 13:23:28 +0100 (CET) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORMAF.corporate.adroot.infra.ftgroup ([fe80::e1dd:62fe:d378:e3f8%21]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 13:23:28 +0100 From: To: "Kraus Achim (INST/ECS4)" , RFC Errata System , "zach.shelby@arm.com" , "hartke@tzi.org" , "cabo@tzi.org" , "ben@nostrum.com" , "aamelnikov@fastmail.fm" , "adam@nostrum.com" , "cabo@tzi.org" , "jaime@iki.fi" CC: "core@ietf.org" , "dots@ietf.org" Thread-Topic: [core] [Technical Errata Reported] RFC7252 (5284) Thread-Index: AQHTt4ndJXGy2My7rUmHIFbO9dEyFKPPl8uAgAAVL1A= Date: Wed, 14 Mar 2018 12:23:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEDFAB6@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <20180309093425.91095B81706@rfc-editor.org> <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com> In-Reply-To: <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 14 Mar 2018 08:40:58 -0700 Subject: Re: [core] [Technical Errata Reported] RFC7252 (5284) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Mar 2018 12:23:32 -0000 Hi Achim, (ccing DOTS WG) Thank you for sharing your thoughts. I'm personally OK with any wording which makes clear that distinct tokens a= re generated to differentiate among concurrent requests involving the same = source/destination endpoints. =20 I'm not sure to understand what you meant by "per simultaneous request", th= ough. =20 Cheers, Med > -----Message d'origine----- > De=A0: Kraus Achim (INST/ECS4) [mailto:Achim.Kraus@bosch-si.com] > Envoy=E9=A0: mercredi 14 mars 2018 12:59 > =C0=A0: RFC Errata System; zach.shelby@arm.com; hartke@tzi.org; cabo@tzi.= org; > ben@nostrum.com; aamelnikov@fastmail.fm; adam@nostrum.com; cabo@tzi.org; > jaime@iki.fi > Cc=A0: BOUCADAIR Mohamed IMT/OLN; core@ietf.org > Objet=A0: RE: [core] [Technical Errata Reported] RFC7252 (5284) >=20 > Hi, >=20 > if the current definition "tokens currently in use" is interpreted as for > "all pending requests", I can't see, that adding "per request" improves t= he > RFC. > If something is added, I would recommend to precise that also with the ti= me- > scope, > e.g. "per simultaneous request". >=20 > Mit freundlichen Gr=FC=DFen / Best regards >=20 > Achim Kraus >=20 > (INST/ECS4) > Bosch=A0Software Innovations=A0GmbH | Stuttgarter Stra=DFe 130 | 71332 Wa= iblingen | > GERMANY | www.bosch-si.com >=20 > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L=FCcke; Gesch=E4ftsf=FChrun= g: Dr. > Stefan Ferber, Michael Hahn >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of RFC Errata System > Sent: Freitag, 9. M=E4rz 2018 10:34 > To: zach.shelby@arm.com; hartke@tzi.org; cabo@tzi.org; ben@nostrum.com; > aamelnikov@fastmail.fm; adam@nostrum.com; cabo@tzi.org; jaime@iki.fi > Cc: mohamed.boucadair@orange.com; core@ietf.org; rfc-editor@rfc-editor.or= g > Subject: [core] [Technical Errata Reported] RFC7252 (5284) >=20 > The following errata report has been submitted for RFC7252, "The Constrai= ned > Application Protocol (CoAP)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5284 >=20 > -------------------------------------- > Type: Technical > Reported by: Mohamed Boucadair >=20 > Section: 5.3.1 >=20 > Original Text > ------------- > The client SHOULD generate tokens in such a way that tokens currently in = use > for a given source/destination endpoint pair are unique. >=20 > Corrected Text > -------------- > The client SHOULD generate tokens in such a way that tokens currently in = use > for a given source/destination endpoint pair are unique per request. >=20 > Notes > ----- > Multiple requests may be active for a given source/destination endpoint p= air. > The OLD text is thus broken. >=20 > The NEW text is aligned with the definition of the Token: >=20 > A token is intended for use as a client-local identifier for > differentiating between concurrent requests (see Section 5.3); it > could have been called a "request ID". >=20 > Further, using the same token for a given source/destination endpoint pai= r > have some implications, for example, for applications which require the > support of multiple observe queries because RFC7641 states the following: >=20 > The entry in the list of observers is keyed by the client endpoint > and the token specified by the client in the request. If an entry > with a matching endpoint/token pair is already present in the list > (which, for example, happens when the client wishes to reinforce > its interest in a resource), the server MUST NOT add a new entry > but MUST replace or update the existing one. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party can log in to change the status = and > edit the report, if necessary. >=20 > -------------------------------------- > RFC7252 (draft-ietf-core-coap-18) > -------------------------------------- > Title : The Constrained Application Protocol (CoAP) > Publication Date : June 2014 > Author(s) : Z. Shelby, K. Hartke, C. Bormann > Category : PROPOSED STANDARD > Source : Constrained RESTful Environments APP > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 14 09:06:15 2018 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 777861252BA; Wed, 14 Mar 2018 09:06:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152104356943.25110.11529556530791775941@ietfa.amsl.com> Date: Wed, 14 Mar 2018 09:06:09 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 16:06:10 -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 WG of the IETF. Title : Object Security for Constrained RESTful Environments (OSCORE) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-10.txt Pages : 64 Date : 2018-03-14 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-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 Wed Mar 14 10:51:43 2018 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 B6068120227; Wed, 14 Mar 2018 10:51:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-object-security@ietf.org, Carsten Bormann , jaime.jimenez@ericsson.com, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152104990173.25169.14692784082106871720.idtracker@ietfa.amsl.com> Date: Wed, 14 Mar 2018 10:51:41 -0700 Archived-At: Subject: [core] Adam Roach's No Objection on draft-ietf-core-object-security-10: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:51:42 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-object-security-10: 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-object-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS and comments. I continue to support EKR's DISCUSS and Martin Thomson's list of issues . From nobody Wed Mar 14 10:53:17 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B9D120227 for ; Wed, 14 Mar 2018 10:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 PxoWdwNvySYn for ; Wed, 14 Mar 2018 10:53:14 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 B0C6E120047 for ; Wed, 14 Mar 2018 10:53:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,306,1517871600"; d="scan'208";a="258311305" Received: from wifi-eduroam-84-058.paris.inria.fr ([128.93.84.58]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2018 18:53:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= In-Reply-To: Date: Wed, 14 Mar 2018 18:53:11 +0100 Cc: "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6159C926-5B14-4801-9F79-99C0E27B0911@inria.fr> References: To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] OSCORE Header Compression X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Mar 2018 17:53:16 -0000 Hi G=C3=B6ran, IIRC, the proposal for the OSCORE header compression came from 6TiSCH = where we are limited to 127-byte frames and often we do not support = fragmentation of IP packets. As we use OSCORE to transport network parameters needed by a new node = (i.e. pledge) to join the network (see = draft-ietf-6tisch-minimal-security), the OSCORE message (i.e. Join = Response) needs to fit into a single 127-byte frame, together with = CoAP/UDP+IPv6+6LoWPAN/802.15.4 headers. The packet carrying this message = is additionally source routed (RFC6554) down the RPL DODAG, where each = hop with the compression mechanism of RFC6554 adds typically around 2 = bytes, IIRC, as the longest-matching prefix between subsequent addresses = can be elided. How deep the 6TiSCH network (without fragmentation) can be is determined = by the size of the resulting OSCORE message (Join Response). The savings = of 4-7 bytes by OSCORE allow us to extend the physical range of the = network from 2 to 4 hops more, at a cost of ~30 lines of highly = unoptimized C code. With that compression performed, we can currently = form 6TiSCH networks up to 6 hops deep (results from the plugtest from = Prague in July 2017), and without we would be limited to 4 to 2 hops. I apologize for the imprecision in my figures, as I am writing from = memory based on the experience we gathered during the plugtests, but I = hope this illustrates the benefits and the involved implementation = complexity. Regards, Mali=C5=A1a > On 14 Mar 2018, at 15:37, G=C3=B6ran Selander = wrote: >=20 > All, >=20 > Another IESG review comment, see below. We certainly have discussed > message size optimisations on the CORE list, but I couldn=E2=80=99t = recall if this > particular optimization was discussed so I forward the comment: >=20 > - Do you agree that this optimisation matters? >=20 > = https://core-wg.github.io/oscoap/draft-ietf-core-object-security.html#rfc.= s > ection.6 >=20 >=20 > (As a comparison, DTLS 1.3 introduces a short header to save of the = order > of 5 bytes.) >=20 > Regards, > G=C3=B6ran >=20 >=20 > On 2018-03-08 08:38, "Adam Roach" wrote: >=20 >>=20 >> = --------------------------------------------------------------------------= >> - >>=20 >> =C2=A76 and its subsections: >>=20 >> The use of a bespoke profile of COSE adds implementation complexity = to >> ostenstibly resource-limited device for what appears to be very = little >> gain. In >> the examples given, savings of 4 to 7 bytes are demonstrated, which = seems >> to >> hardly warrant the addition of this mechanism. These do not appear to = be >> degenerate cases, so I can't imagine that compression performance = under >> real-world conditions would be much better. Was there an explicit >> discussion >> in the working group regarding this complexity/wire-size trade-off? >>=20 >> = --------------------------------------------------------------------------= >> - >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 15 01:52:45 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3B812708C for ; Thu, 15 Mar 2018 01:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tutfi.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 3MYPqNXDypFC for ; Thu, 15 Mar 2018 01:52:41 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321BD12D87D for ; Thu, 15 Mar 2018 01:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tutfi.onmicrosoft.com; s=selector1-tut-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cxUmk1v6FWb/K8bhrew94YBEaNpEDEF/c4QOKBokmRo=; b=INFhysJeIL+ijcheIHZzF02u1miqxMVwOLgbJ5LWfwXDKPcBPXtisHiUAQKTILeyjE3lMg+TUylxekByGsZnAcFSksESdZnrOfKmAZHV+DtpoHXLcI/5yCIsU2gKlhl1LJqRTQo3tJ6hFaAC+P2U6CYJPGu9Co+9gswkAylpyic= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bilhanan.silverajan@tut.fi; Received: from dyn-159-165.public.tut.fi (130.230.159.165) by DB5PR02MB1078.eurprd02.prod.outlook.com (2a01:111:e400:52cd::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Thu, 15 Mar 2018 08:52:35 +0000 To: JinHyeock Choi Cc: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" References: From: Bill Silverajan Message-ID: <0cc8bfd6-2f50-83b6-d392-e80de133ce34@tut.fi> Date: Thu, 15 Mar 2018 10:52:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [130.230.159.165] X-ClientProxiedBy: HE1PR09CA0073.eurprd09.prod.outlook.com (2603:10a6:7:3d::17) To DB5PR02MB1078.eurprd02.prod.outlook.com (2a01:111:e400:52cd::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a8303420-51b4-4fcb-766a-08d58a5219bb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB5PR02MB1078; X-Microsoft-Exchange-Diagnostics: 1; DB5PR02MB1078; 3:Bv3OBo2z+dSVX4/2cPM0B6u5vHALBMT+DL1C6zx+h5tsisRp9IbndyRbN5MgdO0WiJAnn6wSGTGIm1KsiXQTwj08tqU3eA9+r90t1TsvC1+yk88/f6G9Y5VbqD1Ein+q3223LDQa6RUCOYX7BlssQe438cIHI+CdcoNLM+391AeQB5rWM2g4Q7pfpTjz4SazqylyejeuNNiHHbuPqYItZfMXzQ/oo+B1+ezcoESIcxsso92Xa9Rs+y+DCsHJsqHO; 25:oTpUdqDhMumJiqSH/8fJpFI0InN1idajA5AWMD23i9/YbxoUL24thUKtvMjinbBMh38BJ0kzgh8xbVr5IahwtQq+9FXsA8q/1n/zb9eg95RAYWd56QNV61fyDqiO3cM/ulod/ZTvzpbci2a2prg5HU8IYTLjcT3XzgkF6F1hMdbZ8b/bCniEcldKhpj4wNcj3/mjcy8JPyL8RdSqAh2UA4soSKGo4rvJmGh0P7QYRoqrpyyR0i2m/iVOEyePqhVsmNRFpVNXxzH1UVW3pcykXHzMl7LkUW4eFC3XWLc2o20srHjtdRWok+8TyX2PQKSnUGqo1cOWJXIezcwnE8GE0g==; 31:bVTsoqsA/R/F+BXaL/nPOyp6574EqHGL4gG96/fOeLULObSbfOui2DT8DxhlSw3oxnEnBkYTTm5cw95gRQDUIChoxExN6l2jH5gQsHtPHMTOD6jfA8pW63LoXdm4XHt2tYxj4SPERfl45jpiYCyYt4evSC5BgVupfmcsE//g3CA6d6L4yqEMCnXpown/eUYpxhTsRImk3JDLUPr1RqKkbhgu7xlDKJT6tGj41VWrgwg= X-MS-TrafficTypeDiagnostic: DB5PR02MB1078: X-Microsoft-Exchange-Diagnostics: 1; DB5PR02MB1078; 20:1451W4tZ3oqbnYf1go5QYv/dv+ntIGDngzPOw+I9Vpiqsj3+THvu+ISa6i93jI5UtSeZBHlcK4cdKQNcQBnjyf2BErQEDdBI/iDyF44ji0aQyszFwNh3fTp8A3pBZsLO0s+JO6M+8DnBsT1WZ4+mlXQflasAV7ZIOwThLtEJAxwYjgOFeIm2fA+9zRIFk8+SnSgJRcyVEFqgyjoNE/5sKhIgN+ZM5shN6X45HR7vFiNP94SC+SMApZJsOVSnHvSPItslD8rfQx2d3M92fzLsQ7L/yRusPmCOPXWT2OFOltji1/NZBVOv9w1/QRhbPrAZjFnio3IWPoo/UoGDP/asZw==; 4:BggFK9nsq+PeuptB9Xp8flIZZeoozTi6gu6mqE4wb3rz9bM29nC5F6+mx9zd5MnUdbtxnNvecMGYkbFDSGS2GgjWOokV2OIfKWXPkxufUhEI6Ji+KKgJV0G2PTaoscuZeyESyFSRtUMm16Pe49gR3sbfWzfayeJ2AUxlciJ7ymRsWDqWqSJLVKefjvvB0UsvO8prkkn/YHG9SEFtkuVdfFSIz1Ag7G6Vd6IWCXNmaHueTfGlAuqY6DWfSsg1OBFi641ATh5oE55b07KJFLKrRw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231221)(944501244)(52105095)(93006095)(93001095)(3002001)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB5PR02MB1078; BCL:0; PCL:0; RULEID:; SRVR:DB5PR02MB1078; X-Forefront-PRVS: 0612E553B4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(376002)(396003)(366004)(39380400002)(39850400004)(346002)(199004)(189003)(52146003)(47776003)(76176011)(23676004)(786003)(1411001)(74482002)(2870700001)(69596002)(6246003)(64126003)(33896004)(52116002)(2486003)(966005)(50466002)(86362001)(478600001)(7696005)(6306002)(3846002)(6116002)(25786009)(39060400002)(68736007)(386003)(66066001)(53936002)(6916009)(81166006)(81156014)(4326008)(19625305001)(6666003)(305945005)(8676002)(54906003)(97736004)(2950100002)(5660300001)(65826007)(31696002)(229853002)(6486002)(36756003)(8936002)(2906002)(26005)(65956001)(7736002)(31686004)(16526019)(186003)(65806001)(105586002)(106356001)(316002)(53416004)(67846002)(58126008)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR02MB1078; H:dyn-159-165.public.tut.fi; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: tut.fi does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjAyTUIxMDc4OzIzOlVwcTFEVHJ3aHVyK0FRb3JYOCtWZU1hNlE5?= =?utf-8?B?cCtucU1CRStqanZZMUYxUVdHZ01xd2RJWG9ra0N3L1ZrTjl6OVdwOUVxKy9s?= =?utf-8?B?bHpoZ21CTTk0c1VIcUhpcXlEdWpIYzBRTjNJbkFlK0MzTE1YV0VkOVBiVSsy?= =?utf-8?B?a2N4UWFsYVZwckNYQkRxdUVQVXY1MmZycWJVWmtnbC9iWjJjcFhlcWJrSXF1?= =?utf-8?B?bjR4SUJmM29XWUYyM3Y2WW1kTmM2ejVsekFhZEhOaG51L2hKTnd5Umt2ZUpX?= =?utf-8?B?QmoySHIrcHpJTUVQeUVROEg3aVVnb1J5RlFJTkVPb29TczVUVlA2VEZZekx2?= =?utf-8?B?TlBOMTlZd0dtdS9sdFBSYTMzcHZnQ3VQU0lCUFVDZWpydFJBRFBhOXlmZGh5?= =?utf-8?B?b0J1dFRiOHE4c1lZb24zdy9FU1kwYnBYbjUweFJma2pZV2FGNDJEK3ZLK09R?= =?utf-8?B?SnF6d3cxNG1Genl6T3V3N0V5V2o5MEpRK1IveEZkeDRnYkZpQlpETzh2aXdk?= =?utf-8?B?clZrSFBybmJLWktnc0w0Y29jMmNJazAyRlAzREQ1Z0ZBcVY4S0NFT0JIZVQ2?= =?utf-8?B?WkcxV0JyVVNFcHdlWFh5anc4bGpyYnd0LzFzbGNWUnMxRHlqTGhQRkd6cVc3?= =?utf-8?B?N2NGanNIZUU3UG9mckluRTErcE9EOFBDcEMvTndSTWRJellRWFNXK1ZiajRZ?= =?utf-8?B?ckZpZnZicXRKS09wUXpjOS9xS29BMlFQVlRlNy9ycWRBTnczM3BzUGRSNXk1?= =?utf-8?B?RmIxcmd1SS9kRE95Y2twU0V4SEUycnl1eEpQdXI4dFVXZ09WTS9tS1U4MVNn?= =?utf-8?B?bE44QTdCZCtDbkRXV3hmSVh0NS9vT0cvYXBLQ2Uwc2c4d05PdGpZdis5MmVq?= =?utf-8?B?TWhVZzVBbEt2SVk4WnJ1YVRYeWxlUUwxR25Nb0duclRUY2YydXlFTWhKUzk5?= =?utf-8?B?SmFpRkNLZDhjclpkWHVnT1R6aFI2d2FpVThDcDFVUmY0VTZxSXhzc2RNbVd5?= =?utf-8?B?MXJTQW5KczRodE01a0wyQk5zRGw5U2NUZ0oxdElCRVJsam9tdHVhRC9NTGl1?= =?utf-8?B?V1VsU3JaZFJjQ2ZQcGFYOXZaSjVjUUVmcW44U2RuaGNLcThvSU5zcDdCWE9w?= =?utf-8?B?anc2Yjd3RlVsbnhyTk5QVjdMTkNrUE9hdVZLdXNZRWJTTlY3aGE3QU52UEhN?= =?utf-8?B?cDFNUnF3bVNBZVpTeXQzYUR2c3JoTkJVZlBZSm5LK1NKZVk5YW1QdGJ4bDZI?= =?utf-8?B?VFJ2T2xvRmJSR0xkNFFRQnVoOWFGbXpiNW8rN3dJVjR5Ti9QRHVmcVFOb1Rx?= =?utf-8?B?SU1NelUyampuLzhtdnlXNXIwNjBEMHp6ek9ydFZrdFE3VVpsTnFRQ040L3ht?= =?utf-8?B?RW1uZ2xLaUE4QktWU1BtZ2Noa2xPNDZNOG1McUp0MDdlcTBvbFViT0NrR3BF?= =?utf-8?B?blk0K2N3N1VqZjFESkUxYUFTaTNsWG5LaHpFREV6M0hkelFPRDlZRzV6TXF2?= =?utf-8?B?WDBoVXNkL0EzNDVhZ2RoQThjVWxxNEsrcC9WV0RXd3k0MXdDcjYxZThEenVB?= =?utf-8?B?K3dwVk5YZ0xkNFpTZnFtYVBSQjFjUU5LZUxzTk5FLzlzNjltNGhMVkJaRE1p?= =?utf-8?B?Mkp3YU5YdVViTlk1clJnMFdGMlJGMlF3Y1JlMjlLeTRGTGo4RFhObFo4dm5Z?= =?utf-8?B?SlFVMkVxNDhEUGtGMkxua0h0Q0QwS1RDZjI3K0tISHlPRjdIL3ZKdkdNS0pR?= =?utf-8?B?M1JDU2ErcFFlY0pwejNROTd2bDhhL1VlMGRVdXN3SVVRSjQ1S2xZTFV4RlBi?= =?utf-8?B?WE5GWTJ3VWdBWjNzRGovUnQ1QWJpdlJiVkNQQTBhalJNYkdJdW04dFNtdmhm?= =?utf-8?B?ZmRsYk1LZU9oR05obnpFM2Q4VytqcTlFTG9lSTBub09oNEY1eUJCR2Myc3pX?= =?utf-8?B?TGl3SnIrN0t0Tms1dDdvQnFNWnQ1U1hKVWdxeFlkVjdvc1VlRFNUVVlUdmg5?= =?utf-8?B?a2FNVHMxekIvc2VUbGIyNTlzdjZRYmdRUEk3dnpORWtoTjFWUzF6N1h1SFpa?= =?utf-8?B?RWV2c2FTYlAxMVJ2QWFDcmtOcFVWR2tMemZ5dVd1NEVTNjRTdkE2YjByMlRX?= =?utf-8?B?aHg4WktyOHlsWVhWeTFaMGlwTmhYdEZ6ZjVSeUNvTHNHTkd0Tm9uTWI4Vy9G?= =?utf-8?B?dVQ1RFhmNjRpR01heVFqOGpLaWdBPT0=?= X-Microsoft-Antispam-Message-Info: w7GB8JndJ5gwLHlCjluBf+3JOpPQSNWREakgo0Hof9mC12vOWa+p1C684bJalY55UyU9B0MEi2je5eeAUp3spSoEOUVAiXY/drt/FT//ruF9bCgrQWcotzwwZG+JRR/t+LPMXipV76+uMFtLKNwpOndMjNUXG3WLqUYvv8K+djzRC/DuwLPoGHYdpAeKgn3v X-Microsoft-Exchange-Diagnostics: 1; DB5PR02MB1078; 6:XG+bZ1VGniEhnQW4d4k4cPUv21KElXwwPJY2318JZnLjgxkdVCDPr5nudy/ibN7WJUJuTjKzVBvZY4NglbJ7Up65EVn8KpeklJovt+J3aoYoV94AzYNIapZUYKNq4cP8J2bpb+Am3z8xv8VHRqBjRNmrFn+ENxvQAttRhSXPoTZhUGzRufgEycPyJD7KnxS4fz5cpVqKmPPQY6CoOyJmx2rGyaV95XJ6yNN9FZnulaIOOPOvFHJ7LRNKaOzFCTGb8tzi34b0fTsJ1FZi83d+kr9b33WMc/2DTNIblikuNtUbCVXZBV3tO/XUXeX8RC4/4gvqTxh1Z/h6VCybGRIN3x2CtBzWC52apgREMPNRb9k=; 5://Hyv0k87hubs5NjershQG3cL8vEuX3sp2SXqA+VNoRx3Ro6enjqOXBC4xaLFVZoqncsbY95Jqsh2H3tm38+CECwCxnU0BZI4UqjqhT+JnR+qIbvFcgu0k4TUb6Hq7AsrL+wLkpF0OKobP+UV9jhe/OWny9u8VpGvxrw91Ov64w=; 24:79szo7c79NReEkXyEpwEQ2UaSbU7oZ7YIU0C0OLk1DQkqiBg1lPkTIINAMmFA7H19midRoI5OvlazfMVyrGAcUuAx70/B0u5rBubx4zSz7U=; 7:jOyyBS4r7s0Lu1UNt2/3HE8qnsEeFFCBVXnqPj6tMtHynwpOTFqPSieHYj6BXuqGZucqWGXAdhJeWi8186M8fCMg1RSF/6aPcjCtCEM3J75Ms1+q2A2FNjt56bb1CgD8UMFs8L64psCMpsMfdgoB0fQH0bk7XQGyjQ56+CikJqYEzrkji2+5xpO7g9UUyoUv43C2XhZWIgxXUs38HtfmI6WZzzzup7oZI1PP9glsgs67Xhbs2on7uIrcDpl0Nt/K SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tut.fi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2018 08:52:35.3491 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a8303420-51b4-4fcb-766a-08d58a5219bb X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 271a0e2b-2a07-4d45-840b-ca860972fd60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR02MB1078 Archived-At: Subject: Re: [core] Review of draft-silverajan-core-coap-protocol-negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 15 Mar 2018 08:52:44 -0000 Hello JinHyeock, Thanks for your comments! JinHyeock Choi wrote: > good that "ol" & "eps" would be aligned. They are almost equivalent. > > For example, > >     ol=http://[FDFD::123]:61616, coap://[2001:db8:f1::2]:5683 > > corresponds to > >     "eps": [ >       {"ep": "http://[FDFD::123]:61616"}, >       {"ep": "coaps://[2001:db8:f1::2]:5683"} >     ] > That is good. Going forward, the mapping would become easier: We've defined "ol" to be repeatable instead of a comma separated list of base URIs. For example, https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation-08#section-6.1 > There still exisit some differences > (e.g., URI in "ep" shall have IP address in its authority.), > which, I hope, we would discuss in joint meeting next FRI. > If you are participating in IETF 101, we can also arrange a corridor discussion around this topic. I'd be interested in hearing your thoughts here too. Best regards, Bill From nobody Thu Mar 15 05:22:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5AE128961 for ; Thu, 15 Mar 2018 05:22:37 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 V-CO9ouv67vF for ; Thu, 15 Mar 2018 05:22:31 -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 EB6A31241F3 for ; Thu, 15 Mar 2018 05:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2FCMR1C015485 for ; Thu, 15 Mar 2018 13:22:27 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 40275H44QzzDXHL; Thu, 15 Mar 2018 13:22:27 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 542809345.656106-ae4037da44c1b3cf37fd0c175b27da7d Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Mar 2018 13:22:26 +0100 Message-Id: To: Core X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [core] CoRE @ IETF101 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 15 Mar 2018 12:22:37 -0000 The chairs have uploaded a draft agenda to https://datatracker.ietf.org/meeting/101/materials/agenda-101-core Please have a look and check whether =E2=80=94 your slot request is in there =E2=80=94 the time allocated is appropriate We=E2=80=99ll need to reduce the time on some items a bit so we have = more flextime at the end, so please do look if you can get useful work = done in less time as well as in more time=E2=80=A6 As usual, please also send the objectives you have for your slot to = core-chairs@ietf.org so we can include them in the agenda. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 15 07:32:25 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE75F12D88A for ; Thu, 15 Mar 2018 07:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 IeYWczWaYeYY for ; Thu, 15 Mar 2018 07:32:22 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91F212D959 for ; Thu, 15 Mar 2018 07:32:10 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 44F674961C for ; Thu, 15 Mar 2018 15:32:08 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 82EA561 for ; Thu, 15 Mar 2018 15:32:07 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3E3063A for ; Thu, 15 Mar 2018 15:32:07 +0100 (CET) Received: (nullmailer pid 18184 invoked by uid 1000); Thu, 15 Mar 2018 14:32:06 -0000 Date: Thu, 15 Mar 2018 15:32:06 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: <20180315143206.GA16657@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [core] arriving at BERT for early block requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 15 Mar 2018 14:32:24 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoAP-over-TCP authors and working group, during a RFC8323 interop, a question concerning BERT came up: Can a request block operation (say, a large PUT) be conducted with BERT by a TCP client without waiting for the CSM? If the client does not wait for the server's CSM, it can't know the Max-Message-Size, and whether the server indicates the Block-Wise-Transfer capability. The only way to send the PUT right away is to send an 1:(0/1/1024) regular block with szx=3D6. The server then sends back its CSM (say, MMS=3D64k and supporting block). Now who can take the started operation up to BERT? The server would send 2:(0/1/1024) acknowledging the first block, and the client preparing the next block "SHOULD [...] use the block size preferred by the server or a smaller one". Is BERT an exception to that rule, and if so, is that written somewhere? Or can such a transfer never become a BERT one, and clients with large requests should take the time to wait for the CSM rather than save a single round-trip and suffer the penalty of a dozens more due to limited block sizes? Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqqg+EACgkQOY0REtOk veFfqA/6A5zTyFfbqyI/gPAhBqhliebOhgQn9Cyk+67MfJYObh9/G4s5cLT5dfmp rzq6HL8x8+zzXiJZtpaEEAMerlI4tXyopZOH/7iBxkVqmkg954K3FgI+yZaGkI8K 7ZL3+43I/g/+NWaumHZ7GjLmpipq5b3ppsbrCyymTVRLrQOf95orwQsVI0oBxEyo nwLlYtu4RWCj0zCBuvBrHrKEtHZmKR+SVhna69pE1iGhFWCoF1fxh0r9IR7TEtq3 +QgsIpB+jufrRG+809dwzvrguAKAJbUyly4LOCvdKqnd6iEl1QvceFw1EwQMWI8z cI5DGe8Z5V9qKf2UtJnf2q23KFzahIFBLWuvu9yBplhzhePOTr3mpaTu9+crX2u+ 9vwnoa/eS9lybM6lLyR5DbOFtHJEIqZPD4CvoU0jSMxtbZ+CWfaJ4Q7Uy2/TtgnM P+Sd3PyPNPf6qjOi8oykdFoebWmQdRl26uDWetofQxJj4SReBLXgCW8ZEWzzEHH1 dRUVSm+AWqYhHeRK1NJDYeAFtD3mKWFjHgWh2BOM7367o+XL7S6vYpPGIUNTAAG/ J2udw6JIPxy4No4noeY+bRNO2Mwah0nxyliTCeRTQd75u9YN+31jifJ+AUKf1m7f 6OqsgokvYuCyODmNx/cM5fFEZn4LIGnTCdj85gv/i1I64lY3z+w= =uJOE -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From nobody Thu Mar 15 07:47:10 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EB612D88A for ; Thu, 15 Mar 2018 07:47:08 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 4OT2eNUlhrl8 for ; Thu, 15 Mar 2018 07:47:07 -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 B38A3126BF3 for ; Thu, 15 Mar 2018 07:47:06 -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 w2FEl2eX010950; Thu, 15 Mar 2018 15:47:02 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 402BJ60DB3zDXJv; Thu, 15 Mar 2018 15:47:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180315143206.GA16657@hephaistos.amsuess.com> Date: Thu, 15 Mar 2018 15:47:01 +0100 Cc: Core WG mailing list X-Mao-Original-Outgoing-Id: 542818020.020601-2a85773799b70511543552ddcd9e7150 Content-Transfer-Encoding: quoted-printable Message-Id: <2522BCB8-BFEA-4D3A-87B4-1A92D9CE735D@tzi.org> References: <20180315143206.GA16657@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] arriving at BERT for early block requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 15 Mar 2018 14:47:09 -0000 Hi Christian, > On Mar 15, 2018, at 15:32, Christian Ams=C3=BCss = wrote: >=20 > Hello CoAP-over-TCP authors and working group, >=20 > during a RFC8323 interop, a question concerning BERT came up: >=20 > Can a request block operation (say, a large PUT) be conducted with = BERT > by a TCP client without waiting for the CSM? Indeed, the text=20 To avoid unnecessary latency, a Connection Initiator MAY send additional messages after its initial CSM without waiting to receive the Connection Acceptor's CSM; however, it is important to note that the Connection Acceptor's CSM might indicate capabilities that impact how the Connection Initiator is expected to communicate with the Connection Acceptor. For example, the Connection Acceptor's CSM could indicate a Max-Message-Size Option (see Section 5.3.1) that is smaller than the base value (1152) in order to limit both buffering requirements and head-of-line blocking. focuses on capability indications that restrict the defaults instead of = the initiator charging ahead with using capabilities it hasn=E2=80=99t = been presented yet. > If the client does not wait for the server's CSM, it can't know the > Max-Message-Size, and whether the server indicates the > Block-Wise-Transfer capability. The only way to send the PUT right = away > is to send an 1:(0/1/1024) regular block with szx=3D6. Well, sending something the peer may not support is risky, but I = wouldn=E2=80=99t say it=E2=80=99s outright forbidden. Maybe the initiator still knows the CSM from the last time? Maybe = it=E2=80=99s just =E2=80=9Cfeeling lucky=E2=80=9D=E2=84=A2? (The peer cannot even check for premature use of capabilities as it = probably already has sent the CSM and doesn=E2=80=99t know when = that=E2=80=99ll have arrived. Of course, when a capability is being = used that is *not* present, the connection will not be successful.) > The server then sends back its CSM (say, MMS=3D64k and supporting = block). > Now who can take the started operation up to BERT? The server would = send > 2:(0/1/1024) acknowledging the first block, and the client preparing = the > next block "SHOULD [...] use the block size preferred by the server or = a > smaller one=E2=80=9D. Increasing the block size during a transfer was not an objective of the = block-wise protocol, so I don=E2=80=99t think that can be done. > Is BERT an exception to that rule, and if so, is that written = somewhere? I don=E2=80=99t think so. > Or can such a transfer never become a BERT one, Once it is started with a smaller block size, it can=E2=80=99t. > and clients with large > requests should take the time to wait for the CSM rather than save a > single round-trip and suffer the penalty of a dozens more due to = limited > block sizes? It is probably saner to just do this (except maybe when a cached CSM is = available, but that would still be a bit of a gamble). Do you have an example use case of opening a connection and then = charging ahead with BERT without waiting for the CSM? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 15 08:02:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A7124D6C for ; Thu, 15 Mar 2018 08:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 NBuK_Pc9Dfc1 for ; Thu, 15 Mar 2018 08:02:09 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA4912D87C for ; Thu, 15 Mar 2018 08:02:08 -0700 (PDT) Received: from Jude (217.77.82.81) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Mar 2018 07:59:56 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , 'Core WG mailing list' References: <20180315143206.GA16657@hephaistos.amsuess.com> In-Reply-To: <20180315143206.GA16657@hephaistos.amsuess.com> Date: Thu, 15 Mar 2018 16:01:54 +0100 Message-ID: <00ef01d3bc6e$92aea5a0$b80bf0e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGhi7kxWHutmMLXHpvmJimp3CFLgaQ1xT+A Content-Language: en-us X-Originating-IP: [217.77.82.81] Archived-At: Subject: Re: [core] arriving at BERT for early block requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 15 Mar 2018 15:02:11 -0000 I cannot speak for the authors, but as I have written my code, the first block would be sent with an SZ of 6 and then subsequent messages would = use BERT. It is written in part this way because I setup the first message = to be sent before I ever worry about trying to open the TCP session to the server. Jim > -----Original Message----- > From: core On Behalf Of Christian Ams=FCss > Sent: Thursday, March 15, 2018 3:32 PM > To: Core WG mailing list > Subject: [core] arriving at BERT for early block requests >=20 > Hello CoAP-over-TCP authors and working group, >=20 > during a RFC8323 interop, a question concerning BERT came up: >=20 > Can a request block operation (say, a large PUT) be conducted with = BERT by a > TCP client without waiting for the CSM? >=20 > If the client does not wait for the server's CSM, it can't know the = Max- > Message-Size, and whether the server indicates the Block-Wise-Transfer > capability. The only way to send the PUT right away is to send an 1:(0/1/1024) > regular block with szx=3D6. >=20 > The server then sends back its CSM (say, MMS=3D64k and supporting = block). > Now who can take the started operation up to BERT? The server would = send > 2:(0/1/1024) acknowledging the first block, and the client preparing = the next > block "SHOULD [...] use the block size preferred by the server or a smaller > one". >=20 > Is BERT an exception to that rule, and if so, is that written = somewhere? >=20 > Or can such a transfer never become a BERT one, and clients with large > requests should take the time to wait for the CSM rather than save a single > round-trip and suffer the penalty of a dozens more due to limited = block > sizes? >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Mar 15 08:09:05 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1921127369 for ; Wed, 14 Mar 2018 09:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 aw4P5qDMqJSZ for ; Wed, 14 Mar 2018 09:23:16 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 0FEB51252BA for ; Wed, 14 Mar 2018 09:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521044594; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r7oZ7o1zuAS4LkoLsxnZxbs+3GAfhKPw18YBlYNrgd4=; b=UsvRLmhapGrLPo+nBo9dk0AcO8m8Sq0DX7bWjBy5K5jOuWuEwu21uKWg2CRmjSQA IzcKdB+b2crNnZHwwx/XUSSrI5SYk1jyWEZg6yqeZYrotPdotob5MC1yyEKFDAM4 fpb2YAYYshlWLhGTCU2OlpZWTRnWVFl1e7Bq0bakPMk=; X-AuditID: c1b4fb2d-499ff70000005540-9a-5aa94c7213fa Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 76.A8.21824.27C49AA5; Wed, 14 Mar 2018 17:23:14 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 17:23:13 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "mohamed.boucadair@orange.com" , "Kraus Achim (INST/ECS4)" , RFC Errata System , "zach.shelby@arm.com" , "hartke@tzi.org" , "cabo@tzi.org" , "ben@nostrum.com" , "aamelnikov@fastmail.fm" , "adam@nostrum.com" , "jaime@iki.fi" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Technical Errata Reported] RFC7252 (5284) Thread-Index: AQHTuwGoS0FPIxZnd0CK+q0gMPjZqqPPkNuAgAAG4ICAAFPBgA== Date: Wed, 14 Mar 2018 16:23:13 +0000 Message-ID: References: <20180309093425.91095B81706@rfc-editor.org> <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com> <787AE7BB302AE849A7480A190F8B93302DEDFAB6@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEDFAB6@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.252.126.178] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUyM2J7oG6Rz8oog8s7xCz2vz/EZLF07RpW iz1/F7FbzO88zW5xZMpdVot9b9czW6x9c4TVYtvkV0wWh08pWBx++5Tdomn/VzaLS9eesDvw eKyZt4bRY9PCf4weO08dYPNYsuQnk8fhrwtZPGbtfMLi0fLsJJtHQ9sxVo9pizIDOKO4bFJS czLLUov07RK4MuZvNCmYZFOx6vwh9gbGM1ZdjJwcEgImEjc2nmLuYuTiEBI4zCjR2NHDBuEs YZQ4Mr2LFaSKTcBF4kHDIyaQhIjAfmaJy8t3soEkmIESuyb/YwGxhQXsJOZNmgMWFxGwl9j8 YTsThO0ksXvhbkYQm0VAVeLIn23sIDavgIXE/9/7WSG2HWSU+HJ8Btg2ToEkiYtb34MVMQqI SXw/tYYJYpm4xK0n85kg7haQWLLnPDOELSrx8vE/sF5RAT2JvT3tbBBxJYnbmxuA5nAA9WpK rN+lDzHGWqJ/ZRMLhK0oMaX7IdQ9ghInZz5hmcAoPgvJtlkI3bOQdM9C0j0LSfcCRtZVjKLF qcXFuelGxnqpRZnJxcX5eXp5qSWbGIFJ4eCW37o7GFe/djzEKMDBqMTD+9x7ZZQQa2JZcWXu IUYJDmYlEd491kAh3pTEyqrUovz4otKc1OJDjNIcLErivCc9eaOEBNITS1KzU1MLUotgskwc nFINjK0SM4pvMp1JyVtQNTP7faW2nttH/Ws1QasTRX6dMTywd+bpvrUn3ItuLJCeffQm4xTb mVzPTete8lZlrpH+mtcTxH6TWyVTaYGEnWEb+6/KU1/7o9oPnSlLeHPo9YxP0mXcjT9tjVdn fb9gM+HxgRhVVmaO9fGn7bhu9C7kOLmiL/PcjzchoUosxRmJhlrMRcWJAAvUf1EGAwAA Archived-At: X-Mailman-Approved-At: Thu, 15 Mar 2018 08:09:04 -0700 Subject: Re: [core] [Technical Errata Reported] RFC7252 (5284) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Mar 2018 16:23:19 -0000 SGVsbG8sDQoNClBsZWFzZSBub3RlIHRoZXJlIGlzIGFsc28gYSBzZWN1cml0eSBpc3N1ZSB3aXRo IHJlLXVzZSBvZiB0b2tlbnMuIFRoZQ0KZm9sbG93aW5nIGZvcm11bGF0aW9uIGlzIHVzZWQgaW4N Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtZWNoby1yZXF1ZXN0 LXRhZy0wMSNzZWN0aW9uLTUNCg0KIldoZW4gQ29BUCBpcyB1c2VkIHdpdGggYSBzZWN1cml0eSBw cm90b2NvbCBub3QgcHJvdmlkaW5nIGJpbmRpbmdzDQogICBiZXR3ZWVuIHJlcXVlc3RzIGFuZCBy ZXNwb25zZXMsIHRoZSBjbGllbnQgTVVTVCBOT1QgcmV1c2UgdG9rZW5zDQogICB1bnRpbCB0aGUg dHJhZmZpYyBrZXlzIGhhdmUgYmVlbiByZXBsYWNlZC4gIFRoZSBlYXNpZXN0IHdheSB0bw0KICAg YWNjb21wbGlzaCB0aGlzIGlzIHRvIGltcGxlbWVudCB0aGUgVG9rZW4gYXMgYSBjb3VudGVyLCB0 aGlzIGFwcHJvYWNoDQogICBTSE9VTEQgYmUgZm9sbG93ZWQuIg0KDQoNCg0KUmVnYXJkcw0KR8O2 cmFuDQoNCg0KDQpPbiAyMDE4LTAzLTE0IDEzOjIzLCAiY29yZSBvbiBiZWhhbGYgb2YgbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSINCjxjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KDQo+SGkgQWNoaW0sDQo+ KGNjaW5nIERPVFMgV0cpDQo+DQo+VGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMu DQo+DQo+SSdtIHBlcnNvbmFsbHkgT0sgd2l0aCBhbnkgd29yZGluZyB3aGljaCBtYWtlcyBjbGVh ciB0aGF0IGRpc3RpbmN0IHRva2Vucw0KPmFyZSBnZW5lcmF0ZWQgdG8gZGlmZmVyZW50aWF0ZSBh bW9uZyBjb25jdXJyZW50IHJlcXVlc3RzIGludm9sdmluZyB0aGUNCj5zYW1lIHNvdXJjZS9kZXN0 aW5hdGlvbiBlbmRwb2ludHMuDQo+DQo+SSdtIG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQgd2hhdCB5 b3UgbWVhbnQgYnkgInBlciBzaW11bHRhbmVvdXMgcmVxdWVzdCIsDQo+dGhvdWdoLiAgDQo+DQo+ Q2hlZXJzLA0KPk1lZA0KPg0KPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBEZSA6 IEtyYXVzIEFjaGltIChJTlNUL0VDUzQpIFttYWlsdG86QWNoaW0uS3JhdXNAYm9zY2gtc2kuY29t XQ0KPj4gRW52b3nDqSA6IG1lcmNyZWRpIDE0IG1hcnMgMjAxOCAxMjo1OQ0KPj4gw4AgOiBSRkMg RXJyYXRhIFN5c3RlbTsgemFjaC5zaGVsYnlAYXJtLmNvbTsgaGFydGtlQHR6aS5vcmc7DQo+PmNh Ym9AdHppLm9yZzsNCj4+IGJlbkBub3N0cnVtLmNvbTsgYWFtZWxuaWtvdkBmYXN0bWFpbC5mbTsg YWRhbUBub3N0cnVtLmNvbTsgY2Fib0B0emkub3JnOw0KPj4gamFpbWVAaWtpLmZpDQo+PiBDYyA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IGNvcmVAaWV0Zi5vcmcNCj4+IE9iamV0IDogUkU6 IFtjb3JlXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzI1MiAoNTI4NCkNCj4+IA0K Pj4gSGksDQo+PiANCj4+IGlmIHRoZSBjdXJyZW50IGRlZmluaXRpb24gInRva2VucyBjdXJyZW50 bHkgaW4gdXNlIiBpcyBpbnRlcnByZXRlZCBhcw0KPj5mb3INCj4+ICJhbGwgcGVuZGluZyByZXF1 ZXN0cyIsIEkgY2FuJ3Qgc2VlLCB0aGF0IGFkZGluZyAicGVyIHJlcXVlc3QiIGltcHJvdmVzDQo+ PnRoZQ0KPj4gUkZDLg0KPj4gSWYgc29tZXRoaW5nIGlzIGFkZGVkLCBJIHdvdWxkIHJlY29tbWVu ZCB0byBwcmVjaXNlIHRoYXQgYWxzbyB3aXRoIHRoZQ0KPj50aW1lLQ0KPj4gc2NvcGUsDQo+PiBl LmcuICJwZXIgc2ltdWx0YW5lb3VzIHJlcXVlc3QiLg0KPj4gDQo+PiBNaXQgZnJldW5kbGljaGVu IEdyw7zDn2VuIC8gQmVzdCByZWdhcmRzDQo+PiANCj4+ICBBY2hpbSBLcmF1cw0KPj4gDQo+PiAo SU5TVC9FQ1M0KQ0KPj4gQm9zY2ggU29mdHdhcmUgSW5ub3ZhdGlvbnMgR21iSCB8IFN0dXR0Z2Fy dGVyIFN0cmHDn2UgMTMwIHwgNzEzMzINCj4+V2FpYmxpbmdlbiB8DQo+PiBHRVJNQU5ZIHwgd3d3 LmJvc2NoLXNpLmNvbQ0KPj4gDQo+PiBTaXR6OiBCZXJsaW4sIFJlZ2lzdGVyZ2VyaWNodDogQW10 c2dlcmljaHQgQ2hhcmxvdHRlbmJ1cmc7IEhSQiAxNDg0MTEgQg0KPj4gQXVmc2ljaHRzcmF0c3Zv cnNpdHplbmRlcjogRHIuLUluZy4gVGhvcnN0ZW4gTMO8Y2tlOyBHZXNjaMOkZnRzZsO8aHJ1bmc6 DQo+PkRyLg0KPj4gU3RlZmFuIEZlcmJlciwgTWljaGFlbCBIYWhuDQo+PiANCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUkZDIEVycmF0YSBTeXN0ZW0NCj4+IFNlbnQ6IEZyZWl0YWcs IDkuIE3DpHJ6IDIwMTggMTA6MzQNCj4+IFRvOiB6YWNoLnNoZWxieUBhcm0uY29tOyBoYXJ0a2VA dHppLm9yZzsgY2Fib0B0emkub3JnOyBiZW5Abm9zdHJ1bS5jb207DQo+PiBhYW1lbG5pa292QGZh c3RtYWlsLmZtOyBhZGFtQG5vc3RydW0uY29tOyBjYWJvQHR6aS5vcmc7IGphaW1lQGlraS5maQ0K Pj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGNvcmVAaWV0Zi5vcmc7DQo+PnJm Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmcNCj4+IFN1YmplY3Q6IFtjb3JlXSBbVGVjaG5pY2FsIEVy cmF0YSBSZXBvcnRlZF0gUkZDNzI1MiAoNTI4NCkNCj4+IA0KPj4gVGhlIGZvbGxvd2luZyBlcnJh dGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNzI1MiwgIlRoZQ0KPj5Db25zdHJh aW5lZA0KPj4gQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIi4NCj4+IA0KPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBv cnQgYmVsb3cgYW5kIGF0Og0KPj4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlk NTI4NA0KPj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4g VHlwZTogVGVjaG5pY2FsDQo+PiBSZXBvcnRlZCBieTogTW9oYW1lZCBCb3VjYWRhaXIgPG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiANCj4+IFNlY3Rpb246IDUuMy4xDQo+PiANCj4+ IE9yaWdpbmFsIFRleHQNCj4+IC0tLS0tLS0tLS0tLS0NCj4+IFRoZSBjbGllbnQgU0hPVUxEIGdl bmVyYXRlIHRva2VucyBpbiBzdWNoIGEgd2F5IHRoYXQgdG9rZW5zIGN1cnJlbnRseQ0KPj5pbiB1 c2UNCj4+IGZvciBhIGdpdmVuIHNvdXJjZS9kZXN0aW5hdGlvbiBlbmRwb2ludCBwYWlyIGFyZSB1 bmlxdWUuDQo+PiANCj4+IENvcnJlY3RlZCBUZXh0DQo+PiAtLS0tLS0tLS0tLS0tLQ0KPj4gVGhl IGNsaWVudCBTSE9VTEQgZ2VuZXJhdGUgdG9rZW5zIGluIHN1Y2ggYSB3YXkgdGhhdCB0b2tlbnMg Y3VycmVudGx5DQo+PmluIHVzZQ0KPj4gZm9yIGEgZ2l2ZW4gc291cmNlL2Rlc3RpbmF0aW9uIGVu ZHBvaW50IHBhaXIgYXJlIHVuaXF1ZSBwZXIgcmVxdWVzdC4NCj4+IA0KPj4gTm90ZXMNCj4+IC0t LS0tDQo+PiBNdWx0aXBsZSByZXF1ZXN0cyBtYXkgYmUgYWN0aXZlIGZvciBhIGdpdmVuIHNvdXJj ZS9kZXN0aW5hdGlvbiBlbmRwb2ludA0KPj5wYWlyLg0KPj4gVGhlIE9MRCB0ZXh0IGlzIHRodXMg YnJva2VuLg0KPj4gDQo+PiBUaGUgTkVXIHRleHQgaXMgYWxpZ25lZCB3aXRoIHRoZSBkZWZpbml0 aW9uIG9mIHRoZSBUb2tlbjoNCj4+IA0KPj4gICBBIHRva2VuIGlzIGludGVuZGVkIGZvciB1c2Ug YXMgYSBjbGllbnQtbG9jYWwgaWRlbnRpZmllciBmb3INCj4+ICAgZGlmZmVyZW50aWF0aW5nIGJl dHdlZW4gY29uY3VycmVudCByZXF1ZXN0cyAoc2VlIFNlY3Rpb24gNS4zKTsgaXQNCj4+ICAgY291 bGQgaGF2ZSBiZWVuIGNhbGxlZCBhICJyZXF1ZXN0IElEIi4NCj4+IA0KPj4gRnVydGhlciwgdXNp bmcgdGhlIHNhbWUgdG9rZW4gZm9yIGEgZ2l2ZW4gc291cmNlL2Rlc3RpbmF0aW9uIGVuZHBvaW50 DQo+PnBhaXINCj4+IGhhdmUgc29tZSBpbXBsaWNhdGlvbnMsIGZvciBleGFtcGxlLCBmb3IgYXBw bGljYXRpb25zIHdoaWNoIHJlcXVpcmUgdGhlDQo+PiBzdXBwb3J0IG9mIG11bHRpcGxlIG9ic2Vy dmUgcXVlcmllcyBiZWNhdXNlIFJGQzc2NDEgc3RhdGVzIHRoZQ0KPj5mb2xsb3dpbmc6DQo+PiAN Cj4+ICAgIFRoZSBlbnRyeSBpbiB0aGUgbGlzdCBvZiBvYnNlcnZlcnMgaXMga2V5ZWQgYnkgdGhl IGNsaWVudCBlbmRwb2ludA0KPj4gICAgIGFuZCB0aGUgdG9rZW4gc3BlY2lmaWVkIGJ5IHRoZSBj bGllbnQgaW4gdGhlIHJlcXVlc3QuICBJZiBhbiBlbnRyeQ0KPj4gICAgIHdpdGggYSBtYXRjaGlu ZyBlbmRwb2ludC90b2tlbiBwYWlyIGlzIGFscmVhZHkgcHJlc2VudCBpbiB0aGUgbGlzdA0KPj4g ICAgICh3aGljaCwgZm9yIGV4YW1wbGUsIGhhcHBlbnMgd2hlbiB0aGUgY2xpZW50IHdpc2hlcyB0 byByZWluZm9yY2UNCj4+ICAgICBpdHMgaW50ZXJlc3QgaW4gYSByZXNvdXJjZSksIHRoZSBzZXJ2 ZXIgTVVTVCBOT1QgYWRkIGEgbmV3IGVudHJ5DQo+PiAgICAgYnV0IE1VU1QgcmVwbGFjZSBvciB1 cGRhdGUgdGhlIGV4aXN0aW5nIG9uZS4NCj4+IA0KPj4gSW5zdHJ1Y3Rpb25zOg0KPj4gLS0tLS0t LS0tLS0tLQ0KPj4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVk Ii4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UgdXNlDQo+PiAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdo ZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLiBXaGVuIGENCj4+IGRlY2lz aW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgY2FuIGxvZyBpbiB0byBjaGFuZ2Ug dGhlDQo+PnN0YXR1cyBhbmQNCj4+IGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5Lg0KPj4g DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gUkZDNzI1MiAo ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtMTgpDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4gVGl0bGUgICAgICAgICAgICAgICA6IFRoZSBDb25zdHJhaW5lZCBBcHBs aWNhdGlvbiBQcm90b2NvbCAoQ29BUCkNCj4+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBKdW5lIDIw MTQNCj4+IEF1dGhvcihzKSAgICAgICAgICAgOiBaLiBTaGVsYnksIEsuIEhhcnRrZSwgQy4gQm9y bWFubg0KPj4gQ2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQo+PiBTb3Vy Y2UgICAgICAgICAgICAgIDogQ29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMgQVBQDQo+ PiBBcmVhICAgICAgICAgICAgICAgIDogQXBwbGljYXRpb25zDQo+PiBTdHJlYW0gICAgICAgICAg ICAgIDogSUVURg0KPj4gVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCj4+IA0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGNvcmUgbWFpbGlu ZyBsaXN0DQo+PiBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvcmUNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPmNvcmUgbWFpbGluZyBsaXN0DQo+Y29yZUBpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo= From nobody Thu Mar 15 08:53:51 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA631273E2 for ; Thu, 15 Mar 2018 08:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 GpCmrw7GSAcJ for ; Thu, 15 Mar 2018 08:53:48 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7C01270FC for ; Thu, 15 Mar 2018 08:53:48 -0700 (PDT) Received: from Jude (217.77.82.81) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Mar 2018 08:51:37 -0700 From: Jim Schaad To: 'Carsten Bormann' , =?utf-8?Q?'Christian_Ams=C3=BCss'?= CC: 'Core WG mailing list' References: <20180315143206.GA16657@hephaistos.amsuess.com> <2522BCB8-BFEA-4D3A-87B4-1A92D9CE735D@tzi.org> In-Reply-To: <2522BCB8-BFEA-4D3A-87B4-1A92D9CE735D@tzi.org> Date: Thu, 15 Mar 2018 16:53:33 +0100 Message-ID: <010201d3bc75$caddded0$60999c70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGhi7kxWHutmMLXHpvmJimp3CFLgQF6JPrjpCn/G+A= Content-Language: en-us X-Originating-IP: [217.77.82.81] Archived-At: Subject: Re: [core] arriving at BERT for early block requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 15 Mar 2018 15:53:50 -0000 Carsten, > -----Original Message----- > From: core On Behalf Of Carsten Bormann > Sent: Thursday, March 15, 2018 3:47 PM > To: Christian Ams=C3=BCss > Cc: Core WG mailing list > Subject: Re: [core] arriving at BERT for early block requests >=20 > Hi Christian, >=20 > > On Mar 15, 2018, at 15:32, Christian Ams=C3=BCss = > wrote: > > > > Hello CoAP-over-TCP authors and working group, > > > > during a RFC8323 interop, a question concerning BERT came up: > > > > Can a request block operation (say, a large PUT) be conducted with > > BERT by a TCP client without waiting for the CSM? >=20 > Indeed, the text >=20 > To avoid unnecessary latency, a Connection Initiator MAY send > additional messages after its initial CSM without waiting to = receive > the Connection Acceptor's CSM; however, it is important to note = that > the Connection Acceptor's CSM might indicate capabilities that = impact > how the Connection Initiator is expected to communicate with the > Connection Acceptor. For example, the Connection Acceptor's CSM > could indicate a Max-Message-Size Option (see Section 5.3.1) that = is > smaller than the base value (1152) in order to limit both buffering > requirements and head-of-line blocking. >=20 > focuses on capability indications that restrict the defaults instead = of the > initiator charging ahead with using capabilities it hasn=E2=80=99t = been presented yet. >=20 > > If the client does not wait for the server's CSM, it can't know the > > Max-Message-Size, and whether the server indicates the > > Block-Wise-Transfer capability. The only way to send the PUT right > > away is to send an 1:(0/1/1024) regular block with szx=3D6. >=20 > Well, sending something the peer may not support is risky, but I = wouldn=E2=80=99t say > it=E2=80=99s outright forbidden. > Maybe the initiator still knows the CSM from the last time? Maybe = it=E2=80=99s just > =E2=80=9Cfeeling lucky=E2=80=9D=E2=84=A2? > (The peer cannot even check for premature use of capabilities as it = probably > already has sent the CSM and doesn=E2=80=99t know when that=E2=80=99ll = have arrived. Of > course, when a capability is being used that is *not* present, the = connection > will not be successful.) >=20 > > The server then sends back its CSM (say, MMS=3D64k and supporting = block). > > Now who can take the started operation up to BERT? The server would > > send > > 2:(0/1/1024) acknowledging the first block, and the client preparing > > the next block "SHOULD [...] use the block size preferred by the > > server or a smaller one=E2=80=9D. >=20 > Increasing the block size during a transfer was not an objective of = the block- > wise protocol, so I don=E2=80=99t think that can be done. Indeed, there is a requirement that the size be the same or smaller. = However I would question that this is a change of the block size if = going from no BERT to BERT. The block size is the same, one just have = the ability to have a more efficient transfer. If you started w/ a block size of 512 rather than 1024, then I would = agree that BERT could not be triggered as the BERT document says that = SZX can be changed in the middle of a transfer, but it can only be made = smaller. Jim >=20 > > Is BERT an exception to that rule, and if so, is that written = somewhere? >=20 > I don=E2=80=99t think so. >=20 > > Or can such a transfer never become a BERT one, >=20 > Once it is started with a smaller block size, it can=E2=80=99t. >=20 > > and clients with large > > requests should take the time to wait for the CSM rather than save a > > single round-trip and suffer the penalty of a dozens more due to > > limited block sizes? >=20 > It is probably saner to just do this (except maybe when a cached CSM = is > available, but that would still be a bit of a gamble). >=20 > Do you have an example use case of opening a connection and then = charging > ahead with BERT without waiting for the CSM? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 15 10:54:25 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CCB12DA01 for ; Thu, 15 Mar 2018 10:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 iwlwGxZqSIxm for ; Thu, 15 Mar 2018 10:54:22 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0838812DA00 for ; Thu, 15 Mar 2018 10:54:21 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id C5C264961C; Thu, 15 Mar 2018 18:54:18 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id EFD1061; Thu, 15 Mar 2018 18:54:14 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AA1453A; Thu, 15 Mar 2018 18:54:14 +0100 (CET) Received: (nullmailer pid 7698 invoked by uid 1000); Thu, 15 Mar 2018 17:54:13 -0000 Date: Thu, 15 Mar 2018 18:54:13 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: Core WG mailing list Message-ID: <20180315175413.GC17784@hephaistos.amsuess.com> References: <20180315143206.GA16657@hephaistos.amsuess.com> <2522BCB8-BFEA-4D3A-87B4-1A92D9CE735D@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OBd5C1Lgu00Gd/Tn" Content-Disposition: inline In-Reply-To: <2522BCB8-BFEA-4D3A-87B4-1A92D9CE735D@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] arriving at BERT for early block requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 15 Mar 2018 17:54:24 -0000 --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Carsten, On Thu, Mar 15, 2018 at 03:47:01PM +0100, Carsten Bormann wrote: > It is probably saner to just do this (except maybe when a cached CSM > is available, but that would still be a bit of a gamble). >=20 > Do you have an example use case of opening a connection and then > charging ahead with BERT without waiting for the CSM? The cases I stumbled upon it was wget-style client tools. The only realistic case that comes to my mind is registering with a fresh connection on a known resource directory (where the representation of .well-known/core is still fresh). > Maybe the initiator still knows the CSM from the last time? Given that CSMs have no formal persistence, that seems no more reliable than Feeling Lucky in the first place -- the client would need to be prepared to receive 4.0x Bad Option. (For the matter of the not really increasing block sizes itself, Jim has spoken my mind.) Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --OBd5C1Lgu00Gd/Tn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqqs0EACgkQOY0REtOk veHwpQ/8Cc4TlGJ0IF8TVCDbCB6iyUICrp0JtKwpLgkAyNGA8FOtYtfT8cYx1iuL +d4HD/rr3fJ/8dA8w92sm/RK9mEG11pHy5NDcxmOmG9A59wchQFx6GLQPXsANdxP g0M+JNh7xJy3B/Z4X2b5AoX1urHdyAlbSxt897iWMUKkA52YzGo1fIPjH5YerMEo cUtgnnbiHQ3w7K7Re6EY4r0xcQTZOziaS7j1TdWW9AmQnyrSt3yZb5FA2qHNimEZ MBhsLr1i8XCaPYgaE9yxhd56PjlkE9Vm0/b234uTxFhrJa1HmHOr0L3TwugOzEvR yyK7G27bPL5X5fZQz/eYun+jGOD5bRlPzcDExZt2QkBquYfZx0KDEp+k4GlrSYK8 U0wglzuaE27tj+/ojhpKzma4lqiXfbgz9K4gBUIAN6D0yJZLYBWo8n4rua8Mxz3O aqLOVYkcYN6qUSyBkpM7uWBYfRiYMzlB5Fdh+6QWC0ycYKgwR6BHfV0kByUS0b09 9kXcn8Id1+JPcARmJGXd6JPFx5HfnuWqYSDvUeEU2xOJdb1dj4dIjch5qK0eyNnz bwl4sjjTQ7YNk4oAB9Vuuq1WpBYvltO3/G0I7OVEOY1l7hce53nkCslNe4gXkZxj HoRVjdchRaOjqi1pLNiVLfiIbqWUBpnlN1qyv4IPlYSMNpqABV4= =UwQi -----END PGP SIGNATURE----- --OBd5C1Lgu00Gd/Tn-- From nobody Thu Mar 15 18:03:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABB3127873 for ; Thu, 15 Mar 2018 18:03:36 -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 avoivK9FPJu0 for ; Thu, 15 Mar 2018 18:03:34 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 29B3912422F for ; Thu, 15 Mar 2018 18:03:34 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id y2-v6so10805031lfc.5 for ; Thu, 15 Mar 2018 18:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TriRAu8AtXZMfJ4mdWZqpUEhhMY2Pzdi26ZAC7OqKwM=; b=ZMCoIuqq4n3MVs7CDImV5onV2wRGb5NqPowTT/TVfl0BUPshXfCX9ae0w8+QkNAu2x D+35liwQcUoBsL/fUTjsO9q/xFx4nITlr47053hQgxuRgoosaPqsM4m272Ol35tX5l2r QDvTZB2oJ/hz0TO+WXJf0D4ENBHyM1xcXQTH40l8Zg8izv6IMjDY2Bne6DCD60RR1v1s G3tsPv8a0pBMtFMBjKd1HQeFrWsTkPYLCHN+gumbjn1sodC+4RsE2T3hsLMXmUgq0Ay1 lUXzaqJa5dWHeOvll6jGmMraDEW+d8/B1pjbCi3RXcGDowJeY5cHyl2maM2wCwiBl3jw SzdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TriRAu8AtXZMfJ4mdWZqpUEhhMY2Pzdi26ZAC7OqKwM=; b=HKoL4eJ7GtelZdnmo4Vd5NF0reuJgogGdcHxXPBN5KQnqQhGLO0/S+rSwEYB6LU0rr gWuD1LWsceNP8R3qIyUsWS3rNxsbOSsuWp25JYvDq3Us+G4GCaOajHCmRNxDvzsAi5Zx yqvsn0WpAf3vzvDYHyTMSGNi25Ku/iCXaj9/+mtdKcDm0cerYL0H8UjdaepvklOh34Pg Q+s+B7oSDU6f0sLLrNA0BN5CqknHo5qWEK6TbobNDRejjP8I5H7lJoBCfwv8M5pv7ZJ7 qS9sCDqEmkparMSYWtf/TlzojhokYx7fzEMR5E3fpLHGTb1ITO2VsjhRvufXzoYmaTrL IRJg== X-Gm-Message-State: AElRT7ERln3uFvz1DOcePVmyFib22FZRgyuz917SXq3Xq0H9Jtnpcas2 BbR3dO7OUxr06y3/SNdzNIOEMuU690A9owWXta0= X-Google-Smtp-Source: AG47ELvs8uJ7EcqF7yt8HqcbuhwGzmCSMI0kUyHTXlrw8gS1uXTkpyIl7o9nj/Wmuw9WyyFSX7db2HP/HoBZbGdDi6w= X-Received: by 2002:a19:ea16:: with SMTP id i22-v6mr8069276lfh.65.1521162212291; Thu, 15 Mar 2018 18:03:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d0cf:0:0:0:0:0 with HTTP; Thu, 15 Mar 2018 18:03:31 -0700 (PDT) In-Reply-To: <0cc8bfd6-2f50-83b6-d392-e80de133ce34@tut.fi> References: <0cc8bfd6-2f50-83b6-d392-e80de133ce34@tut.fi> From: JinHyeock Choi Date: Fri, 16 Mar 2018 10:03:31 +0900 Message-ID: To: Bill Silverajan Cc: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org WG (core@ietf.org)" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] Review of draft-silverajan-core-coap-protocol-negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Mar 2018 01:03:36 -0000 Bill >> ol=http://[FDFD::123]:61616, coap://[2001:db8:f1::2]:5683 >> >> corresponds to >> >> "eps": [ >> {"ep": "http://[FDFD::123]:61616"}, >> {"ep": "coaps://[2001:db8:f1::2]:5683"} >> ] >> > That is good. Going forward, the mapping would become easier: We've defined > "ol" to be repeatable instead of a comma separated list of base URIs. For > example, > https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation-08#section-6.1 thanks for the clarification. I mistakenly referred the examples from v08. >> There still exisit some differences >> (e.g., URI in "ep" shall have IP address in its authority.), >> which, I hope, we would discuss in joint meeting next FRI. >> > If you are participating in IETF 101, we can also arrange a corridor > discussion around this topic. I'd be interested in hearing your thoughts > here too. Unfortunately IETF 101 conflicts with OCF meeting in Prague. However FRI afternoon, we will have a T2TRG/ OCF/ WoT joint meeting there, https://github.com/t2trg/2018-03-ocf-wot so your participation would be much appreciated. best regards JinHyeock From nobody Fri Mar 16 01:00:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B597126CBF for ; Fri, 16 Mar 2018 01:00:14 -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=googlemail.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 fmmHCuYjaLH3 for ; Fri, 16 Mar 2018 01:00:12 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 D7BE91243FE for ; Fri, 16 Mar 2018 01:00:11 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id w3-v6so1054501itc.4 for ; Fri, 16 Mar 2018 01:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JZFGk2CU39Im2W9iRRcpemWKzD2eDfYO8zfau2WRvoE=; b=J01SiknZLJXbWBBf1hLuozfXmFCkEk+XGXWUYkJx4Ip0VzMka6ONPRa+1kDLJveFvs tbTtfH+cnHNLqpc2gJyPhaVDrHJGbTWD7adAOwSitw2onxKNPuQZurLPgdAhSQuzXHPi drumpJFIBXWs2H6KItf/T4C8MKJg0huFgy4Gl4ZNZff0vlshgxoWMmktRbHCEAt0lZFM 8pSrLqP6Bnm/BT+JIWIrJVNkLPZqL9krxTV1nZuqKelI+y5WTOeQ1d0RaQQRk4nafBLo fPeAIyOYFVlX8AkyMSfqgcm4WXKJyh9vHyl5Bp/Rij9++bdv6fPs2CudG/uCDHsh4hBz LHzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JZFGk2CU39Im2W9iRRcpemWKzD2eDfYO8zfau2WRvoE=; b=YqM3Bc4jyvj0fzQX4H7UDLgV4+W3B6PU3X5LPTl6Z3AzN6sjN87isVEbyJ756/yxgj te7cbAa05PoQomLb3Huo07uzF4642YHPmG/TtACDxebCs5K+xKJlkut0519DSLsY9l8N EvjJxM0w57rJNuxVpS+BejTC/DlfcrWViZL87Hn73zLsh8qn6ikKallXS4kLP0KEfAlO RBWe4ADRdT6Iz6dVUytSc/p7DI1CtFGOyjKHLFQ1fC54PHWdXvEnnOSUm2DRb8vQm4id imPjAu3u4/dk8knZSfyVJZtfz8vO0R9bUAIv/YddO37voCeGG4dH0QoEVKiLG981Cpxo vFiA== X-Gm-Message-State: AElRT7EHdG6pufBlRk2l6cKfUKhzrH14E0F4mMVnFGvE8qon431QXsl9 Y8W8+/aLGB3hSL7G9RrECOtyJPlUOmI4koIjiI4= X-Google-Smtp-Source: AG47ELvK2plOx1pd2MHNwJOjoPUdBpZltjpucAIb/XKmC5nrQB7io+gvSaRlb956f8nNJLUhDrY6syHGiKRgj2kQA+Y= X-Received: by 2002:a24:cf03:: with SMTP id y3-v6mr1258433itf.5.1521187210754; Fri, 16 Mar 2018 01:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.201.140 with HTTP; Fri, 16 Mar 2018 01:00:10 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Fri, 16 Mar 2018 10:00:10 +0200 Message-ID: To: core@ietf.org Cc: Maria Rita Palattella Content-Type: multipart/alternative; boundary="0000000000005581d2056782ff0d" Archived-At: Subject: [core] Fwd: M2MSAT (IoT over SATELLITE) back at IETF101 LONDON X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Mar 2018 08:00:15 -0000 --0000000000005581d2056782ff0d Content-Type: text/plain; charset="UTF-8" Hi, FYI, ---------- Forwarded message ---------- From: Maria Rita Palattella Date: 2018-03-08 12:30 GMT+02:00 Subject: M2MSAT (IoT over SATELLITE) back at IETF101 LONDON To: Maria Rita Palattella Dear all, I would like to thank all of you that joined the Info session on M2MSAT at IETF99 - Prague, and shown an interest in our activities. For those that may not remember, *M2MSAT* (https://artes.esa.int/projects/m2msat)is a project, funded by ESA, aiming to study optimisation of IoT application protocols (CoAP and MQTT) for communication over a satellite link. IoT networks will be soon integrated with terrestrial networks in the 5G scenarios, and it is fundamental to understand which performance can be achieved, and which adaptation/improvement are needed for the IoT protocols, not originally designed for communication over satellite. We have simulated the integrated M2M-Sat system combining different tools: OpenSAND, Californium CoAP, MQTT Mosquito. We have been investigating the most suitable configurations, integrating proxy, and brokers (when and where possible) in the architecture, and tuning different protocol parameters. I will be presenting the last outcomes of the M2MSAT project, at *I**ETF101 London*, for 2 hr slot (from *16:30-18:30*) on *Tuesday 20th March *in *Hilton Meeting Rooms 1-4*. I will be happy to see many of you there, discuss together and collect your feedback. For those that would like to join remotely, we have set up a webex. Here is the link: JOIN WEBEX MEETING https://meetses.webex.com/meetses/j.php?MTID=m8ef2e6c167d11e162178bd64a65fa bfc Meeting number (access code): 977 113 932 Meeting password: Frank_123 Please, feel free to advertise the Info session to anyone that could be interested in the topic. For those of you that are chairing a WG, if you consider the topic relevant for your group, I will appreciate if you can announce the talk on your WG ML. Thank you. I look forward to meeting you in London. Best Regards, Dr. Maria Rita Palattella ------------------------------------------------------------ ----------------- Senior R&T Associate Department 'Environmental Research and Innovation' (ERIN) Luxembourg Institute of Science and Technology (LIST) 41, rue du Brill L-4422 Belvaux, Grand-duchy of Luxembourg email: mariarita.palattella@list.lu, tel: +352 275 888-5055 --0000000000005581d2056782ff0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

FYI,


<= div class=3D"gmail_quote">---------- Forwarded message ----------
From: = Maria Rita Palattella &= lt;mariarita.palattella@lis= t.lu>
Date: 2018-03-08 12:30 GMT+02:00
Subject: M2MSAT = (IoT over SATELLITE) back at IETF101 LONDON
To: Maria Rita Palattella &l= t;mariarita.palattella@list= .lu>


Dear all,

I would like to thank all of you that joined the Info = session on M2MSAT at IETF99 - Prague, and shown an interest in our activiti= es.
For those that may not remember,

M2MSAT=C2=A0(<= /font>https://artes.esa.int/projects/m2msat)is a project, funded by ESA, aiming to study = optimisation of IoT application protocols (CoAP and MQTT) for communication= over a satellite link. IoT networks will be soon integrated with terrestri= al networks in the 5G scenarios, and it is fundamental to understand which = performance can be achieved, and which adaptation/improvement are needed fo= r the =C2=A0IoT protocols, not originally designed for communication over s= atellite.

We have simulated the integrated M2M-Sat system combin= ing different tools: OpenSAND, Californium CoAP, MQTT Mosquito.
We have been investigating the most suitable configura= tions, integrating proxy, and brokers (when and where possible) in the arch= itecture, and tuning different protocol parameters.

I will be presenting the last outcomes of the M2MSAT p= roject, at IETF101 London, fo<= /tt>r 2 hr slot (from 16:30-18:30) on Tuesday 20th March <= /font>in Hilt= on Meeting Rooms 1-4.

I will be happy to see many of you there, discuss toge= ther and collect your feedback.

For those that would like to join remotely, we have se= t up a webex. Here is the link:

JOIN WEBEX MEETING
https:= //meetses.webex.com/meetses/j.php?MTID=3Dm8ef2e6c167d11e162178bd6= 4a65fabfc
Meeting number (access code): 977 113 932
Meeting password: Frank_123

Please, feel free to advertise the Info session to any= one that could be interested in the topic.
For those of you that are chairing a WG, if you consid= er the topic relevant for your group, I will appreciate if you can announce= the talk on your WG ML.

=C2=A0
Thank you.
I look forward to meeting you in London.


Best Regards,
Dr. Maria Rita Palattella

-----------------------------------------------------------------= ------------
Senior R&T Associate
Department 'Environmental Research and Innovation' (ERIN)
Luxembourg Institute of Science and Technology (LIST)
41, rue du Brill
L-4422 Belvaux, Grand-duchy of Luxembourg
email: ma= riarita.palattella@list.lu, tel: +352 275 888-5055


    --0000000000005581d2056782ff0d-- From nobody Fri Mar 16 09:44:20 2018 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 09A7112D77D; Fri, 16 Mar 2018 09:44:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Christer Holmberg To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-cocoa.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152121865400.14492.10787438326929665934@ietfa.amsl.com> Date: Fri, 16 Mar 2018 09:44:14 -0700 Archived-At: Subject: [core] Genart telechat review of draft-ietf-core-cocoa-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 16:44:14 -0000 Reviewer: Christer Holmberg Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-core-cocoa-03 Reviewer: Christer Holmberg Review Date: 2018-03-16 IETF LC End Date: None IESG Telechat date: 2018-04-05 Summary: >From a technical perspective I don’t have any issues. However, I think the document could use quite a bit of editorial improvements. There is lots of inconsistent terminology, “speech-to-text” etc. I will focus on parts that I think are unclear. Major issues: N/A Minor issues: N/A Nits/editorial comments: --- General: The document uses lots of different, and often complicated, terminology for referencing RFC 7252. Example: “In the definition of the CoAP protocol [RFC7252],…” “The CoRE CoAP specification defines…” Etc etc. Please use consistent terminology. I suggest to simply say “CoAP [RFC7252]” or “[RFC7252]”. --- General: In some places the text says: “The present specification…” I suggest to say: “This specification…” --- General: The draft uses “CoAP endpoint” and “endpoint” terminology. Please use consistent terminology. --- General: The draft uses “RTO estimator” and “estimator” terminology. Please use consistent terminology. Also, what is an “RTO estimator”? --- General: Some of the sections are named “Discussion”. However, they still contain normative procedures, and even RFC2119 terminology (MUST, SHOULD etc). Because of that, I think it is more than a discussion. A discussion is typically used to justify something, or to give some background, not to define procedures. --- The Abstract and the Introduction say: “CoAP, the Constrained Application Protocol, needs to be implemented in such a way that it does not cause persistent congestion on the network it uses.” What exactly does this mean? Implemented in what way? --- The text in Section 2 says: “The present specification is based on the approved text in the [RFC7252] base specification.” I don’t understand the “approved” part. Since RFC 7252 has been published, I assume the text is approved :) --- The text in Section 3 refers to “Responder”. However, it is not defined/referenced anywhere. --- The text in Section 4.3 says: “The state of the RTO estimators for an endpoint SHOULD be kept as long as possible.” Later the text says that the RTO state depends on whether there is other state (DTLS etc) or not? Can the sentence above be removed? --- The text in Section 4.3 says “very strongly RECOMMENDED” and “strongly RECOMMENDED”. That sounds like a “SHOULD” in my ears :) --- The text in Section 4.3 talks about “State of RTO estimator” and “RTO state”. Are these different states? --- The text in Section 5 talks about “non-confirmables”. Please include a reference or definition. --- The text in Section 7 says: “The security considerations of, e.g., [RFC5681], [RFC2914], and [RFC8085] apply. Some issues are already discussed in the security considerations of [RFC7252].” I don’t think you can say “e.g.,” and “Some issues”. It needs to be clear which security considerations apply. From nobody Fri Mar 16 13:54:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C371252BA for ; Fri, 16 Mar 2018 13:54:46 -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 l70DCcuBnGLJ for ; Fri, 16 Mar 2018 13:54:44 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 8B90F124C27 for ; Fri, 16 Mar 2018 13:54:44 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id y127so7118731vky.9 for ; Fri, 16 Mar 2018 13:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=AOjaFgvUrnyy66Ei8bIl21fI7cXMbIKDo/HmQQT4DEk=; b=G+XNeJMw1+VZAmHqQRkenuChkTBMY8SW45uijtA9Fje/810FN//GhnVNw9wqLCacbI KqCzuzbBdLkYi7vl2Lb7mtEyqBrOQ6N8XIU+LyHwdW8DD6rg5Q/kUHXU2cAuNhAbFehy wzxvyOQxpa9vq0QFG2JNOVjAh/u0qBdWQjhCcF34i+Ctkj3lqWBN8naYjpZ2NtOWeFjq R3+9DVouEVGhjiGw4sioOS6FSMRJThlMyLutBqkJdEH3PSNA4dnANPVw96arp61GO1rv GDHqdcJldEcGAfhtIRygsxQONVenFN06bXs6nCd5yigP01AvZ7ZyRiyqfqH31xXeH7Qy HL+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AOjaFgvUrnyy66Ei8bIl21fI7cXMbIKDo/HmQQT4DEk=; b=PkCZtwiDYXtUWLWPF1JXJCBD0XELoIacnKa0kX6X8A/PShnBEhkp8XLjZWl7g5DjKV OONC+g5eg79tP0CjiaEz4+g/KBBKHHRBWW2oLNDCFMnxAD2UFIdmmgkaCo0iSO7JkvDM GeswFbu6fgQmKiSgM8jwF5BSKoZByZQVAJ4T+Z79KWdb4pWrA54/qbA59mWD7J8AeW1z ECnmchqZNhUiKBpNP+1lLJDdurQICCW0IC49ot90pFidUF/igZ3ijpqMisJ++KO1qjRI fZhi2c76+z2dQg9paHr77MhKB1Jtj5PGY73q7z4+asYh/xdVZayrHIlHtB+4ppPLAddh /WoQ== X-Gm-Message-State: AElRT7Gh+0kxXHQ0jS9cspcrMjn7EM//fqAGJbXL3mQ2RjtZ0MGb0HwW orJKJ5ZOY78ubW1d2h38gdY8QQbt/ITZnnPGrpDgrgRp X-Google-Smtp-Source: AG47ELtBwP93BQplrLTrwT2pyBvxCLitHiode2/IDtxMJK2GPbdb6vp4HLvglgRqh7m3d8+9ZZ6DXVZmbvpTv3Gu3/U= X-Received: by 10.31.196.131 with SMTP id u125mr2238261vkf.27.1521233683312; Fri, 16 Mar 2018 13:54:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.142 with HTTP; Fri, 16 Mar 2018 13:54:42 -0700 (PDT) From: Tanguy Ropitault Date: Fri, 16 Mar 2018 16:54:42 -0400 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="001a114bcfc25073d205678dd18f" Archived-At: Subject: [core] CoMI server implementation available for remote interop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Mar 2018 20:54:46 -0000 --001a114bcfc25073d205678dd18f Content-Type: text/plain; charset="UTF-8" Hi, we are pleased to announce that we have a CoMI Server implementation available for remote interoperability testing. In order to ease the process, we use f-interop (go.f-interop.eu). For those who don't know, f-interop allows to automatically manage the interoperability process. It also facilitates the remote testing process by creating tunnels, allowing two different implementations to interact with only few clicks. I also defined a YANG interoperability file (and generated its associated SID file). It's a very simple YANG file but I think we need to start with a very simple one. Our implementation manages so far GET, FETCH, PUT, IPATCH and DELETE request. For those interested, please-send me an email in order to discuss about what we can do/how to use f-interop, obtain the YANG and SID file, etc. Cheers, Tanguy PS: f-interop can be used only for Linux Debian-like OS and macOS for the time-being. --001a114bcfc25073d205678dd18f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    = Hi,
    we are pleased to announce that we have a CoMI Server implementati= on available for remote interoperability testing.

    In order t= o ease the process, we use f-interop (go.f-interop.eu). For t= hose who don't know, f-interop allows to automatically manage the inter= operability process. It also facilitates the remote testing process by crea= ting tunnels, allowing two different implementations to interact with only = few clicks.

    I also defined a YANG interoperability file (and= generated its associated SID file). It's a very simple YANG file but I= think we need to start with a very simple one. Our implementation manages = so far GET, FETCH, PUT, IPATCH and DELETE request.

    For those= interested, please-send me an email in order to discuss about what we can = do/how to use f-interop, obtain the YANG and SID file, etc.

    =
    = Cheers,
    Tanguy
    PS: f-interop can be used only for Linux Debian-li= ke OS and macOS for the time-being.

    --001a114bcfc25073d205678dd18f-- From nobody Sat Mar 17 05:13:17 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C27312778E; Sat, 17 Mar 2018 05:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 E0q8qp65PIo3; Sat, 17 Mar 2018 05:13:14 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49961270A3; Sat, 17 Mar 2018 05:13:10 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9A479477C5; Sat, 17 Mar 2018 13:13:08 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A4AD961; Sat, 17 Mar 2018 13:13:07 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2001:67c:370:128:d1a4:586c:a5dc:33d8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E0DB43A; Sat, 17 Mar 2018 13:13:06 +0100 (CET) Received: (nullmailer pid 11529 invoked by uid 1000); Sat, 17 Mar 2018 12:13:05 -0000 Date: Sat, 17 Mar 2018 12:13:05 +0000 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list , draft-ietf-lwig-coap@ietf.org Message-ID: <20180317121303.GA9258@hephaistos.amsuess.com> References: <20180305221945.GA25693@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20180305221945.GA25693@hephaistos.amsuess.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Strictness of RFC7959 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 17 Mar 2018 12:13:16 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, hello lwig-coap authors, On Mon, Mar 05, 2018 at 11:19:45PM +0100, Christian Ams=FCss wrote: > I am uncertain about the behavior RFC7959 actually prescribes to > servers: How liberal is it for servers about which blocks can be acted > on together (or when to send 4.08 Request Entity Incomplete)? At small discussion during the hackathon, there seemed to be a tendency toward interpreting Block1 to be keyed by (endpoint, endpoint, cache-key) rather than (endpoint, endpoint, path) -- however, that might not be fully explicit in RFC7959, and might call for either implentation guidance or even clarification by an update. To get this started, I propose the following paragraphs for lwig-coap (which might easily be moved around to other documents if they fit better there): --- ### 3.4.1 Proxying without deeper understanding of proxy operations Proxies can not ignore the Block options -- by specification, because Block are not safe-to-forward, and by rationale of messages from different clients being understood by the server to constitute an atomic operation. A proxy can, however, ensure that this does not happen by adding an option that prevents such confusion. Appending a Request-Tag (see {{I-D.ietf-core-echo-request-tag}}) that is derived from the requester's endpoint is one way to do that. ### 3.4.2 Atomic blockwise operations When an implementation does need to assemble blocks from block-wise transfers, applications need to form a key by which to identify messages that can be grouped together. This "Block Key" at least contains: * The source endpoint (eg. IP address and port in the UDP case) * The destination endpoint * The Cache-Key (as updated in {{RFC7252}}) * All options that are proxy unsafe and not explicitly described as safe for blockwise assembly. The only known options safe for blockwise assembly are the Block1 and Block2 options. For the Block1 phase, the request payload is excluded from the key generation as it is just being assembled. If a message is received that is not the start of a blockwise operation, has a Block Key that is not known, and the implementation needs to act atomically on a request body, it can only answer 4.08 Request Entity Incomplete. Conversely, clients should be aware that requests whose Block Key matches can be interpreted by the server atomically. This especially affects proxies (see 3.4.1). --- If the statements in this do not correctly reflect the intention of RFC7959, we should discuss this further to arrive with paragraphs that do. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqtBkwACgkQOY0REtOk veEX5Q/9GXcxV+TTb5auRgrfpibs+vZ1zsGkapLJvKi0jQgQ/l1A6wILTeSiFs0k KkcdkEDpghGYDyrw0lQIh7oCuxvpbeSWN8+FCipnreX42bYaNNkVUNiihZm2VB1D YpJxhOKWv3C0V8i/LMULrTi1VCoun8aoAYcaLPGTJv12waCiEKTSjPtjLUVzXJrP OvzDls+PXbWgicHTwaDYLE66//TG9vyCpvpTsc/4wgyWuRjJn6bIqW8K8wi6I3ZC UbYXgWs0HGqnZZ70VpvZXlDSVH4wGFqzEClagnIj7Km+R+VR4WUYyxA7bTJ/qxUy gm6A2ovpxXhdCfSyheWjNeQ+XqHsWtkFIvyMV+5+Jdd4BjsPK6u+ziZkB6Y6N7G+ b+FrUwYEd5iM/g2xBDhnFD2oJGBWAMPqW88R718BHYjTFOyWJJQ6tF5+PKQ7PXRq U2eFliKWLN4lTQT5zllz+OXi5a5ClMWqFrfvMKn4rXgCQCKgnhwKbeo1GLhHrtPf MZAQTYtyfjSncR7alLKYpw2iUCC3I9gRaX1jDpd6OvADr2TzGxxqbCpw1o3GaCSW a12v4ahLYz71XYBzNlC01OdrAwc5Q/2bFsAo4jxCer2MC8n77SN3hCxeph0WzgEV M6+YNKwzB7W0/CsouuI2oVqJmKFcE3uMMDrIKTgkt/i3/zKGsD8= =JN1T -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From nobody Sun Mar 18 10:21:20 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E812AF83 for ; Sun, 18 Mar 2018 10:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AVRMm9S_ih39 for ; Sun, 18 Mar 2018 10:21:12 -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 819EF12D87D for ; Sun, 18 Mar 2018 10:21:05 -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 w2IHL2Ee014071 for ; Sun, 18 Mar 2018 18:21:02 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:f0b2:f866:f411:a22c] (unknown [IPv6:2001:67c:1232:144:f0b2:f866:f411:a22c]) (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 4045ZQ2697zDXsY; Sun, 18 Mar 2018 18:21:02 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Sun, 18 Mar 2018 17:21:01 +0000 X-Mao-Original-Outgoing-Id: 543086459.958569-a4df98c19aeca93f4da9af7cbe01043f Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Core X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] CoRE @ IETF101 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 18 Mar 2018 17:21:16 -0000 The agenda has sustained a bit of change, please see: https://datatracker.ietf.org/meeting/101/materials/agenda-101-core again. We have moved CoCoA to Tuesday so we can have a Transport expert attend = (thanks to Gorry Fairhurst for taking the time!). In exchange, we have swapped over CoMI to Monday (and keep all of SenML = on Monday, too). (And lots of other little changes.) Please keep those slides (and objective statements) coming! Gr=C3=BC=C3=9Fe, Carsten > On Mar 15, 2018, at 12:22, Carsten Bormann wrote: >=20 > The chairs have uploaded a draft agenda to >=20 > https://datatracker.ietf.org/meeting/101/materials/agenda-101-core >=20 > Please have a look and check whether >=20 > =E2=80=94 your slot request is in there > =E2=80=94 the time allocated is appropriate >=20 > We=E2=80=99ll need to reduce the time on some items a bit so we have = more flextime at the end, so please do look if you can get useful work = done in less time as well as in more time=E2=80=A6 >=20 > As usual, please also send the objectives you have for your slot to = core-chairs@ietf.org so we can include them in the agenda. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 From nobody Sun Mar 18 15:28:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54429126B72 for ; Sun, 18 Mar 2018 15:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tObMUDt2ma29 for ; Sun, 18 Mar 2018 15:28:12 -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 3B9011200C5 for ; Sun, 18 Mar 2018 15:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2IMS887026655 for ; Sun, 18 Mar 2018 23:28:08 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:6d2b:aff:5f88:3927] (unknown [IPv6:2001:67c:1232:144:6d2b:aff:5f88:3927]) (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 404DNm5X5MzDXtw; Sun, 18 Mar 2018 23:28:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Sun, 18 Mar 2018 22:28:08 +0000 X-Mao-Original-Outgoing-Id: 543104886.9091851-37207d8fb0e25389af9ba7e374fb3f63 Content-Transfer-Encoding: quoted-printable Message-Id: <0F799E37-E3D4-421E-9DDE-E359767BC4F4@tzi.org> References: To: Core X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] CoRE @ IETF101 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 18 Mar 2018 22:28:14 -0000 I have uploaded an initial slide set: = https://datatracker.ietf.org/meeting/101/materials/slides-101-core-consoli= dated-slides For a lot of slots, slides are still missing. Slot leaders, please: =E2=80=94 check that the slides I did put in are the right ones =E2=80=94 send the slides that are missing 15 hours to our first meeting=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > On Mar 18, 2018, at 17:21, Carsten Bormann wrote: >=20 > The agenda has sustained a bit of change, please see: >=20 > https://datatracker.ietf.org/meeting/101/materials/agenda-101-core >=20 > again. >=20 > We have moved CoCoA to Tuesday so we can have a Transport expert = attend (thanks to Gorry Fairhurst for taking the time!). >=20 > In exchange, we have swapped over CoMI to Monday (and keep all of = SenML on Monday, too). >=20 > (And lots of other little changes.) >=20 > Please keep those slides (and objective statements) coming! >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Mar 15, 2018, at 12:22, Carsten Bormann wrote: >>=20 >> The chairs have uploaded a draft agenda to >>=20 >> https://datatracker.ietf.org/meeting/101/materials/agenda-101-core >>=20 >> Please have a look and check whether >>=20 >> =E2=80=94 your slot request is in there >> =E2=80=94 the time allocated is appropriate >>=20 >> We=E2=80=99ll need to reduce the time on some items a bit so we have = more flextime at the end, so please do look if you can get useful work = done in less time as well as in more time=E2=80=A6 >>=20 >> As usual, please also send the objectives you have for your slot to = core-chairs@ietf.org so we can include them in the agenda. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 From nobody Sun Mar 18 16:54:47 2018 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 F0AE012D810; Sun, 18 Mar 2018 16:54:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152141727894.15843.2582251484874029491@ietfa.amsl.com> Date: Sun, 18 Mar 2018 16:54:38 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dynlink-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 23:54:39 -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 WG of the IETF. Title : Dynamic Resource Linking for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Jintao Zhu Bilhanan Silverajan Filename : draft-ietf-core-dynlink-05.txt Pages : 19 Date : 2018-03-18 Abstract: For CoAP [RFC7252] Dynamic linking of state updates between resources, either on an endpoint or between endpoints, is defined with the concept of Link Bindings. This specification defines conditional observation attributes that work with Link Bindings or with CoAP Observe [RFC7641]. Editor's note: o The git repository for the draft is found at https://github.com/ core-wg/dynlink The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dynlink-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-05 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 Mar 19 03:31:07 2018 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 5A381126CBF; Mon, 19 Mar 2018 03:30:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152145545833.15916.3912812813455828666@ietfa.amsl.com> Date: Mon, 19 Mar 2018 03:30:58 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 10:30:59 -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 WG of the IETF. Title : Uniform Resource Names for Device Identifiers Authors : Jari Arkko Cullen Jennings Zach Shelby Filename : draft-ietf-core-dev-urn-01.txt Pages : 13 Date : 2018-03-19 Abstract: This memo describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dev-urn-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dev-urn-01 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 Mar 19 03:45:32 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEE7128D2E for ; Mon, 19 Mar 2018 03:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 vGgkZDdkm1sG for ; Mon, 19 Mar 2018 03:45:24 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0135.outbound.protection.outlook.com [104.47.2.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5276B126DEE for ; Mon, 19 Mar 2018 03:45:23 -0700 (PDT) Received: from AM4P121CA0001.EURP121.PROD.OUTLOOK.COM (129.75.24.15) by AM5P121MB0036.EURP121.PROD.OUTLOOK.COM (129.75.189.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.16; Mon, 19 Mar 2018 10:45:20 +0000 Received: from HE1EUR02FT048.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::203) by AM4P121CA0001.outlook.office365.com (2a01:111:e400:e2b1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.588.16 via Frontend Transport; Mon, 19 Mar 2018 10:45:19 +0000 Authentication-Results: spf=neutral (sender IP is 13.80.155.198) smtp.mailfrom=philips.com; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.80.155.198 is neither permitted nor denied by domain of philips.com) Received: from EDGE-VM-002.westeurope.cloudapp.azure.com (13.80.155.198) by HE1EUR02FT048.mail.protection.outlook.com (10.152.10.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.18 via Frontend Transport; Mon, 19 Mar 2018 10:45:19 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (213.199.180.145) by autodiscover.lighting.com (192.168.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1034.26; Mon, 19 Mar 2018 10:45:16 +0000 Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM (129.75.24.213) by VI1P121MB0063.EURP121.PROD.OUTLOOK.COM (129.75.190.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.16; Mon, 19 Mar 2018 10:45:14 +0000 Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::481b:1c16:5798:8142]) by VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::481b:1c16:5798:8142%14]) with mapi id 15.20.0588.017; Mon, 19 Mar 2018 10:45:14 +0000 From: Esko Dijk To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= CC: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRp?= =?utf-8?Q?loca-core-multicast-oscoap?= Thread-Index: AQHTurAvC8oUuZ4/xEaXKwtNH9s4nKPXaKRw Date: Mon, 19 Mar 2018 10:45:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [80.246.199.210] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; VI1P121MB0063; 7:zLBY06vmD7s/tv5GmK+UzOrGrqbuo8Op/Bc0B5fNvu0mK+CjpvDXpL4N+XmvLwdxcGyNvH5IFeb6fYbAbkN+QXqGWgm93iVHvgvziLZihDdZaM7pWvImLs57UO51z4gJQcrpgzARWEdJgrc3yOgaEn+xBorFdmAYAs/VhyB0OBXzpN3kJvtkYqIWSw92gfTpcOK0/6cympbS9oHV/3Xfu6MxcJhVjDcekDi2gzpwoTeEUp8RTdGdrqsaZxR6pHId x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 41eb0853-4c0c-41d0-5d1c-08d58d868271 X-Microsoft-Antispam-Untrusted: UriScan:(260087099026482); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:VI1P121MB0063; X-MS-TrafficTypeDiagnostic: VI1P121MB0063:|AM5P121MB0036: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(278428928389397)(192374486261705)(100405760836317)(21748063052155)(260087099026482); UriScan:(37575265505322)(28532068793085)(278428928389397)(192374486261705)(100405760836317)(21748063052155)(260087099026482); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231221)(944501300)(52105095)(3002001)(6055026)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:VI1P121MB0063; BCL:0; PCL:0; RULEID:; SRVR:VI1P121MB0063; BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93003095)(3002001)(3231221)(944501300)(52105095)(10201501046)(6055026)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061750153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AM5P121MB0036; BCL:0; PCL:0; RULEID:; SRVR:AM5P121MB0036; x-forefront-prvs: 06167FAD59 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(396003)(39380400002)(199004)(189003)(377424004)(5250100002)(4326008)(55016002)(33656002)(9686003)(26005)(316002)(54906003)(6246003)(81156014)(53936002)(53546011)(236005)(25786009)(8936002)(81166006)(105586002)(478600001)(3846002)(7696005)(6116002)(6506007)(186003)(76176011)(99286004)(6916009)(6306002)(2950100002)(106356001)(68736007)(102836004)(93886005)(229383001)(54896002)(59450400001)(66066001)(2906002)(7736002)(966005)(229853002)(606006)(2900100001)(74316002)(86362001)(3280700002)(19609705001)(3660700001)(575784001)(790700001)(53946003)(14454004)(6436002)(97736004)(5660300001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P121MB0063; H:VI1P121MB0014.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) X-Microsoft-Antispam-Message-Info-Original: uWJ8t0Bk4cS7uYVqp/FM2niWe68f+ubNQsDurv7zayvMeXA5qGJFREOhkgOwblbs7zFe9jPV0/BHMDBsnvt4p2D+3s0yvKDnPuxhAMNnQjM4SPMbAE0d2nW4ujASlxFbIDbSatDyMxC/w29eA+koxwN+i3MORmcZ+LFW8Lil7LCW7Y7lCqlNO+rlsHxv0uS3WZZporhz0mjIuDqrcOgjlg9yKbkhWMp/24FQE/a8NtFArMd8cRldG6rxtvjz3h7s7cCi6dYW5kIZQ74qp4EMHJuWqMC5iJOUz2YqcZTUz20tuJeZQ3461hJgmPR3Lo50VHViZgnj5pLhBvgKhc5SXA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1P121MB0014D688CCED02667AA3E38B9BD40VI1P121MB0014EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0063 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: HE1EUR02FT048.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.80.155.198; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39380400002)(346002)(39860400002)(396003)(376002)(2980300002)(199004)(189003)(377424004)(16586007)(6506007)(59450400001)(6246003)(606006)(5660300001)(9686003)(68736007)(53946003)(99286004)(316002)(26005)(55016002)(33964004)(81166006)(8936002)(61614004)(81156014)(14454004)(6306002)(53936002)(2906002)(86362001)(575784001)(229853002)(356003)(54896002)(336012)(236005)(53546011)(2950100002)(102836004)(84326002)(6916009)(106466001)(93886005)(33656002)(25786009)(5250100002)(229383001)(966005)(6116002)(105586002)(790700001)(2900100001)(3846002)(54906003)(22756006)(76176011)(4326008)(7736002)(66066001)(74316002)(498600001)(26826003)(97736004)(7696005)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P121MB0036; H:EDGE-VM-002.westeurope.cloudapp.azure.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT048; 1:94ADSaM646eu2kFRsYW3wZyOPmh/H1B1dvkj557JGtw3v3RdgvtPvDP/jDoZzt8VkrXV5hG/gCPBcaX99u7Bn2nLAjkA/tIisZStjdwPoCcsVLOft57i59647kjITfws X-Microsoft-Antispam: UriScan:(260087099026482); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(4534165)(4627221)(201703031133081)(8559017)(8990040)(2017052603328)(7193020); SRVR:AM5P121MB0036; X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0036; 3:TV0pOPpLt4DFZJfVFNI8iQgn+lC3+vJktJhapZjqCzjFkBXKNc/wFDTQ6awL5sXZNxm+ekq0uHwkEBFIn20v752IiYOKBRdPunxyQGYNOh8erlw9irC6hVSSQq18cwzrCv1D1WM2w7/QUA7inUwOH63KEmAi6L40CSeg7Ld04MiW7DGS56jR4BVaswXt64U5GbpY1FpM8DBDMSPb4eSsQha59/iaOtqQ2yNZp5g/rKY3zdp6Pj6aP+wXziKP9hd/LfCfQemstkY6aTewm53/cV7nuzNLqiwnR77eNUjfOx7/Y881r0O3CfQKxLM/MrXV4Jr2vGVM1CgZS3mKz1WOrM0ymTJ8RLaxP9XrXJupFfGwyKzNG8AhWvYHbY1QweAeVejZD9KyE7DlCifZh9wuNA==; 25:gz/z/cPNn3MHIKWkZJo841tOwwnGpZ4zqNmssrl+THNcnjwSdhplCL+mzMt1vR8THSfgmcfyYWvKQZttFgUlrirlvnoaqzTMYr9hrC2iPoq7KB423HP8iQTVF8krJxn98P3U34JWmzZfM9UYCyVT+/uTVIU6+Zfp77lv+z7hbzQ3fA4H9yaYxjSzCb5JO/xWUJJpZUf1koCXD53P6R2maouhOoWDN4zfTXEryCoexgsU14NPDsfGxw6sGm4jxAqFGTRCDTiPZV58MNrMBqYoRS5ntO3pZ7fRLmNdK9nuMHY2kyEuaKVHtFX82yMWrWVbp1cEEsWP6/xnNjEmBiz9eg== X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0036; 31:kMVLzVM5SrdMiHriJG/2UNCYoGqodyskM3L+gBymObnpxn54XhAICtOHud18GMmLAfYnNdHTqEELKaKP6DCwtcQ9RhaByh0kp+Nlv7HNdB8GrJ74abQoljqZn6USCL/StPDAdW+z/nfJaZ8W59rnwLpwb/Zcs57PlS3j//AFPU8tZLYk5Anntfw8VrM4HDyKSwkbG/mSRkX9Yvcj+bZFCW8gxG50BnVJS/IBUSgdTWs=; 20:DcL0+eMmtSezgMB5iJX9/1jW07Vwc0memmkG0lTMXH9lRHuZwAA7FOMyp9VGkLiLVTvcKJ/sgyQv0zV1sb4TBoyrvmcS2XOJSsGw/wmDK6XA+x84NEhv2MgsWHgHFRgJa7mb+ljvgDkVxSpQNht99llQts9HJEdy9xKY8NXysdQZa8kuId8AgYZpUQPHnMeeD5eZicRV/szxCo3XXSqpiyIWqT/6Uoxeu//b3+yXOHvANyfCnqqXh4nh4hJrnq5CxOHtQnJnVBkWqKHQG3oH/avE6Z6eJMJuwA2AJ+LYfYQaIX8Qqp+ql0B07S22yjs7T4GDPM6BX+PnhSkqLGWSSS0sD3ezHRCJiRswlCJj8W3UpTigdQ1ZXhi7vKmr1ITVyJjnxGQtdrRgsJBsrLGvFDcx7F66IN42I5uv4XQYs+e+FxDUToh2I/yD18/Fr4Hz+ig6wToopHkGZbvGe9X977iEExvnDfFiBVhokFikJJNec27I/IBnwxVQxyva47R/ X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0036; 4:i1T3FJ496Rb1Qv66o8OalvhWmMYPAO25/9dUl2FIfdqmaj7rs9ysCuY6j6u4ZlGnFM1fvbncmqMeAXofF+IicKDrchDMPbrHMZvCYbpjeJQPMCDhHKsMwgjvBeHOEmgf9RN5JuSkIiWu3o647sqSMX8bV4A+BHfyFjSuU2t1c+DCUlz3Z5babjn7r7fIyq7ujsKkvmcZZVryg6EUoBSDHNRbwaPHM5xOcTvdnFF1Yb2MIwfKF76r+WjibGVkGwe22Pb6fyfWkwKmIDpX6+nQGQL0amDw49dGI3q7RyXCAUDITQevtbjWKw9d0BRS+OZJSVEVvmupeQKCnEz0KyMUz92WwnHRhwcmC8oTBshlHd+8gQHPU3K5HXJETORMceeDsJRmWdaHL5DJb/bKf0Z0kN720IQJAOUkO6wj4YituWVLQPMhG6Uexft8xcOavQO56Gbr01+vXkGmZkDsGmvOBNtBhk6ZgMUSfj1Mkyj6inErpkTRzb7XhXLD38fr/TOZG76txXsy4qFMmv4QhIb02w== X-Forefront-PRVS: 06167FAD59 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5P121MB0036; 23:f0GzntKmOJziyyisAdawDIxkUl3lATxCz9rkocY/4?= =?us-ascii?Q?e/dg9/vmJiJrmFWszZyDYuczPobxySKTFTyM8lK8MaKXLc3clIYiCHQmmyQA?= =?us-ascii?Q?XJPZlmcycoVmoD67feqNr6vdsCJpfzSXb0DvJXJSDfXygiksfHSkSdKoEfJ/?= =?us-ascii?Q?Oqj2p/zElGgHEeaDUR7TQnSS3PFQSOLfMkGhYmj26lEoiszk1P3UBu2Vq3DU?= =?us-ascii?Q?JqS1axlpOeh4WGUmnP6wtwwFXQNH2IrRjtpwuBAQ9YBBYPCrR7tgt6F2KYT4?= =?us-ascii?Q?nBMpbNtS1URUesUtdgTWEJxw8vkv9r4EdXkIBxO0GRj7xheFGaTp9WNPuIiV?= =?us-ascii?Q?oZjbc7NV2+WTe8MNIhz1I6HSTcXwuqZiI+X7Tw/bKfTtRz3KTaQitUp3Gnmy?= =?us-ascii?Q?3p42Pvt+GDE6fH99yafMTz3jdG2LQW2kLBuauGO/2xDo+2Ayjj0RvajW+bTr?= =?us-ascii?Q?jVCn2jP72HpeUZYri73rl+Nk+FtYxfTYgLsnBWUe/u0Sj8LyuF77Fi7MIjN8?= =?us-ascii?Q?0OIwUCQOul+c470m4/tdGrunqPhOa31GUfQefkpiexaDeDHzYqI4RHlPzJUU?= =?us-ascii?Q?OSpxicVW4saQbvFUcU2b8Ui4jiSOorDKh0AHRbw79V3YlZSWGoXP1f0kHMr9?= =?us-ascii?Q?Bgj3GpEw6guF5gT+kems/4IBN5qjGSi0NBqFEjfmOMA3cVOOQx4dEhlRepPP?= =?us-ascii?Q?Bf6vH/wEPUFu18SGvLunHvGjEjS88gUCMrGEJGTi4RyMxuSH53JWNbXBoheX?= =?us-ascii?Q?oPx8C9q91EA+GdiOxjdNtAyPwVHxmsSssXnGcV4C2zeuBXfYkVUMBdhN2IZY?= =?us-ascii?Q?zBCtjLiuhWMskAoZEJHIt/2P3oXYM1GMHO5xmZqjVL5cWWzrlKvgTJzOcbya?= =?us-ascii?Q?pCGz1/wCqr//0G1XvaSdl0TgsR8IDHF8EBTV/PkoPOaR/wjC18mgL2NFeMXF?= =?us-ascii?Q?6NCbRF6WptT8QLwN1O2paxaDxB/joq37BhcfQOvR1m2lIb84UHnzLj5sdPk4?= =?us-ascii?Q?z5IjrZ58WkSQrecPxsBgPr067cSXGZFxNcWh7KnBOhEIucQXPxERM4aDD1Mb?= =?us-ascii?Q?jee2pYIFwfXIxMMWNA5wVz5ALpuhEfwfstSssZYSf39cQt/KU1joIgvP1MYX?= =?us-ascii?Q?cBWUu6L6hXKCoz1lMiknCPwNrWAFvHgkh91cRZHqWectljae0DbS/qSj2eKg?= =?us-ascii?Q?mWMiQIs2wznvlA0dWOL/RrDbiV4fIdeeD+hUEVknuppQDu1Mi4C2EPN+MwQn?= =?us-ascii?Q?3L3J7QHCB0Y1LWH+GghGMkVr+Qqy4CJ4QV/pN5nszXZwSq4oZlqDj0HIv0pB?= =?us-ascii?Q?W9QLrSYKxBjjWi+fSp9IiuHNQo7HpF3wCsag8oRIirg7HcKCRGTMsI2uscFo?= =?us-ascii?Q?I+dI5voR5mjFDSwV40yuP3PhwIuPok6g/s0w6Kfy5+upAV5WF8kLAwgK9Ogl?= =?us-ascii?Q?dTJzBLFT1s8ry0cCvVfId0ba1jiSctrQP7pGAigXpIzFdB1jZsGRycItviub?= =?us-ascii?Q?EtMjZUPbM/IlQ4YpKkhjQFpiGaGZEYL7LPK8/UguB6Dx5LKPiWguTfU?= X-Microsoft-Antispam-Message-Info: PkqZyu25BkxuU7Z+0hP1pBOAxqMTdSuFySpwb+5A9dtVYBRNBYgnFYYl7hgnB/rMGo5xda+8qbAkx52aEcft1wSH8VS+VuVNQy5DcGmnWG5xaEvqT/N4zMbVfKVNI/Ziqfo+f8BnbK3+dHVgD3BPkaSZxnpZ4p5alZFvLqmX8zdTGcmbxcwLqgIjPEHzuoIL3Oo7K7e6K8aTQ2QO3t0n5sG6Hrklh4AxOUEJvxQoNPtXbYA7DHMAYa82z2rlcH/Obn0P0ssLx1sN4OCleCInhcgMJLQ0N269p0KjXdsaJPAD6LD9GQHOlqqQgs4ObK0YXQ3aC0hx7aLQ70MNp7MHig== X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0036; 6:H/NMYKBNZzDug7XvOTY9OtyA6h9/4n/Xtx+yxVXlElfqS4gv5VgReN4XIjXk2Ora6aPGQDnFCryqTDPqjmYMx8x74L3tDQumBpMFC8WVsF+FdvJLwhJKjFOC4KgrzUYL0UJSQqNam1ZI7QSCDYsDxz1WcuPr7Dzw5eimma684S9VpySaP0q4/eBtSx+GqHZ/877L1cjZMMzbfJYu97A7/PG73sCLqi3nhkAmsVP54y0CCy5p4YBL/Op7JIlgOYW+mSCWmkd+x0uHinsasOESw3XP1zzx6OZfXf/q10LblGd+E3kjOwJw1x9wyQF5rlHvr3yPoBB54/gwMuibz6yVqOYP5i6Xh6vvGj8R0cAdlf2J9dcIR3jjC1jo8K2/dff+SMIsFxFgpe7bgYY57P7VHQ==; 5:LwW6FdSvGdQ+Z0oXCU+kbMPOeIrOP4xnhbQ+EyunVu4Yt2mVbUcco49hXA0GBu8vkJEbtrCULbQkSpadnGeTNGsXT06c1F7n8T12UBTEGIdKsXyHDnDTCT8NgZPYoXP3XAdEdcG0UyO0mawdXB92B/WKZbCeMKOQf71WGo8Jbok=; 24:APgFHwAe+aT1VX3qBgMEEQhzyAv1oNuq064y8TjN81dAW1mptxCXFhWdvNXNIVzdGVtNSKhqlZLrqO7HNzDPX5yU0+/n4m0+wYFiVf3wfrc= X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0036; 7:Opeugo/Q70Axq6DiS9ylXNcrAfJKvcDP2oNHIlBorVUIJ1JWWs9MAyknCPsUxqAIxIid+ywSJsHCCEzZewJ3iSOioC1AYOwy+cyPpojbf0fGKz8R0UriB2qmmR3PGug4yqdOqaoWBx34f7NAg1tG8BT0i3nwApAgil4H7QPahjybqjHoi5NjNTM2Tfd2lJUTjCnEbXxVYm5cocVAwfOtUiurhRrmTrL0Z7pYUPb2p2U8snrKpUSRsKjTQcugakl2 X-OriginatorOrg: lightingaad.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2018 10:45:19.4207 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 41eb0853-4c0c-41d0-5d1c-08d58d868271 X-MS-Exchange-CrossTenant-Id: 75b2f54b-feff-400d-8e0b-67102edb9a23 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=75b2f54b-feff-400d-8e0b-67102edb9a23; Ip=[13.80.155.198]; Helo=[EDGE-VM-002.westeurope.cloudapp.azure.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P121MB0036 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-tilo?= =?utf-8?q?ca-core-multicast-oscoap?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 10:45:28 -0000 --_000_VI1P121MB0014D688CCED02667AA3E38B9BD40VI1P121MB0014EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCB0aGF0IGlzIGNsZWFyIG5vdy4gU28gcmVwaHJhc2luZyB0aGUgdGVybSDigJxuZWds aWdpYmxlIHByb2JhYmlsaXR54oCdIGluIFNlY3Rpb24gMiBhbmQgQXBwZW5kaXggQyBjb3VsZCBo ZWxwIGluIHRoaXMgcmVzcGVjdC4gSG93IHNtYWxsIHRoaXMgcHJvYmFiaWxpdHkgc2hvdWxkIGJl IGlzIHVwIHRvIHRoZSBzeXN0ZW0gZGVzaWduZXIgaW4gdGhpcyBjYXNlLg0KDQpFc2tvDQoNCkZy b206IEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPg0KU2VudDog VHVlc2RheSwgTWFyY2ggMTMsIDIwMTggMTA6NDcNClRvOiBFc2tvIERpamsgPGVza28uZGlqa0Bw aGlsaXBzLmNvbT47IGNvcmVAaWV0Zi5vcmcgV0cgKGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYu b3JnPg0KQ2M6IE1hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhQHJpLnNlPg0KU3ViamVjdDogUmU6 IFtjb3JlXSDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRpbG9jYS1jb3JlLW11 bHRpY2FzdC1vc2NvYXANCg0KSGkgRXNrbywNCg0KVGhhbmtzIGZvciBnb29kIGNvbW1lbnRzIQ0K DQpMZXTigJlzIHJlY2FwIHRoZSBzZXR0aW5nOiBUaGUgc2VuZGVyIGFuZCByZWNpcGllbnQgb2Yg YSBncm91cCBPU0NPUkUgbWVzc2FnZSBuZWVkcyB0byByZXRyaWV2ZS9kZXJpdmUgdGhlIHJpZ2h0 IHNlY3VyaXR5IGNvbnRleHQgZm9yIHNlbmRpbmcgYW5kIHJlY2VpdmluZyByZXF1ZXN0cyBhbmQg cmVzcG9uc2VzLCBhbmQgdGhlIGFtb3VudCBvZiBkYXRhIHNlbnQgZm9yIHRoaXMgcHVycG9zZSBz aG91bGQgYmUgYXMgc21hbGwgYXMgcG9zc2libGUuIFRoaXMgc2hvdWxkIGFwcGx5IHRvIGFsbCBw aGFzZXMgb2YgY29tbXVuaWNhdGlvbjsgZmlyc3QgdGltZSwgbm9ybWFsIG9wZXJhdGlvbiwgYWZ0 ZXIgbWVtYmVyIGhhcyBiZWVuIGV4Y2x1ZGVkLCBldGMuDQoNCg0KDQpUaGUgT1NDT1JFIG1lc3Nh Z2UgZm9ybWF0IGluY2x1ZGVzIHRoZSAna2lkJyBhbmQgdGhlICdraWQgY29udGV4dCcuIEZvciB0 aGUgZ3JvdXAgc2V0dGluZzoNCg0KKiB0aGUga2lkIGNvbnRhaW5zIHRoZSBJRCBvZiB0aGUgc2Vu ZGluZyBncm91cCBtZW1iZXIgKFNlbmRlciBJRCksIHVuaXF1ZSBpbiB0aGUgZ3JvdXAsIGFzc2ln bmVkIGJ5IHRoZSBncm91cCBtYW5hZ2VyICh3aGljaCBjb3VsZCBiZSBqdXN0IGEgc2hvcnQgYnl0 ZSBzdHJpbmcpLg0KDQoqIFRoZSBraWQgY29udGV4dCBjb250YWlucyB0aGUgZ3JvdXAgaWRlbnRp ZmllciwgYWxzbyBhc3NpZ25lZCBieSB0aGUgZ3JvdXAgbWFuYWdlciBhbmQgdW5pcXVlIGZvciB0 aGlzIGdyb3VwIG1hbmFnZXIuIFRoZSBraWQgY29udGV4dCBpcyBhICJjb250ZXh0IGhpbnTigJ0g aGVscGluZyB0aGUgcmVjaXBpZW50IGVuZHBvaW50IGZpbmQgdGhlIHNlY3VyaXR5IGNvbnRleHQu IElmIGVuZHBvaW50cyBhcmUgZGVwbG95ZWQgd2l0aCBtdWx0aXBsZSB1bmNvb3JkaW5hdGVkIGdy b3VwIG1hbmFnZXJzIHRoZW4gdGhleSBuZWVkIHRvIGJlIGFibGUgdG8gaGFuZGxlIGNvaW5jaWRp bmcgZ3JvdXAgaWRlbnRpZmllcnMsIGUuZy4gYnkgdHJ5aW5nIG11bHRpcGxlIHNlY3VyaXR5IGNv bnRleHRzIHRvIHNlZSBpZiBpZiBhbnkgdmVyaWZpZXMuIEFzIGxvbmcgYXMgdGhlIE1hc3RlciBT ZWNyZXQgaXMgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgZ3JvdXBzIChhbmQgZGlmZmVyZW50IGVw b2NocyBvZiBhIGdyb3VwKSBhbmQgdGhlIFNlbmRlciBJRHMgd2l0aGluIHRoZSBncm91cCBhcmUg dW5pcXVlLCB0aGF0IGlzIHN1ZmZpY2llbnQgdG8gbWFrZSBBRUFEIGtleSBhbmQgbm9uY2UgZGlm ZmVyZW50Lg0KDQoNCg0KU28gdGhlcmUgaXMgbm8gbmVlZCBmb3IgbmVnbGlnYWJsZSBwcm9iYWJp bHR5IG9mIGNvaW5jaWRpbmcgZ3JvdXAgaWRlbnRpZmllcnMgYXMgbG9uZyBhcyB0aGUgcmVjaXBp ZW50IGNhbiBmaW5kIGl0cyB3YXkgdG8gdGhlIHJpZ2h0IHNlY3VyaXR5IGNvbnRleHQuIEJ1dCBp biB0aGUgY2FzZSBvZiBhbiBlbmRwb2ludCBiZWluZyBpbiBtdWx0aXBsZSBncm91cHMgbWFuYWdl ZCBieSBkaWZmZXJlbnQgZ3JvdXAgbWFuYWdlcnMsIGl0IGlzIG9mIGNvdXJzZSBmYXZvdXJhYmxl IGlmIHRoZSBncm91cCBpZGVudGlmaWVycyBhcmUgZGlmZmVyZW50LiBTbyB3ZSBzaG91bGQgcmVw aHJhc2UgdGhpcyBhY2NvcmRpbmdseS4NCg0KDQoNCkZ1cnRoZXIgY29tbWVudHMgaW5saW5lLg0K DQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBFc2tvIERpamsgPGVza28uZGlqa0BwaGlsaXBzLmNvbTxt YWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tPj4NCkRhdGU6IFdlZG5lc2RheSA3IE1hcmNoIDIw MTggYXQgMDk6MjkNClRvOiBNYXJjbyBUaWxvY2EgPG1hcmNvLnRpbG9jYUByaS5zZTxtYWlsdG86 bWFyY28udGlsb2NhQHJpLnNlPj4sIEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTxtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+PiwgImNvcmVAaWV0Zi5v cmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+IFdHIChjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGll dGYub3JnPikiIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbY29yZV0g8J+UlCBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29y ZS1tdWx0aWNhc3Qtb3Njb2FwDQoNClRoYW5rcyBNYXJjbywNCg0KVGhpcyB1cGRhdGUgc29sdmVz IHRoZSBpc3N1ZXMgSSB0aGluayBhbmQgYW5zd2VycyBteSBxdWVzdGlvbnMsIGV4Y2VwdCBmb3Ig dGhlIHJhbmRvbW5lc3MgaW4gdGhlIEdpZDogIOKAnEEgR2lkIE1VU1QgaGF2ZSBhIHJhbmRvbSBj b21wb25lbnQgYW5kIGJlIGxvbmcgZW5vdWdoLCBpbiBvcmRlciB0byBhY2hpZXZlIGEgbmVnbGln aWJsZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb25zIGJldHdlZW4gR3JvdXAgSWRlbnRpZmllcnMg ZnJvbSBkaWZmZXJlbnQgR3JvdXAgTWFuYWdlcnPigJ07IGFuZCBBcHBlbmRpeCBDLg0KDQpUaGUg ZXhhbXBsZSBBcHBlbmRpeCBDIHVzZXMgYSBzaW5nbGUgcmFuZG9tIGJ5dGUuICBNb3N0IHBlb3Bs ZSB3b3VsZCB0aGluayB0aGUgY29sbGlzaW9uIHByb2JhYmlsaXR5IGlzIHF1aXRlIGhpZ2ggaW4g dGhpcyBjYXNlOyBzbyBob3cgY2FuIHRoaXMgY2hvaWNlIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50 Pw0KDQpTZWUgYWJvdmUuDQoNCk1heWJlIGluIHRoaXMgZXhhbXBsZSB0aGUgR3JvdXAgTWFuYWdl cnMgcGljayBhIHJhbmRvbSB2YWx1ZSBhbmQgdGhlbiBtdXR1YWxseSB2ZXJpZnkgdGhhdCB0aGVy ZSBhcmUgbm8gY29sbGlzc2lvbnM/DQoNCg0KWWVzLCBpZiB0aGVyZSBpcyBjb29yZGluYXRpb24g YmV0d2VlbiBncm91cCBtYW5hZ2VycywgYnV0IHRoaXMgaXMgbm90IG5lY2Vzc2FyeSBmb3IgdGhl IHNjaGVtZSB0byB3b3JrIGFzIG5vdGVkIGFib3ZlLg0KDQpUaGUgbmFtZSDigJxHcm91cCBFcG9j aOKAnSBjb3VsZCBiZSBzbGlnaHRseSBjb25mdXNpbmcgaGVyZSDigJMgQXBwZW5kaXggQyBzdGF0 ZXMgdGhlIGVwb2NoIGFwcGxpZXMgdG8gYSBzaW5nbGUgZ3JvdXAuIEhvd2V2ZXIgdGhlIGV4YW1w bGUgdGhlcmUgc2hvd3MgdGhlIGVwb2NoIGFwcGxpZXMgdG8gYWxsIGdyb3VwcyBmcm9tIHRoZSBz YW1lIEdyb3VwIE1hbmFnZXIsIG9yIGluIG90aGVyIHdvcmRzIHRoZSBlcG9jaCAqaXMqIHRoZSBn cm91cC4gKEJlY2F1c2UgdGhlcmUgaXMgbm8gdGhpbmcgbGlrZSDigJxHcm91cCBJROKAnSBpbiB0 aGUgZXhhbXBsZSwgb25seSBHTSByYW5kb20gYnl0ZSBhbmQgR3JvdXAgRXBvY2ggYnl0ZXMuKSAg V2FzIGl0IGludGVuZGVkIHRvIGFkZCBhIGJ5dGUgb3Igc28gZm9yIOKAnEdyb3VwIElE4oCdID8g U28gdGhhdCBlYWNoIGdyb3VwIGNhbiBoYXZlIGl0cyBvd24gZXBvY2ggY291bnRlci4NCg0KDQpU aGUgaW50ZW50IHdhcyB0aGF0IHRoZSBHcm91cCBJRCBjb25zaXN0cyBvZiBhIEdyb3VwIFByZWZp eCBhbmQgYSBHcm91cCBFcG9jaC4gVGhlIG5lZWQgZm9yIGEgZ3JvdXAgcHJlZml4IGlzIHRvIGFs bG93IGEgY29uc3RhbnQgaWRlbnRpZmllciBvZiB0aGUgZ3JvdXAuIFRoZSBuZWVkIGZvciBncm91 cCBlcG9jaCBpcyB0byBhbGxvdyBlbmRwb2ludHMgdG8gZmluZCB0aGUgcmlnaHQgTWFzdGVyIEtl eXMgdXNlZCBpbiB0aGUgZ3JvdXAgYXQgYSBjZXJ0YWluIHRpbWUuDQoNCiBHcm91cCBpZGVudGlm aWVycyBtYXkgYmUgY29uc3RydWN0ZWQgaW4gb3RoZXIgd2F5cyB0aGF0IG1ha2VzIHRoZSByZWNp cGllbnQgZmluZCB0aGUgcmlnaHQgc2VjdXJpdHkgY29udGV4dC4NCg0KSG9wZSB0aGF0IGhlbHBz Lg0KDQpUaGFua3MsDQpHw7ZyYW4NCg0KDQpFc2tvDQoNCg0KDQpGcm9tOiBNYXJjbyBUaWxvY2Eg PG1hcmNvLnRpbG9jYUByaS5zZTxtYWlsdG86bWFyY28udGlsb2NhQHJpLnNlPj4NClNlbnQ6IE1v bmRheSwgTWFyY2ggNSwgMjAxOCAyMzoxOA0KVG86IEVza28gRGlqayA8ZXNrby5kaWprQHBoaWxp cHMuY29tPG1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20+PjsgSmFpbWUgSmltw6luZXogPGph aW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPG1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNv bT4+OyBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPiBXRyAoY29yZUBpZXRmLm9y ZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4pIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBk cmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwDQoNCg0KSGVsbG8gRXNrbywNCg0KDQoN ClRoYW5rcyBmb3IgeW91ciBzdXBwb3J0IGFuZCBjb21tZW50cywgd2UgaGF2ZSBjb25zaWRlcmVk IHRoZW0gd2hlbiBwcm9kdWNpbmcgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSAgZHJhZnQgWzFd Lg0KDQoNCg0KUGxlYXNlLCBmaW5kIGluIGxpbmUgc29tZSBhbnN3ZXJzIHRvIHlvdXIgY29tbWVu dHMuDQoNCg0KDQpCZXN0LA0KDQovTWFyY28NCg0KDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9zY29yZS1ncm91cGNvbW0tMDENCg0KT24gMjAxNy0x Mi0wNCAxNDozNSwgRXNrbyBEaWprIHdyb3RlOg0KSSBhbHNvIHN1cHBvcnQgdGhlIGFkb3B0aW9u IG9mIHRoaXMgZHJhZnQgYXMgYSB3b3JrIGl0ZW0gZm9yIENvUkUuIEJlbG93IGFyZSB0aGUgcmVz dWx0cyBvZiBhIHF1aWNrIHJldmlldywgYWxzby4NCg0KQmVzdCByZWdhcmRzDQpFc2tvIERpamsN Cg0KDQpPdmVyYWxsIGNvbW1lbnRzIOKAkyBvciB3b3JrIHRoYXQgdGhlIFdHIGNvdWxkIHRha2Ug dXAgbmV4dA0KwrcgICAgICAgICBEZXRhaWxlZCBleGFtcGxlIHdpdGggbWVzc2FnZSBzaXplcyB3 b3VsZCBiZSB1c2VmdWwuIFNpbmNlIGl04oCZcyBpbXBvcnRhbnQgZm9yIG11bHRpY2FzdCBvdmVy IDZsb3dwYW4gcGVyZm9ybWFuY2UgdGhhdCB0aGUgSVB2NiBwYWNrZXRzIHN0YXkgc21hbGwgZW5v dWdoIChvbmUgODAyLjE1LjQgZnJhbWUpLiBBdCB0aGlzIG1vbWVudCwgSSBjYW7igJl0IGp1ZGdl IHRoYXQgeWV0IGVhc2lseSBiYXNlZCBvbiB0aGUgZHJhZnQuDQoNCg0KW01UXSBXZSBoYXZlIG5v dyBpbmNsdWRlZCBkZXRhaWxlZCBleGFtcGxlcyBpbiBTZWN0aW9ucyAzLjEgKFJlcXVlc3QpIGFu ZCBTZWN0aW9uIDMuMiAoUmVzcG9uc2UpLg0KDQoNCg0KwrcgICAgICAgICBOb3JtYWxseSwgZm9y IGFwcGxpY2F0aW9ucyAoZS5nLiBCdWlsZGluZyBhdXRvbWF0aW9uIGFuZCBsaWdodGluZykgZ3Jv dXBzIGRvIG5lZWQgYSBzdGFibGUgYW5kIG5vbi1yYW5kb20gZ3JvdXAgSUQsIHRoYXQgaWRlbnRp ZmllcyB0aGUgZ3JvdXAgb3ZlciB0aW1lIGV2ZW4gYXMgY2hhbmdlcyBvY2N1ciwgZS5nLiBtZW1i ZXJzIGFkZGVkL3JlbW92ZWQuIFRoZSDigJxHaWTigJ0gaW4gdGhlIGRyYWZ0IGhvd2V2ZXIgY2hh bmdlcy4gVGhlcmUgY291bGQgYmUgc29tZSB0ZXh0IGFkZGVkIHRvIGV4cGxhaW4gaG93IEdpZCBp cyBsaW5rZWQgdG8gYSBzdGFibGUgSUQuIEUuZy4sIHRoaXMgY291bGQgYmUgY29uZmlndXJlZCBi eSB0aGUgR3JvdXAgTWFuYWdlci4gVGhlIHN0YWJsZSBncm91cCBJRCBpcyB0aGVuIG5vdCB1c2Vk IG92ZXItdGhlLXdpcmUgZm9yIG11bHRpY2FzdCBPU0NPUkUuDQoNCg0KW01UXSBJdCBpcyB0cnVl IHRoYXQgdGhlIEdpZCBpbiB0aGlzIGRyYWZ0IGNoYW5nZXMgb3ZlciB0aW1lLCBlc3BlY2lhbGx5 IHVwb24gcmVuZXdpbmcgdGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbCwgYW5kIHRoZSBHcm91cCBN YW5hZ2VyIGlzIHRoZSBvbmx5IHJlc3BvbnNpYmxlIGZvciBtYW5hZ2luZyBpdHMgdmFsdWUgdXBk YXRlLiBIb3dldmVyLCB0aGlzIEdpZCBoYXMgdG8gYmUgaW50ZW5kZWQgYXMgdGhlIGlkZW50aWZp ZXIgb2YgdGhlIE9TQ09SRSDigJxzZWN1cml0eSBncm91cOKAnSwgaW5jbHVkaW5nIGFzIG1lbWJl cnMgdGhlIGVuZHBvaW50cyB0aGF0IHNoYXJlIHRoZSBzYW1lIENvbW1vbiBTZWN1cml0eSBDb250 ZXh0Lg0KDQpbTVRdIEFzIHlvdSBzYXksIGFwcGxpY2F0aW9ucyBkbyByZWx5IG9uIGEgc3RhYmxl IGFuZCBub24tcmFuZG9tIGdyb3VwIElELCB3aGljaCBpcyBub3QgdXNlZCBvdmVyLXRoZS13aXJl IGZvciBncm91cCBPU0NPUkUsIGFuZCBpbnN0ZWFkIGlkZW50aWZpZXMgYW4g4oCcYXBwbGljYXRp b24gZ3JvdXDigJ0gaGF2aW5nIGFzIG1lbWJlcnMgdGhlIGVuZHBvaW50cyB0aGF0IHBhcnRpY2lw YXRlIGluIGEgc2FtZSBncm91cCBhcHBsaWNhdGlvbi4gVGhlcmUgaXMgbm8gcmVsYXRpb24gYmV0 d2VlbiB0aGlzIGFwcGxpY2F0aW9uLWxldmVsIGdyb3VwIElEIGFuZCB0aGUgT1NDT1JFIEdpZCBk ZWZpbmVkIGluIHRoaXMgZHJhZnQuIEhvd2V2ZXIsIG9uZSBtYXkgcG9zc2libHkgbWFwIG11bHRp cGxlIOKAnGFwcGxpY2F0aW9uIGdyb3Vwc+KAnSB0byB0aGUgc2FtZSDigJxzZWN1cml0eSBncm91 cOKAnS4NCg0KW01UXSBJbiBvcmRlciB0byBjbGFyaWZ5IHRoaXMgcG9pbnQsIHdlIGluY2x1ZGVk IGFsc28gYSBkZWZpbml0aW9uIG9mIOKAnEdyb3Vw4oCdIGFuZCDigJxHcm91cCBJROKAnSBpbiBT ZWN0aW9uIDEuMS4NCg0KDQrCtyAgICAgICAgIFRoZXJlIGlzIG5vcm1hdGl2ZSB0ZXh0IGluIHRo ZSBBcHBlbmRpY2VzOyBpdCBjb3VsZCBiZSBjbGFyaWZpZWQgd2hhdCB0aGUgc3RhdHVzIG9mIHRo aXMgaXMuIEUuZy4gb25seSBub3JtYXRpdmUgaWYgb25lIGNob29zZXMgdG8gaW1wbGVtZW50IHRo ZSBvcHRpb25hbCBlbGVtZW50IGRlc2NyaWJlZCBpbiB0aGUgQXBwZW5kaXg/SSBoYXZlIGEgcHJl ZmVyZW5jZSBmb3IgYXZvaWRpbmcgbm9ybWF0aXZlIHRleHQgaW4gdGhlIEFwcGVuZGljZXMsIGJ1 dCBJ4oCZbSBjdXJpb3VzIHRvIGhlYXIgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCltNVF0gV2UgcmVs YXhlZCB0aGUgdGV4dCBpbiBBcHBlbmRpY2VzIHRvIGF2b2lkIG5vcm1hdGl2ZSByZWZlcmVuY2Vz LCB3aXRoIHRoZSBleGNlcHRpb24gb2YgYSDigJxOT1QgUkVDT01NRU5ERUTigJ0gaW4gY3VycmVu dCBBcHBlbmRpeCBGIOKAnE5vIFZlcmlmaWNhdGlvbiBvZiBTaWduYXR1cmVz4oCdLg0KDQoNCg0K wrcgICAgICAgICBUaGUgdGV4dCBzb21ldGltZXMgc3VnZ2VzdHMgdGhhdCBhIHNlY3VyZSBncm91 cCBjb250ZXh0IGlzIGxpbmtlZCB0byBvbmUgYW5kIG9ubHkgb25lIG11bHRpY2FzdCBJUCBhZGRy ZXNzLiBJbiBwcmFjdGljZSwgdGhlcmUgbWF5IGJlIG1vcmUgdmFyaWV0eSDigJMgZS5nLiBvbmUg bXVsdGljYXN0IElQIGFkZHJlc3MgcGx1cyBvbmUgb3IgbW9yZSB1bmljYXN0IElQIGFkZHJlc3Nl cyB0byB3aGljaCB0aGUgZ3JvdXAgbWVzc2FnZSBpcyBzdWJzZXF1ZW50bHkgZGVsaXZlcmVkLiBF LmcuIHJlcGVhdCBvZiB0aGUgZ3JvdXAgbWVzc2FnZSB0byBtZW1iZXJzIHdoaWNoIGRpZCBub3Qg Z2V0IGl0IHlldC4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGNvdWxkIGJlIHJldmlld2VkIHdpdGgg dGhhdCB2aWV3IGluIG1pbmQsIHRoYXQgdGhlcmUgbWF5IGJlIG11bHRpcGxlIChtdWx0aWNhc3Qv dW5pY2FzdCkgSVAgZGVzdGluYXRpb24gYWRkcmVzc2VzIHRvIHdoaWNoIGEgZ3JvdXAgbWVzc2Fn ZSB3aWxsIGJlIHNlbnQuIEkgZGlkIG5vdCBkbyB0aGF0IHlldDsgY2FuIGRvIHNvIGluIGEgZnV0 dXJlIGluLWRlcHRoIHJldmlldy4NCg0KDQpbTVRdIFRoYW5rcywgdGhhdOKAmXMgYSB2ZXJ5IGdv b2QgY29tbWVudC4gV2XigJlsbCB0aGluayBtb3JlIG9uIHRoZSBwb3NzaWJsZSB2aWV3IHlvdSBw cm9wb3NlLiBJdCBzaG91bGQgYmUgZmluZSBhcyBsb25nIGFzIGEgcmVjaXBpZW50IGlzIGFibGUg dG8gcmV0cmlldmUgdGhlIHJpZ2h0IGdyb3VwIFNlY3VyaXR5IENvbnRleHQsIGJ5IHVzaW5nIHRo ZSBHaWQuDQoNCg0KDQoNClNlY3Rpb24gMi4xDQpTb21lIHRoaW5ncyBoZXJlIGFyZSBsaXN0ZWQg YXMgb3V0IG9mIHNjb3BlLCBidXQgdGhleSBkbyBjb21lIGJhY2sgbGF0ZXIgaW4gdGhlIGRvYyDi gJMgc3VjaCBhcyBmb3J3YXJkIHNlY3VyaXR5IGFuZCBiYWNrd2FyZCBzZWN1cml0eSAsIHdoaWNo IGFyZSBhZGRyZXNzZWQgSSB0aGluayDigJMgY2VydGFpbmx5IG5vdCBvdXQgb2Ygc2NvcGUuDQoN Cg0KW01UXSBHcm91cCBPU0NPUkUgZG9lcyBub3QgZW5zdXJlIGZvcndhcmQgc2VjdXJpdHkgYW5k IGJhY2t3YXJkIHNlY3VyaXR5IGl0c2VsZi4gSW5zdGVhZCwgdGhleSBhcmUgZW50cnVzdGVkIHRv IHRoZSBzcGVjaWZ5aW5nIGdyb3VwIHJla2V5aW5nIHByb3RvY29sIGVuZm9yY2VkIGJ5IHRoZSBH cm91cCBNYW5hZ2VyLiBUaGUgc3BlY2lmaWMgcmVrZXlpbmcgcHJvdG9jb2wgaWYgb3V0IG9mIHNj b3BlIGZvciBHcm91cCBPU0NPUkUsIHdoaWNoIGhvd2V2ZXIgcmVjb21tZW5kcyB0aGUgdXNlIG9m IG9uZSBhYmxlIHRvIGVuc3VyZSBiYWNrd2FyZCBhbmQgZm9yd2FyZCBzZWN1cml0eSBpbiB0aGUg Z3JvdXAuDQoNCg0KDQoNClNlY3Rpb24gMw0KIiBHaWQgTVVTVCBiZSByYW5kb20gIiAtPiBzZWVt cyB0byBjb250cmFkaWN0IEFwcGVuZGl4IEIgd2hpY2ggdXNlcyBhbiBFcG9jaCBjb3VudGVyIGlu IHRoZSBHaWQuICBTaG91bGQgaXQgc2F5IOKAnE1VU1QgaGF2ZSBhIHJhbmRvbSBjb21wb25lbnTi gJ0gPw0KDQoNCltNVF0gUmlnaHQsIG5vdyBmaXhlZCAoaW4gY3VycmVudCBBcHBlbmRpeCBDKS4N Cg0KDQoNCg0KQXBwZW5kaWNlcw0KDQogICogICBBcHBlbmRpeCBCLCBhIGNvbmNyZXRlIGV4YW1w bGUgaW5zdGFuY2UgaXMgbWlzc2luZy4gRS5nLiDigJx3M2ZqOTBmMGFfMDA0MuKAnSBvciBpdHMg YnN0ciBlcXVpdmFsZW50ICAoanVzdCBndWVzc2luZyBoZXJlIHRvIHRoZSBmb3JtYXQpDQoNCg0K W01UXSBXZSBhZGRlZCBhbiBleGFtcGxlLCBpbiBjdXJyZW50IEFwcGVuZGl4IEMuDQoNCg0KDQoN CiAgKg0KICAqICAgQXBwZW5kaXggQywgaXMgdGhpcyBhbiBleGFtcGxlIGJsdWVwcmludCBvZiBo b3cgdG8gZG8gaXQg4oCTIGZ1bGx5IG9wdGlvbmFsIHRvIGZvbGxvdyBvciBub3QgZm9sbG93IHRo aXM/DQoNCg0KW01UXSBXZSByZWxheGVkIHRoZSB0ZXh0IGluIGN1cnJlbnQgQXBwZW5kaXggRCwg YXMgZm9yIHRoZSB0aW1lIGJlaW5nIGl0IGlzIGludGVuZGVkIHRvIGJlIGEgZ3VpZGVsaW5lIGV4 YW1wbGUuDQoNCg0KDQoNCiAgKg0KDQpNaW5vcg0KDQogICogICBsaWd0aGluZyAtPiBsaWdodGlu Zw0KICAqICAgZW5wb2ludCAgLT4gZW5kcG9pbnQNCiAgKiAgIFBnIDI1ICwgW0ktRC5pZXRmLWFj ZS1kdGxzLWF1dGhvcml6ZV0gcmVmZXJlbmNlIGJyZWFrcyBhY3Jvc3MgbGluZSBhbmQgYXMgc3Vj aCBiZWNvbWVzIG5vbi1zZWFyY2hhYmxlIGluIHRoZSBicm93c2VyLiBBbmQgSSBsaWtlIHRoZXNl IHJlZnMgdG8gYmUgc2VhcmNoYWJsZSDwn5iJDQoNCg0KDQoNCg0KRnJvbTogY29yZSBbbWFpbHRv OmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphaW1lIEppbcOpbmV6DQpTZW50 OiBUaHVyc2RheSwgTm92ZW1iZXIgMjMsIDIwMTcgMTc6NTkNClRvOiBjb3JlQGlldGYub3JnPG1h aWx0bzpjb3JlQGlldGYub3JnPiBXRyAoY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9y Zz4pIDxjb3JlQGlldGYub3JnPjxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCkNjOiBqaS15ZS5wYXJr QHVuaS1kdWUuZGU8bWFpbHRvOmppLXllLnBhcmtAdW5pLWR1ZS5kZT4NClN1YmplY3Q6IFtjb3Jl XSDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2Fz dC1vc2NvYXANCg0KRGVhciBhbGwsDQoNClRoZSBkcmFmdCBvbiAiU2VjdXJlIGdyb3VwIGNvbW11 bmljYXRpb24gZm9yIENvQVAiICggZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcDxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9z Y29hcC8+ICkgaGFkIGluIHJvb20gY29uc2Vuc3VzIGZvciBhZG9wdGlvbiBkdXJpbmcgSUVURjk5 IGFscmVhZHksIG5vdyB3ZSBhcmUgY2xlYXIgdG8gY29uZmlybSBpdCBvbiB0aGUgbWFpbGluZyBs aXN0Lg0KDQpQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNs dWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQgdG8gd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQg YWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVu dC4NCg0KVGFyZ2V0IHRvIGVuZCB0aGUgV0dBIGlzIDE0dGggb2YgRGVjZW1iZXIuDQoNCkNpYW8s DQotIC0gSmFpbWUgSmltw6luZXoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGVtYWlsIG1heSBiZSBjb25maWRl bnRpYWwgYW5kL29yIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUg bWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9m IHRoaXMgZW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3Jp Z2luYWwgZW1haWwuDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KY29yZSBtYWlsaW5nIGxpc3QNCg0KY29yZUBpZXRmLm9yZzxtYWls dG86Y29yZUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlDQoNCg0KDQoNCi0tDQoNCk1hcmNvIFRpbG9jYSwgUGhEDQoNClJlc2VhcmNoIEluc3Rp dHV0ZXMgb2YgU3dlZGVuDQoNClJJU0UgSUNUL1NJQ1MNCg0KSXNhZmpvcmRzZ2F0YW4gMjIgLyBL aXN0YWfDpW5nZW4gMTYNCg0KU0UtMTY0IDQwIEtpc3RhIChTd2VkZW4pDQoNClBob25lOiArNDYg KDApNzAgNjAgNDYgNTAxDQoNCmh0dHBzOi8vd3d3LnNpY3Muc2UNCg0KDQoNClRoZSBSSVNFIGlu c3RpdHV0ZXMgSW5udmVudGlhLCBTUCBhbmQgU3dlZGlzaCBJQ1QNCg0KaGF2ZSBtZXJnZWQgaW4g b3JkZXIgdG8gYmVjb21lIGEgc3Ryb25nZXIgcmVzZWFyY2gNCg0KYW5kIGlubm92YXRpb24gcGFy dG5lciBmb3IgYnVzaW5lc3NlcyBhbmQgc29jaWV0eS4NCg0KDQoNClNJQ1MgU3dlZGlzaCBJQ1Qg QUIsIGhhcyBub3cgY2hhbmdlZCBuYW1lIHRvIFJJU0UgU0lDUyBBQi4NCg== --_000_VI1P121MB0014D688CCED02667AA3E38B9BD40VI1P121MB0014EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMjAlOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJbGluZS1oZWlnaHQ6MTIwJTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ4ODQ0NjE5NDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTk0NDg5MjkwNjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjk5ODk2 NjI3MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzI2NjY1NjI0O30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDINCgl7bXNvLWxpc3QtaWQ6MTI1MTIzODk5ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQ0 MDIxMjkwNDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE0OTI5ODQ1NzE7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTM3NDc5MjM0 IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjE5NzMyOTE1MzA7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDc1OTQ1NTM2O30NCkBsaXN0IGw0OmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7 bXNvLWxpc3QtaWQ6MjA0NzIyMDg4MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5NzkyODAy NDQ7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoYW5rcywgdGhhdCBpcyBjbGVh ciBub3cuIFNvIHJlcGhyYXNpbmcgdGhlIHRlcm0g4oCcbmVnbGlnaWJsZSBwcm9iYWJpbGl0eeKA nSBpbiBTZWN0aW9uIDIgYW5kIEFwcGVuZGl4IEMgY291bGQgaGVscCBpbiB0aGlzIHJlc3BlY3Qu IEhvdyBzbWFsbCB0aGlzIHByb2JhYmlsaXR5IHNob3VsZCBiZSBpcyB1cCB0byB0aGUgc3lzdGVt IGRlc2lnbmVyIGluIHRoaXMNCiBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+RXNrbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEfDtnJhbiBTZWxhbmRlciAmbHQ7Z29yYW4u c2VsYW5kZXJAZXJpY3Nzb24uY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1h cmNoIDEzLCAyMDE4IDEwOjQ3PGJyPg0KPGI+VG86PC9iPiBFc2tvIERpamsgJmx0O2Vza28uZGlq a0BwaGlsaXBzLmNvbSZndDs7IGNvcmVAaWV0Zi5vcmcgV0cgKGNvcmVAaWV0Zi5vcmcpICZsdDtj b3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFyY28gVGlsb2NhICZsdDttYXJjby50 aWxvY2FAcmkuc2UmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPiYjMTI4Mjc2Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+IFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXRpbG9jYS1jb3JlLW11 bHRpY2FzdC1vc2NvYXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPkhpIEVza28sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0Ij5UaGFua3MgZm9yIGdvb2QgY29tbWVudHMhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5MZXTi gJlzIHJlY2FwIHRoZSBzZXR0aW5nOiZuYnNwO1RoZSBzZW5kZXIgYW5kIHJlY2lwaWVudCBvZiBh IGdyb3VwIE9TQ09SRSBtZXNzYWdlIG5lZWRzIHRvIHJldHJpZXZlL2Rlcml2ZSB0aGUgcmlnaHQg c2VjdXJpdHkgY29udGV4dCBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5nIHJlcXVlc3RzIGFuZCBy ZXNwb25zZXMsIGFuZCB0aGUgYW1vdW50IG9mIGRhdGEgc2VudA0KIGZvciB0aGlzIHB1cnBvc2Ug c2hvdWxkIGJlIGFzIHNtYWxsIGFzIHBvc3NpYmxlLiZuYnNwO1RoaXMgc2hvdWxkIGFwcGx5IHRv IGFsbCBwaGFzZXMgb2YgY29tbXVuaWNhdGlvbjsgZmlyc3QgdGltZSwgbm9ybWFsIG9wZXJhdGlv biwgYWZ0ZXIgbWVtYmVyIGhhcyBiZWVuIGV4Y2x1ZGVkLCBldGMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0O21pbi1oZWlnaHQ6IDE0cHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj5UaGUgT1NDT1JFIG1lc3NhZ2UgZm9ybWF0IGluY2x1ZGVzIHRoZSAna2lk JyBhbmQgdGhlICdraWQgY29udGV4dCcuIEZvciB0aGUgZ3JvdXAgc2V0dGluZzo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4qIHRoZSBraWQgY29u dGFpbnMgdGhlIElEIG9mIHRoZSBzZW5kaW5nIGdyb3VwIG1lbWJlciAoU2VuZGVyIElEKSwgdW5p cXVlIGluIHRoZSBncm91cCwgYXNzaWduZWQgYnkgdGhlIGdyb3VwIG1hbmFnZXIgKHdoaWNoJm5i c3A7Y291bGQgYmUganVzdCBhIHNob3J0IGJ5dGUgc3RyaW5nKS4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4qIFRoZSZuYnNwO2tpZCBj b250ZXh0IGNvbnRhaW5zIHRoZSBncm91cCBpZGVudGlmaWVyLCBhbHNvIGFzc2lnbmVkIGJ5IHRo ZSBncm91cCBtYW5hZ2VyIGFuZCB1bmlxdWUgZm9yIHRoaXMgZ3JvdXAgbWFuYWdlci4gVGhlIGtp ZCBjb250ZXh0IGlzIGEgJnF1b3Q7Y29udGV4dCBoaW504oCdIGhlbHBpbmcgdGhlIHJlY2lwaWVu dA0KIGVuZHBvaW50Jm5ic3A7ZmluZCB0aGUgc2VjdXJpdHkgY29udGV4dC4mbmJzcDs8L3NwYW4+ SWYgZW5kcG9pbnRzIGFyZSBkZXBsb3llZCB3aXRoIG11bHRpcGxlIHVuY29vcmRpbmF0ZWQgZ3Jv dXAgbWFuYWdlcnMgdGhlbiB0aGV5IG5lZWQgdG8gYmUgYWJsZSB0byBoYW5kbGUgY29pbmNpZGlu ZyBncm91cCBpZGVudGlmaWVycywgZS5nLiBieSB0cnlpbmcgbXVsdGlwbGUgc2VjdXJpdHkgY29u dGV4dHMgdG8gc2VlIGlmJm5ic3A7aWYgYW55IHZlcmlmaWVzLiBBcyBsb25nIGFzDQogdGhlIE1h c3RlciBTZWNyZXQgaXMgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgZ3JvdXBzIChhbmQgZGlmZmVy ZW50IGVwb2NocyBvZiBhIGdyb3VwKSBhbmQgdGhlIFNlbmRlciBJRHMgd2l0aGluIHRoZSBncm91 cCBhcmUgdW5pcXVlLCB0aGF0IGlzIHN1ZmZpY2llbnQgdG8gbWFrZSBBRUFEIGtleSBhbmQgbm9u Y2UgZGlmZmVyZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0O21pbi1oZWlnaHQ6IDE0cHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj5TbyB0aGVyZSBpcyBubyBuZWVkIGZvciBuZWdsaWdhYmxl IHByb2JhYmlsdHkgb2YgY29pbmNpZGluZyBncm91cCBpZGVudGlmaWVycyBhcyBsb25nIGFzIHRo ZSByZWNpcGllbnQgY2FuIGZpbmQgaXRzIHdheSB0byB0aGUgcmlnaHQgc2VjdXJpdHkgY29udGV4 dC4mbmJzcDtCdXQgaW4gdGhlIGNhc2Ugb2YNCiBhbiBlbmRwb2ludCBiZWluZyBpbiBtdWx0aXBs ZSBncm91cHMgbWFuYWdlZCBieSBkaWZmZXJlbnQgZ3JvdXAgbWFuYWdlcnMsIGl0IGlzIG9mJm5i c3A7Y291cnNlJm5ic3A7ZmF2b3VyYWJsZSBpZiB0aGUgZ3JvdXAgaWRlbnRpZmllcnMgYXJlIGRp ZmZlcmVudC4gU28gd2Ugc2hvdWxkIHJlcGhyYXNlIHRoaXMgYWNjb3JkaW5nbHkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+RnVydGhlciBj b21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTogPC9iPmNvcmUgJmx0OzxhIGhyZWY9Im1haWx0 bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPmNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9u IGJlaGFsZiBvZiBFc2tvIERpamsgJmx0OzxhIGhyZWY9Im1haWx0bzplc2tvLmRpamtAcGhpbGlw cy5jb20iPmVza28uZGlqa0BwaGlsaXBzLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldl ZG5lc2RheSA3IE1hcmNoIDIwMTggYXQgMDk6Mjk8YnI+DQo8Yj5UbzogPC9iPk1hcmNvIFRpbG9j YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmNvLnRpbG9jYUByaS5zZSI+bWFyY28udGlsb2NhQHJp LnNlPC9hPiZndDssIEphaW1lIEppbcOpbmV6ICZsdDs8YSBocmVmPSJtYWlsdG86amFpbWUuamlt ZW5lekBlcmljc3Nvbi5jb20iPmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPC9hPiZndDssICZx dW90OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiBXRyAo PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+KSZxdW90Ow0K ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbY29yZV0gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPg0KJiMxMjgyNzY7PC9zcGFu PiBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Nj b2FwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMu NzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij5UaGFua3MgTWFyY28sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij5UaGlzIHVwZGF0ZSBzb2x2ZXMgdGhlIGlzc3VlcyBJIHRoaW5rIGFu ZCBhbnN3ZXJzIG15IHF1ZXN0aW9ucywgZXhjZXB0IGZvciB0aGUgcmFuZG9tbmVzcyBpbiB0aGUg R2lkOiAmbmJzcDvigJxBIEdpZCBNVVNUIGhhdmUgYSByYW5kb20gY29tcG9uZW50IGFuZCBiZSBs b25nIGVub3VnaCwgaW4gb3JkZXIgdG8gYWNoaWV2ZSBhIG5lZ2xpZ2libGUgcHJvYmFiaWxpdHkg b2YNCiBjb2xsaXNpb25zIGJldHdlZW4gR3JvdXAgSWRlbnRpZmllcnMgZnJvbSBkaWZmZXJlbnQg R3JvdXAgTWFuYWdlcnPigJ07IGFuZCBBcHBlbmRpeCBDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+VGhlIGV4YW1wbGUgQXBwZW5kaXggQyB1c2VzIGEgc2luZ2xl IHJhbmRvbSBieXRlLiZuYnNwOyBNb3N0IHBlb3BsZSB3b3VsZCB0aGluayB0aGUgY29sbGlzaW9u IHByb2JhYmlsaXR5IGlzIHF1aXRlIGhpZ2ggaW4gdGhpcyBjYXNlOyBzbyBob3cgY2FuIHRoaXMg Y2hvaWNlIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50PyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0Ij5TZWUgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+TWF5YmUg aW4gdGhpcyBleGFtcGxlIHRoZSBHcm91cCBNYW5hZ2VycyBwaWNrIGEgcmFuZG9tIHZhbHVlIGFu ZCB0aGVuIG11dHVhbGx5IHZlcmlmeSB0aGF0IHRoZXJlIGFyZSBubyBjb2xsaXNzaW9ucz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQiPlllcywgaWYgdGhlcmUgaXMgY29vcmRpbmF0aW9uIGJldHdlZW4gZ3JvdXAgbWFuYWdlcnMs IGJ1dCB0aGlzIGlzIG5vdCBuZWNlc3NhcnkgZm9yIHRoZSBzY2hlbWUgdG8gd29yayBhcyBub3Rl ZCBhYm92ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21h cmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5UaGUgbmFtZSDigJxHcm91cCBFcG9jaOKAnSBj b3VsZCBiZSBzbGlnaHRseSBjb25mdXNpbmcgaGVyZSDigJMgQXBwZW5kaXggQyBzdGF0ZXMgdGhl IGVwb2NoIGFwcGxpZXMgdG8gYSBzaW5nbGUgZ3JvdXAuIEhvd2V2ZXIgdGhlIGV4YW1wbGUgdGhl cmUgc2hvd3MgdGhlIGVwb2NoIGFwcGxpZXMgdG8gYWxsIGdyb3VwcyBmcm9tIHRoZSBzYW1lIEdy b3VwIE1hbmFnZXIsDQogb3IgaW4gb3RoZXIgd29yZHMgdGhlIGVwb2NoICo8Yj5pczwvYj4qIHRo ZSBncm91cC4gKEJlY2F1c2UgdGhlcmUgaXMgbm8gdGhpbmcgbGlrZSDigJxHcm91cCBJROKAnSBp biB0aGUgZXhhbXBsZSwgb25seSBHTSByYW5kb20gYnl0ZSBhbmQgR3JvdXAgRXBvY2ggYnl0ZXMu KSZuYnNwOyBXYXMgaXQgaW50ZW5kZWQgdG8gYWRkIGEgYnl0ZSBvciBzbyBmb3Ig4oCcR3JvdXAg SUTigJ0gPyBTbyB0aGF0IGVhY2ggZ3JvdXAgY2FuIGhhdmUgaXRzIG93biBlcG9jaCBjb3VudGVy Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+VGhlIGludGVudCB3YXMgdGhhdCB0aGUgR3JvdXAgSUQgY29uc2lzdHMgb2YgYSBH cm91cCBQcmVmaXggYW5kIGEgR3JvdXAgRXBvY2guJm5ic3A7VGhlIG5lZWQgZm9yIGEgZ3JvdXAg cHJlZml4IGlzIHRvIGFsbG93IGEgY29uc3RhbnQgaWRlbnRpZmllciBvZiB0aGUgZ3JvdXAuIFRo ZSBuZWVkIGZvciBncm91cCBlcG9jaCBpcyB0byBhbGxvdyBlbmRwb2ludHMgdG8NCiBmaW5kIHRo ZSByaWdodCBNYXN0ZXIgS2V5cyB1c2VkIGluIHRoZSBncm91cCBhdCBhIGNlcnRhaW4gdGltZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPiZuYnNwO0dyb3VwIGlkZW50aWZpZXJzIG1heSBiZSBjb25zdHJ1Y3Rl ZCBpbiBvdGhlciB3YXlzIHRoYXQgbWFrZXMgdGhlIHJlY2lwaWVudCBmaW5kIHRoZSByaWdodCBz ZWN1cml0eSBjb250ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SG9wZSB0aGF0IGhlbHBzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5Hw7ZyYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJp Z2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+RXNrbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij4gTWFyY28gVGlsb2NhICZsdDs8YSBocmVmPSJtYWlsdG86bWFyY28udGls b2NhQHJpLnNlIj5tYXJjby50aWxvY2FAcmkuc2U8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgTWFyY2ggNSwgMjAxOCAyMzoxODxicj4NCjxiPlRvOjwvYj4gRXNrbyBEaWprICZs dDs8YSBocmVmPSJtYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tIj5lc2tvLmRpamtAcGhpbGlw cy5jb208L2E+Jmd0OzsgSmFpbWUgSmltw6luZXogJmx0OzxhIGhyZWY9Im1haWx0bzpqYWltZS5q aW1lbmV6QGVyaWNzc29uLmNvbSI+amFpbWUuamltZW5lekBlcmljc3Nvbi5jb208L2E+Jmd0OzsN CjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiBXRyAoPGEg aHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW2NvcmVdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mIzEy ODI3Njs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBXRyBDYWxsIGZvciBB ZG9wdGlvbiBvbiBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij5IZWxsbyBFc2tv LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPlRoYW5r cyBmb3IgeW91ciBzdXBwb3J0IGFuZCBjb21tZW50cywgd2UgaGF2ZSBjb25zaWRlcmVkIHRoZW0g d2hlbiBwcm9kdWNpbmcgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSZuYnNwOyBkcmFmdCBbMV0u PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+UGxlYXNl LCBmaW5kIGluIGxpbmUgc29tZSBhbnN3ZXJzIHRvIHlvdXIgY29tbWVudHMuPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+QmVzdCw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij4vTWFyY288bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij5bMV0gPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vc2NvcmUtZ3JvdXBjb21tLTAx Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9zY29yZS1ncm91 cGNvbW0tMDE8L2E+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIwMTctMTIt MDQgMTQ6MzUsIEVza28gRGlqayB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFm dCBhcyBhIHdvcmsgaXRlbSBmb3IgQ29SRS4gQmVsb3cgYXJlIHRoZSByZXN1bHRzIG9mIGEgcXVp Y2sgcmV2aWV3LCBhbHNvLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXNrbyBEaWprPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T3ZlcmFsbCBjb21tZW50cyDigJMgb3Igd29yayB0aGF0IHRoZSBXRyBjb3VsZCB0YWtlIHVwIG5l eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoyNy4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omw0IGxldmVsMSBsZm8yO3ZlcnRp Y2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5EZXRhaWxlZCBleGFtcGxlIHdpdGggbWVzc2Fn ZSBzaXplcyB3b3VsZCBiZSB1c2VmdWwuIFNpbmNlIGl04oCZcyBpbXBvcnRhbnQgZm9yIG11bHRp Y2FzdCBvdmVyIDZsb3dwYW4gcGVyZm9ybWFuY2UgdGhhdCB0aGUgSVB2NiBwYWNrZXRzIHN0YXkg c21hbGwgZW5vdWdoIChvbmUgODAyLjE1LjQgZnJhbWUpLiBBdCB0aGlzIG1vbWVudCwgSSBjYW7i gJl0IGp1ZGdlIHRoYXQgeWV0IGVhc2lseSBiYXNlZA0KIG9uIHRoZSBkcmFmdC48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNVF0gV2UgaGF2ZSBub3cgaW5jbHVk ZWQgZGV0YWlsZWQgZXhhbXBsZXMgaW4gU2VjdGlvbnMgMy4xIChSZXF1ZXN0KSBhbmQgU2VjdGlv biAzLjIgKFJlc3BvbnNlKS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNCBs ZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Tm9ybWFsbHksIGZv ciBhcHBsaWNhdGlvbnMgKGUuZy4gQnVpbGRpbmcgYXV0b21hdGlvbiBhbmQgbGlnaHRpbmcpIGdy b3VwcyBkbyBuZWVkIGEgc3RhYmxlIGFuZCBub24tcmFuZG9tIGdyb3VwIElELCB0aGF0IGlkZW50 aWZpZXMgdGhlIGdyb3VwIG92ZXIgdGltZSBldmVuIGFzIGNoYW5nZXMgb2NjdXIsIGUuZy4gbWVt YmVycyBhZGRlZC9yZW1vdmVkLiBUaGUg4oCcR2lk4oCdIGluIHRoZSBkcmFmdA0KIGhvd2V2ZXIg Y2hhbmdlcy4gVGhlcmUgY291bGQgYmUgc29tZSB0ZXh0IGFkZGVkIHRvIGV4cGxhaW4gaG93IEdp ZCBpcyBsaW5rZWQgdG8gYSBzdGFibGUgSUQuIEUuZy4sIHRoaXMgY291bGQgYmUgY29uZmlndXJl ZCBieSB0aGUgR3JvdXAgTWFuYWdlci4gVGhlIHN0YWJsZSBncm91cCBJRCBpcyB0aGVuIG5vdCB1 c2VkIG92ZXItdGhlLXdpcmUgZm9yIG11bHRpY2FzdCBPU0NPUkUuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTVRdIEl0IGlzIHRydWUgdGhhdCB0aGUgR2lkIGlu IHRoaXMgZHJhZnQgY2hhbmdlcyBvdmVyIHRpbWUsIGVzcGVjaWFsbHkgdXBvbiByZW5ld2luZyB0 aGUgZ3JvdXAga2V5aW5nIG1hdGVyaWFsLCBhbmQgdGhlIEdyb3VwIE1hbmFnZXIgaXMgdGhlIG9u bHkgcmVzcG9uc2libGUgZm9yIG1hbmFnaW5nIGl0cyB2YWx1ZSB1cGRhdGUuDQogSG93ZXZlciwg dGhpcyBHaWQgaGFzIHRvIGJlIGludGVuZGVkIGFzIHRoZSBpZGVudGlmaWVyIG9mIHRoZSBPU0NP UkUg4oCcc2VjdXJpdHkgZ3JvdXDigJ0sIGluY2x1ZGluZyBhcyBtZW1iZXJzIHRoZSBlbmRwb2lu dHMgdGhhdCBzaGFyZSB0aGUgc2FtZSBDb21tb24gU2VjdXJpdHkgQ29udGV4dC48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTVRdIEFzIHlvdSBzYXksIGFwcGxpY2F0 aW9ucyBkbyByZWx5IG9uIGEgc3RhYmxlIGFuZCBub24tcmFuZG9tIGdyb3VwIElELCB3aGljaCBp cyBub3QgdXNlZCBvdmVyLXRoZS13aXJlIGZvciBncm91cCBPU0NPUkUsIGFuZCBpbnN0ZWFkIGlk ZW50aWZpZXMgYW4g4oCcYXBwbGljYXRpb24gZ3JvdXDigJ0gaGF2aW5nIGFzIG1lbWJlcnMNCiB0 aGUgZW5kcG9pbnRzIHRoYXQgcGFydGljaXBhdGUgaW4gYSBzYW1lIGdyb3VwIGFwcGxpY2F0aW9u LiBUaGVyZSBpcyBubyByZWxhdGlvbiBiZXR3ZWVuIHRoaXMgYXBwbGljYXRpb24tbGV2ZWwgZ3Jv dXAgSUQgYW5kIHRoZSBPU0NPUkUgR2lkIGRlZmluZWQgaW4gdGhpcyBkcmFmdC4gSG93ZXZlciwg b25lIG1heSBwb3NzaWJseSBtYXAgbXVsdGlwbGUg4oCcYXBwbGljYXRpb24gZ3JvdXBz4oCdIHRv IHRoZSBzYW1lIOKAnHNlY3VyaXR5IGdyb3Vw4oCdLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPltNVF0gSW4gb3JkZXIgdG8gY2xhcmlmeSB0aGlzIHBvaW50LCB3ZSBp bmNsdWRlZCBhbHNvIGEgZGVmaW5pdGlvbiBvZiDigJxHcm91cOKAnSBhbmQg4oCcR3JvdXAgSUTi gJ0gaW4gU2VjdGlvbiAxLjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+VGhlcmUgaXMgbm9ybWF0aXZlIHRleHQgaW4gdGhlIEFwcGVuZGljZXM7IGl0IGNv dWxkIGJlIGNsYXJpZmllZCB3aGF0IHRoZSBzdGF0dXMgb2YgdGhpcyBpcy4gRS5nLiBvbmx5IG5v cm1hdGl2ZSBpZiBvbmUgY2hvb3NlcyB0byBpbXBsZW1lbnQgdGhlIG9wdGlvbmFsIGVsZW1lbnQg ZGVzY3JpYmVkIGluIHRoZSBBcHBlbmRpeD9JIGhhdmUgYSBwcmVmZXJlbmNlIGZvciBhdm9pZGlu ZyBub3JtYXRpdmUNCiB0ZXh0IGluIHRoZSBBcHBlbmRpY2VzLCBidXQgSeKAmW0gY3VyaW91cyB0 byBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCltNVF0gV2UgcmVsYXhlZCB0aGUg dGV4dCBpbiBBcHBlbmRpY2VzIHRvIGF2b2lkIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCB3aXRoIHRo ZSBleGNlcHRpb24gb2YgYSDigJxOT1QgUkVDT01NRU5ERUTigJ0gaW4gY3VycmVudCBBcHBlbmRp eCBGIOKAnE5vIFZlcmlmaWNhdGlvbiBvZiBTaWduYXR1cmVz4oCdLjwvc3Bhbj48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2 ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSB0ZXh0IHNvbWV0 aW1lcyBzdWdnZXN0cyB0aGF0IGEgc2VjdXJlIGdyb3VwIGNvbnRleHQgaXMgbGlua2VkIHRvIG9u ZSBhbmQgb25seSBvbmUgbXVsdGljYXN0IElQIGFkZHJlc3MuIEluIHByYWN0aWNlLCB0aGVyZSBt YXkgYmUgbW9yZSB2YXJpZXR5IOKAkyBlLmcuIG9uZSBtdWx0aWNhc3QgSVAgYWRkcmVzcyBwbHVz IG9uZSBvciBtb3JlIHVuaWNhc3QgSVAgYWRkcmVzc2VzIHRvIHdoaWNoDQogdGhlIGdyb3VwIG1l c3NhZ2UgaXMgc3Vic2VxdWVudGx5IGRlbGl2ZXJlZC4gRS5nLiByZXBlYXQgb2YgdGhlIGdyb3Vw IG1lc3NhZ2UgdG8gbWVtYmVycyB3aGljaCBkaWQgbm90IGdldCBpdCB5ZXQuIFRoZSBwcm9wb3Nl ZCBzb2x1dGlvbiBjb3VsZCBiZSByZXZpZXdlZCB3aXRoIHRoYXQgdmlldyBpbiBtaW5kLCB0aGF0 IHRoZXJlIG1heSBiZSBtdWx0aXBsZSAobXVsdGljYXN0L3VuaWNhc3QpIElQIGRlc3RpbmF0aW9u IGFkZHJlc3NlcyB0byB3aGljaA0KIGEgZ3JvdXAgbWVzc2FnZSB3aWxsIGJlIHNlbnQuIEkgZGlk IG5vdCBkbyB0aGF0IHlldDsgY2FuIGRvIHNvIGluIGEgZnV0dXJlIGluLWRlcHRoIHJldmlldy48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNVF0gVGhhbmtzLCB0 aGF04oCZcyBhIHZlcnkgZ29vZCBjb21tZW50LiBXZeKAmWxsIHRoaW5rIG1vcmUgb24gdGhlIHBv c3NpYmxlIHZpZXcgeW91IHByb3Bvc2UuIEl0IHNob3VsZCBiZSBmaW5lIGFzIGxvbmcgYXMgYSBy ZWNpcGllbnQgaXMgYWJsZSB0byByZXRyaWV2ZSB0aGUgcmlnaHQgZ3JvdXAgU2VjdXJpdHkgQ29u dGV4dCwNCiBieSB1c2luZyB0aGUgR2lkLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlv biAyLjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgdGhpbmdzIGhl cmUgYXJlIGxpc3RlZCBhcyBvdXQgb2Ygc2NvcGUsIGJ1dCB0aGV5IGRvIGNvbWUgYmFjayBsYXRl ciBpbiB0aGUgZG9jIOKAkyBzdWNoIGFzIGZvcndhcmQgc2VjdXJpdHkgYW5kIGJhY2t3YXJkIHNl Y3VyaXR5ICwgd2hpY2ggYXJlIGFkZHJlc3NlZCBJIHRoaW5rIOKAkyBjZXJ0YWlubHkgbm90IG91 dCBvZiBzY29wZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltN VF0gR3JvdXAgT1NDT1JFIGRvZXMgbm90IGVuc3VyZSBmb3J3YXJkIHNlY3VyaXR5IGFuZCBiYWNr d2FyZCBzZWN1cml0eSBpdHNlbGYuIEluc3RlYWQsIHRoZXkgYXJlIGVudHJ1c3RlZCB0byB0aGUg c3BlY2lmeWluZyBncm91cCByZWtleWluZyBwcm90b2NvbCBlbmZvcmNlZCBieSB0aGUgR3JvdXAg TWFuYWdlci4gVGhlDQogc3BlY2lmaWMgcmVrZXlpbmcgcHJvdG9jb2wgaWYgb3V0IG9mIHNjb3Bl IGZvciBHcm91cCBPU0NPUkUsIHdoaWNoIGhvd2V2ZXIgcmVjb21tZW5kcyB0aGUgdXNlIG9mIG9u ZSBhYmxlIHRvIGVuc3VyZSBiYWNrd2FyZCBhbmQgZm9yd2FyZCBzZWN1cml0eSBpbiB0aGUgZ3Jv dXAuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OyBHaWQgTVVTVCBiZSByYW5kb20gJnF1b3Q7IC0mZ3Q7 IHNlZW1zIHRvIGNvbnRyYWRpY3QgQXBwZW5kaXggQiB3aGljaCB1c2VzIGFuIEVwb2NoIGNvdW50 ZXIgaW4gdGhlIEdpZC4mbmJzcDsgU2hvdWxkIGl0IHNheSDigJxNVVNUIGhhdmUgYSByYW5kb20g Y29tcG9uZW504oCdID88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PltNVF0gUmlnaHQsIG5vdyBmaXhlZCAoaW4gY3VycmVudCBBcHBlbmRpeCBDKS48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFwcGVuZGljZXMgPG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlkZGxlIj5BcHBlbmRpeCBC LCBhIGNvbmNyZXRlIGV4YW1wbGUgaW5zdGFuY2UgaXMgbWlzc2luZy4gRS5nLiDigJx3M2ZqOTBm MGFfMDA0MuKAnSBvciBpdHMgYnN0ciBlcXVpdmFsZW50Jm5ic3A7IChqdXN0IGd1ZXNzaW5nIGhl cmUgdG8gdGhlIGZvcm1hdCk8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPltNVF0gV2UgYWRkZWQgYW4gZXhhbXBsZSwgaW4gY3VycmVudCBBcHBlbmRpeCBD Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsNCBsZXZlbDEgbGZvMjt2 ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVsMSBsZm8yO3ZlcnRpY2FsLWFsaWduOm1p ZGRsZSI+QXBwZW5kaXggQywgaXMgdGhpcyBhbiBleGFtcGxlIGJsdWVwcmludCBvZiBob3cgdG8g ZG8gaXQg4oCTIGZ1bGx5IG9wdGlvbmFsIHRvIGZvbGxvdyBvciBub3QgZm9sbG93IHRoaXM/PG86 cD48L286cD48L2xpPjwvdWw+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTVRdIFdlIHJl bGF4ZWQgdGhlIHRleHQgaW4gY3VycmVudCBBcHBlbmRpeCBELCBhcyBmb3IgdGhlIHRpbWUgYmVp bmcgaXQgaXMgaW50ZW5kZWQgdG8gYmUgYSBndWlkZWxpbmUgZXhhbXBsZS48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246 bWlkZGxlIj4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlub3I8bzpwPjwv bzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMyBsZXZlbDEgbGZvOCI+bGlndGhpbmcg LSZndDsgbGlnaHRpbmc8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbGlzdDpsMyBsZXZlbDEgbGZvOCI+ZW5wb2ludCZuYnNwOyAtJmd0OyBlbmRwb2ludDxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwzIGxl dmVsMSBsZm84Ij5QZyAyNSAsIFtJLUQuaWV0Zi1hY2UtZHRscy1hdXRob3JpemVdIHJlZmVyZW5j ZSBicmVha3MgYWNyb3NzIGxpbmUgYW5kIGFzIHN1Y2ggYmVjb21lcyBub24tc2VhcmNoYWJsZSBp biB0aGUgYnJvd3Nlci4gQW5kIEkgbGlrZSB0aGVzZSByZWZzIHRvIGJlIHNlYXJjaGFibGUNCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNl cmlmIj4mIzEyODUyMTs8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoyNy4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBjb3JlIFs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+SmFpbWUgSmltw6luZXo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDIz LCAyMDE3IDE3OjU5PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4gV0cgKDxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5j b3JlQGlldGYub3JnPC9hPikNCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj4mbHQ7Y29y ZUBpZXRmLm9yZyZndDs8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86amkteWUu cGFya0B1bmktZHVlLmRlIj5qaS15ZS5wYXJrQHVuaS1kdWUuZGU8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFtjb3JlXSA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1v amkmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjgyNzY7PC9zcGFuPiBXRyBDYWxsIGZvciBBZG9wdGlv biBvbiBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgb24gJnF1b3Q7U2VjdXJlIGdyb3VwIGNv bW11bmljYXRpb24gZm9yIENvQVAmcXVvdDsgKCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLyI+ZHJhZnQt dGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcDwvYT4mbmJzcDspIGhhZCBpbiByb29tIGNvbnNl bnN1cyBmb3IgYWRvcHRpb24gZHVyaW5nIElFVEY5OSBhbHJlYWR5LCBub3cgd2UgYXJlDQogY2xl YXIgdG8gY29uZmlybSBpdCBvbiB0aGUgbWFpbGluZyBsaXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHJl cGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5v dCZuYnNwO2xpbWl0ZWQgdG8gd2hldGhlciZuYnNwO29yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlv bi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkmbmJzcDtlbmNvdXJhZ2VkIHRvIGNvbW1lbnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGFyZ2V0IHRvIGVuZCB0aGUgV0dBIGlzIDE0dGggb2YgRGVjZW1iZXIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW8sPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIC0g SmFpbWUgSmltw6luZXo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIy IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5Ij5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZW1haWwgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQvb3IgbGVnYWxseSBwcm90ZWN0ZWQg dW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIGFkZHJlc3NlZShzKS4gSWYgeW91DQogYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3Nl bWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZA0K IGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgZW1haWwuPGJyPg0KPC9zcGFuPjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmNvcmUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv OmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+PG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NYXJjbyBU aWxvY2EsIFBoRDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlc2VhcmNoIEluc3RpdHV0ZXMgb2Yg U3dlZGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+UklTRSBJQ1QvU0lDUzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPklzYWZqb3Jkc2dhdGFuIDIyIC8gS2lzdGFnw6VuZ2VuIDE2PG86cD48L286cD48 L3ByZT4NCjxwcmU+U0UtMTY0IDQwIEtpc3RhIChTd2VkZW4pPG86cD48L286cD48L3ByZT4NCjxw cmU+UGhvbmU6ICYjNDM7NDYgKDApNzAgNjAgNDYgNTAxPG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuc2ljcy5zZSI+aHR0cHM6Ly93d3cuc2ljcy5zZTwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgUklT RSBpbnN0aXR1dGVzIElubnZlbnRpYSwgU1AgYW5kIFN3ZWRpc2ggSUNUPG86cD48L286cD48L3By ZT4NCjxwcmU+aGF2ZSBtZXJnZWQgaW4gb3JkZXIgdG8gYmVjb21lIGEgc3Ryb25nZXIgcmVzZWFy Y2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW5ub3ZhdGlvbiBwYXJ0bmVyIGZvciBidXNp bmVzc2VzIGFuZCBzb2NpZXR5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlNJQ1MgU3dlZGlzaCBJQ1QgQUIsIGhhcyBub3cgY2hhbmdlZCBuYW1l IHRvIFJJU0UgU0lDUyBBQi48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1P121MB0014D688CCED02667AA3E38B9BD40VI1P121MB0014EURP_-- From nobody Mon Mar 19 03:50:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD0E12DA29 for ; Mon, 19 Mar 2018 03:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 EuxmLBTM3Y8U for ; Mon, 19 Mar 2018 03:50:37 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 0820F126FB3 for ; Mon, 19 Mar 2018 03:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521456633; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=V3LzSNO6GsGVCHJDrz2Rgi9nN8Eyoj8caKHZl7GLxTI=; b=PW7oUT9VUrS8m9TPpwUKu1UHJcWs39ggVFPhjWP10mYKLgLw7wuChEw6LLmCuNq6 blxJlI0VSVhbvERnwNsQUdPP2HLoWz8Ry4/skHIGx9vHRQISHwGS+wM4E3NvFfA+ G3KjIBCzcXbtLrs8m7+I3QE39OGL9Ec+MF6JKH6zpZE=; X-AuditID: c1b4fb2d-87c029c000005540-3c-5aaf95f8ac13 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.69.21824.8F59FAA5; Mon, 19 Mar 2018 11:50:33 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 11:50:10 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: JinHyeock Choi CC: Bill Silverajan , "core@ietf.org WG (core@ietf.org)" , "t2trg-chairs@irtf.org" Thread-Topic: [core] Review of draft-silverajan-core-coap-protocol-negotiation Thread-Index: AQHTv3AMpAeSG1xbxk2mfPE1eQABsw== Date: Mon, 19 Mar 2018 10:50:10 +0000 Message-ID: <237126CD-5E63-41CB-A0E9-1F8E9ADF2716@ericsson.com> References: <0cc8bfd6-2f50-83b6-d392-e80de133ce34@tut.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.128.199] Content-Type: multipart/signed; boundary="Apple-Mail=_63050CFB-C35E-4B04-88D4-84005C7675B4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUyM2J7lO7PqeujDI72M1tcPCVrse/temaL p6t2sFrcm3SRyYHFY+esu+weS5b8ZPKYvPEwm8f86SsYA1iiuGxSUnMyy1KL9O0SuDJOLbzD XrAhpmLPcvsGxomhXYycHBICJhIrJr1i7WLk4hASOMwosXTJPyYIZwmjxKul75hAqtgEnCU+ PWtkB7FFBNQkDk+dAmYzC8xklJjakgliCwsESMyYPgGqJlCi+ewSRghbT+L564esIDaLgKrE vytbmUFsXgF7icdblzNDLDvOKNG5/wdYMydQ8/edS1lAbEYBMYnvp9YwQSwTl7j1ZD4TxNki Eg8vnmaDsEUlXj7+xwphK0ls2f+FHWQos8AURollcw+yQ2wTlDg58wnLBEaRWUhmzUJWNwtJ HURRkkTLxiY2CFtbYtnC18wQtqbE/u7lLJjiGhKd3yayQtimEq+PfmSEsK0lZvw6CDVHUWJK 90P2BYzcqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECY/zglt+6OxhXv3Y8xCjAwajEw8s5 cX2UEGtiWXFl7iFGFaA5jzasvsAoxZKXn5eqJML79Mq6KCHelMTKqtSi/Pii0pzU4kOM0hws SuK8Jz15o4QE0hNLUrNTUwtSi2CyTBycUg2M1TcXeKRMX124cKGjnnHol+iJjFW+aWeaGKQ9 Oubzf5n5+Hvr9uw9D+IVH2/du65Er/RA9NmSP7Ez4mbbcab7mGx+dopx9YzSbyo5sZMMNkjm WuY8+v69+hmn143ERTcEAuqnWH1Xe/hIo9zt06+piZ9v39qo8aNjVUPLZun4uvd/tLpXNG2U UGIpzkg01GIuKk4EAL8flb75AgAA Archived-At: Subject: Re: [core] Review of draft-silverajan-core-coap-protocol-negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 10:50:42 -0000 --Apple-Mail=_63050CFB-C35E-4B04-88D4-84005C7675B4 Content-Type: multipart/alternative; boundary="Apple-Mail=_B48E3D4B-B1C6-4342-92ED-0E795EEFD7D9" --Apple-Mail=_B48E3D4B-B1C6-4342-92ED-0E795EEFD7D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi JinHyeock, hi T2TRG chairs, would it be possible for you to share in this thread the remote = participation details of the T2TRG/ OCF/ WoT join meeting? Thanks! - - Jaime Jim=C3=A9nez > On 16 Mar 2018, at 1.03, JinHyeock Choi wrote: >=20 > Bill >=20 >>> ol=3Dhttp://[FDFD::123]:61616, coap://[2001:db8:f1::2]:5683 >>>=20 >>> corresponds to >>>=20 >>> "eps": [ >>> {"ep": "http://[FDFD::123]:61616"}, >>> {"ep": "coaps://[2001:db8:f1::2]:5683"} >>> ] >>>=20 >> That is good. Going forward, the mapping would become easier: We've = defined >> "ol" to be repeatable instead of a comma separated list of base URIs. = For >> example, >> = https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiatio= n-08#section-6.1 >=20 > thanks for the clarification. I mistakenly referred the examples from = v08. >=20 >>> There still exisit some differences >>> (e.g., URI in "ep" shall have IP address in its authority.), >>> which, I hope, we would discuss in joint meeting next FRI. >>>=20 >> If you are participating in IETF 101, we can also arrange a corridor >> discussion around this topic. I'd be interested in hearing your = thoughts >> here too. >=20 > Unfortunately IETF 101 conflicts with OCF meeting in Prague. > However FRI afternoon, we will have a T2TRG/ OCF/ WoT joint meeting = there, > https://github.com/t2trg/2018-03-ocf-wot > so your participation would be much appreciated. >=20 > best regards >=20 > JinHyeock --Apple-Mail=_B48E3D4B-B1C6-4342-92ED-0E795EEFD7D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = JinHyeock, hi T2TRG chairs,

    would it be possible for you to share in this thread the = remote participation details of the T2TRG/ OCF/ WoT join = meeting?

    Thanks!
    - - Jaime Jim=C3=A9nez

    On 16 Mar 2018, at 1.03, JinHyeock Choi <jinchoe@gmail.com> = wrote:

    Bill

       ol=3Dhttp://[FDFD::123]:61616, coap://[2001:db8:f1::2]:5683

    corresponds to

    =    "eps": [
    =      {"ep": "http://[FDFD::123]:61616"},
    =      {"ep": "coaps://[2001:db8:f1::2]:5683"}
    =    ]

    That is = good. Going forward, the mapping would become easier: We've defined
    "ol" to be repeatable instead of a comma separated list of = base URIs. For
    example,
    https://tools.ietf.org/html/draft-silverajan-core-coap-protocol= -negotiation-08#section-6.1

    thanks for the clarification. I mistakenly referred the = examples from v08.

    There still exisit some = differences
    (e.g., URI in "ep" shall have IP address in = its authority.),
    which, I hope, we would discuss in joint = meeting next FRI.

    If you are = participating in IETF 101, we can also arrange a corridor
    discussion around this topic. I'd be interested in hearing = your thoughts
    here too.

    Unfortunately IETF 101 conflicts with OCF meeting in = Prague.
    However FRI afternoon, we will have a T2TRG/ OCF/ = WoT joint meeting there,
    https://github.com/t2trg/2018-03-ocf-wot
    so = your participation would be much appreciated.

    best regards

    JinHyeock

    = --Apple-Mail=_B48E3D4B-B1C6-4342-92ED-0E795EEFD7D9-- --Apple-Mail=_63050CFB-C35E-4B04-88D4-84005C7675B4 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDMxOTEwNTAwOVowIwYJKoZIhvcNAQkEMRYEFGl3PykFmjftjcLKpMNx7sMI5N/w MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAOu88dlWC538Rt1DS8ei9a0kX5MmjaSNKUOmuyMpOt6pGXwGXduTLEtwTzIQ5D/Nz Etw3lZfGY8luUMWhK6iaxsoDy4JyAIILfDkltLjZCyoATm6T3vF26+7IBF7RuRBKcWBNxOSQpLZb takcr+8ERRNCcp40iBi3OiUaoJjqPdIVKu6xq0x6l8AqSJ+Va5cvs1JGaShzR1eTg7n8AbIVhrjz bUQArjBN5c9HjVZWMztGX35sdCoaFKHnMoPNNSmTcj30iVDfV9fzmWonRiia0n+FFxwp0PPrUw5W OD9Xm87XtPhghAPO4HOIQYYEdwesul+fJMWGh/qPzHyggWxyIwAAAAAAAA== --Apple-Mail=_63050CFB-C35E-4B04-88D4-84005C7675B4-- From nobody Mon Mar 19 04:39:29 2018 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 AE9D7127077; Mon, 19 Mar 2018 04:39:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152145956668.15965.13041321010560214272@ietfa.amsl.com> Date: Mon, 19 Mar 2018 04:39:26 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:39:27 -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 WG of the IETF. Title : Object Security for Constrained RESTful Environments (OSCORE) Authors : Goeran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-11.txt Pages : 69 Date : 2018-03-19 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-11 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 Mar 19 08:40:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676C7129C5D for ; Mon, 19 Mar 2018 08:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 wwhXVWSPTqsV for ; Mon, 19 Mar 2018 08:40:42 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 34B8612DB6E for ; Mon, 19 Mar 2018 08:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521474038; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wzQMFtZWkYvf7fnAywBSG5FGG/ffwC3Dv4sLJ9JsjnQ=; b=gkO7gpqng64XXd5nDatmkLcY536tN5JUcsdaozmEi9UUnqNAdnCNpqAyu5x9yXJG a9PndZ5D4s33dKDqywmOQ0k2JsR6vRLrt8ie9bssoH26QKiffMiwJMLNLTFWpnvx 4N/jgSpkWhMTjTttVr675vZsbyzxFoRgIlTBYWT+XX8=; X-AuditID: c1b4fb25-669ff70000006222-83-5aafd9f65b55 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EA.AA.25122.6F9DFAA5; Mon, 19 Mar 2018 16:40:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 16:40:37 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , core CC: JinHyeock Choi , Bill Silverajan , "t2trg-chairs@irtf.org" Thread-Topic: [core] Review of draft-silverajan-core-coap-protocol-negotiation Thread-Index: AQHTv5ig2bnDuwMWgk2KICPv6bur4w== Date: Mon, 19 Mar 2018 15:40:37 +0000 Message-ID: <51E1C328-C1E2-4C88-950D-89909801DDEF@ericsson.com> References: <0cc8bfd6-2f50-83b6-d392-e80de133ce34@tut.fi> <237126CD-5E63-41CB-A0E9-1F8E9ADF2716@ericsson.com> In-Reply-To: <237126CD-5E63-41CB-A0E9-1F8E9ADF2716@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.128.200] Content-Type: text/plain; charset="utf-8" Content-ID: <8E625765C2CD604CA0FA417DD0C89EE4@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7uO63m+ujDE4+4Le4eErWYt/b9cwW T1ftYLW4N+kikwOLx85Zd9k9liz5yeQxeeNhNo/501cwBrBEcdmkpOZklqUW6dslcGUsv/GF seCZUMXP7hb2BsYVQl2MnBwSAiYSc4/eZepi5OIQEjjMKNH/fSkrhLOEUeLO/AksIFVsArYS T1r3sYLYIgKREkvmLWMGKWIWaGeU2HbmOSNIQljAV6L51So2iKIAiZm3ehkhbD2JhQ/uMYHY LAKqEgfvbAMbyitgL7H91i9GiG1/GSXe7zzEDpLgFHCQuPn8AVgzo4CYxPdTa8CamQXEJW49 mc8EcbeAxJI955khbFGJl4//sULYShKLLqwHmsMBVK8psX6XPkSrtcSGefNYIWxFiSndD9kh bhCUODnzCcsERrFZSDbMQuiehaR7FpLuWUi6FzCyrmIULU4tTspNNzLWSy3KTC4uzs/Ty0st 2cQIjL+DW36r7mC8/MbxEKMAB6MSD++1A+ujhFgTy4orcw8xSnAwK4nwPr2yLkqINyWxsiq1 KD++qDQntfgQozQHi5I47xzh9ighgfTEktTs1NSC1CKYLBMHp1QDo8yfus8lLUt371KfcnHS kxPuBzjOBU9ammJyxi3fQXTd9dWyJ3IE15daXtr991DXhTmRuyea6nzdfVv58+UZPQkFQX9/ fliZs+ughr3R+strn7SY9MocfJrznFMotnTXbYuNlxXkPJkqpsub5P7YLZW/Y/Iq367ZL8Ii OXWL/1XEpoR2zNJ92qHEUpyRaKjFXFScCAAAtBvUuwIAAA== Archived-At: Subject: Re: [core] Review of draft-silverajan-core-coap-protocol-negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 15:40:45 -0000 VGhlIHJlbW90ZSBwYXJ0aWNpcGF0aW9uIGRldGFpbHMgYXJlIG5vdyBhdmFpbGFibGUgaW4gdGhl IG1lZXRpbmcgZ2l0aHViIHBhZ2U6DQpodHRwczovL2dpdGh1Yi5jb20vdDJ0cmcvMjAxOC0wMy1v Y2Ytd290DQoNCg0KQ2hlZXJzLA0KQXJpDQoNCj4gT24gMTkgTWFyIDIwMTgsIGF0IDEwLjUwLCBK YWltZSBKaW3DqW5leiA8amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4g SGkgSmluSHllb2NrLCBoaSBUMlRSRyBjaGFpcnMsDQo+IA0KPiB3b3VsZCBpdCBiZSBwb3NzaWJs ZSBmb3IgeW91IHRvIHNoYXJlIGluIHRoaXMgdGhyZWFkIHRoZSByZW1vdGUgcGFydGljaXBhdGlv biBkZXRhaWxzIG9mIHRoZSBUMlRSRy8gT0NGLyBXb1Qgam9pbiBtZWV0aW5nPw0KPiANCj4gVGhh bmtzIQ0KPiAtIC0gSmFpbWUgSmltw6luZXoNCj4gDQo+PiBPbiAxNiBNYXIgMjAxOCwgYXQgMS4w MywgSmluSHllb2NrIENob2kgPGppbmNob2VAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4gQmls bA0KPj4gDQo+Pj4+ICAgIG9sPWh0dHA6Ly9bRkRGRDo6MTIzXTo2MTYxNiwgY29hcDovL1syMDAx OmRiODpmMTo6Ml06NTY4Mw0KPj4+PiANCj4+Pj4gY29ycmVzcG9uZHMgdG8NCj4+Pj4gDQo+Pj4+ ICAgICJlcHMiOiBbDQo+Pj4+ICAgICAgeyJlcCI6ICJodHRwOi8vW0ZERkQ6OjEyM106NjE2MTYi fSwNCj4+Pj4gICAgICB7ImVwIjogImNvYXBzOi8vWzIwMDE6ZGI4OmYxOjoyXTo1NjgzIn0NCj4+ Pj4gICAgXQ0KPj4+PiANCj4+PiBUaGF0IGlzIGdvb2QuIEdvaW5nIGZvcndhcmQsIHRoZSBtYXBw aW5nIHdvdWxkIGJlY29tZSBlYXNpZXI6IFdlJ3ZlIGRlZmluZWQNCj4+PiAib2wiIHRvIGJlIHJl cGVhdGFibGUgaW5zdGVhZCBvZiBhIGNvbW1hIHNlcGFyYXRlZCBsaXN0IG9mIGJhc2UgVVJJcy4g Rm9yDQo+Pj4gZXhhbXBsZSwNCj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2lsdmVyYWphbi1jb3JlLWNvYXAtcHJvdG9jb2wtbmVnb3RpYXRpb24tMDgjc2VjdGlvbi02LjEN Cj4+IA0KPj4gdGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gSSBtaXN0YWtlbmx5IHJlZmVy cmVkIHRoZSBleGFtcGxlcyBmcm9tIHYwOC4NCj4+IA0KPj4+PiBUaGVyZSBzdGlsbCBleGlzaXQg c29tZSBkaWZmZXJlbmNlcw0KPj4+PiAoZS5nLiwgVVJJIGluICJlcCIgc2hhbGwgaGF2ZSBJUCBh ZGRyZXNzIGluIGl0cyBhdXRob3JpdHkuKSwNCj4+Pj4gd2hpY2gsIEkgaG9wZSwgd2Ugd291bGQg ZGlzY3VzcyBpbiBqb2ludCBtZWV0aW5nIG5leHQgRlJJLg0KPj4+PiANCj4+PiBJZiB5b3UgYXJl IHBhcnRpY2lwYXRpbmcgaW4gSUVURiAxMDEsIHdlIGNhbiBhbHNvIGFycmFuZ2UgYSBjb3JyaWRv cg0KPj4+IGRpc2N1c3Npb24gYXJvdW5kIHRoaXMgdG9waWMuIEknZCBiZSBpbnRlcmVzdGVkIGlu IGhlYXJpbmcgeW91ciB0aG91Z2h0cw0KPj4+IGhlcmUgdG9vLg0KPj4gDQo+PiBVbmZvcnR1bmF0 ZWx5IElFVEYgMTAxIGNvbmZsaWN0cyB3aXRoIE9DRiBtZWV0aW5nIGluIFByYWd1ZS4NCj4+IEhv d2V2ZXIgRlJJIGFmdGVybm9vbiwgd2Ugd2lsbCBoYXZlIGEgVDJUUkcvIE9DRi8gV29UIGpvaW50 IG1lZXRpbmcgdGhlcmUsDQo+PiBodHRwczovL2dpdGh1Yi5jb20vdDJ0cmcvMjAxOC0wMy1vY2Yt d290DQo+PiBzbyB5b3VyIHBhcnRpY2lwYXRpb24gd291bGQgYmUgbXVjaCBhcHByZWNpYXRlZC4N Cj4+IA0KPj4gYmVzdCByZWdhcmRzDQo+PiANCj4+IEppbkh5ZW9jaw0KPiANCg0K From nobody Mon Mar 19 09:35:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA5212D7FC for ; Mon, 19 Mar 2018 09:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 WgBQ8QR4JhlL for ; Mon, 19 Mar 2018 09:35:06 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id CE49A12D874 for ; Mon, 19 Mar 2018 09:35:05 -0700 (PDT) Received: from dhcp-8e53.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:ec88:e430:e6cb:55b3]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C13801B0012A; Mon, 19 Mar 2018 16:35:04 +0000 (GMT) Message-ID: <5AAFE6B8.2050407@erg.abdn.ac.uk> Date: Mon, 19 Mar 2018 16:35:04 +0000 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carsten Borman CC: jaime@iki.fi, core@ietf.org, Gorry Fairhurst References: <5AAFD717.6090502@erg.abdn.ac.uk> In-Reply-To: <5AAFD717.6090502@erg.abdn.ac.uk> X-Forwarded-Message-Id: <5AAFD717.6090502@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Some comments on: draft-ietf-core-cocoa-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 16:35:09 -0000 To understand draft-ietf-core-cocoa-03, I did a quick read through of this. Sorry, it took a long read to understand what this ID is saying. I finally worked it out and some of this commentary may be useful to others so I include it below. Gorry (p.s. I am not a list memebr, please post to core WG - I can be reached at the cc line above). ---------------- Checking against BCPs: Section 3.1.1 of RFC8085 provides BCP for timers. This ID would benefit from saying something like this from RFC8085: The method uses averaging of multiple recent measurement samples to account for variance using an exponentially weighted moving average. RFC8085 says this: Independent latency estimates SHOULD be maintained for each destination with which an endpoint communicates. But rather ambiguously this ID says this: It may also be worthwhile to perform RTT estimation not just based on information measured from a single destination endpoint, but also based on entire hosts (IP addresses) and/or complete prefixes (e.g., maintain an RTT estimate for a whole /64). The exact way this can be used to reduce the amount of state in an initiator is for further study. - but yet this ID does not warn of the issues in not being able to predict a consistent RTT (because a few (?) of the endpoints you talk to are actually remotely located across a path, albeit they are within a network prefix). I think this is a potential issue. This ID sets the Blind RTO Estimate to 2 seconds, whereas RFC8085 states: Such applications SHOULD NOT send more than one UDP datagram every 3 seconds and SHOULD use an even less aggressive rate when possible. - Im not sure why 2 s was chosen in preference to 3? Although they are both fairly large numbers. RFC 5033 probably could be mentioned in the intro, but actually targets a different use case, and that can be said I think. ---------------- The abstract isnt super clear about what is normal and advanced modes of operations, in fact the advanced mode is also claimed as simple. Thats not easy to follow. As I see this is an advanced RTT for congestion control. Section 4 Advanced CoAP Congestion Control: RTO Estimation - This isnt really a Advanced CoAP Congestion Control - it is advanced RTO estimation. As I read it, the congestion control remains the same. I dont really understand this phrase: For an initiator that plans to make multiple requests to one destination endpoint, it may be worthwhile to make RTT measurements in order to compute a more appropriate RTO than the default initial timeout of 2 to 3 s. In particular, a wide spectrum of RTT values is expected in different types of networks where CoAP is used. What does may be worthwhile mean? I dont understand the context. Perhaps something like this was what was intended?: The initiator as defined in [RFCxxx] uses a default initial timeout of 2 to 3 s. An initiator that plans to make multiple requests to one destination endpoint, can benefit from making RTT measurements that enable it to compute a more appropriate RTO. This is expected to improve performance across the wide range of RTT values that may be expected across the types of networks where CoAP is used. Section 4 says: To ensure that the new scheme is not posing a danger to the network, - This seems rather too bold, I dont know how to ensure this. Although I do expect it would be good tos ay something like: suggest there is not a significant risk. This also was hard to follow: Note that such a mechanism must, during idle periods, decay RTO estimates that are shorter or longer than the default RTO estimate back to the default RTO estimate, until fresh measurements become available again, as proposed in Section 4.3. - why isnt the ability to grow the RTT during idle periods actually not a standards requirement? I could not find normative text in section 4.3 either, and I really do think this particular point should be written using MUST clauses. Finally, this also is not really very clear to me: A client that has arrived at a RTO estimate shorter than 1 s SHOULD therefore use a larger backoff factor for retransmissions to avoid expending all of its retransmissions (MAX_RETRANSMIT, see Section 4.2 of [RFC7252], normally 4) in the default interval of 2 to 3 s. - what does this actually say you need to implement? (I think this is just a wording issue??) From nobody Mon Mar 19 10:05:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C00128959 for ; Mon, 19 Mar 2018 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 koz86NnO_lWV for ; Mon, 19 Mar 2018 10:05:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 32F291204DA for ; Mon, 19 Mar 2018 10:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521479118; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lHDvXccmY5AXwr8foiXRfdm2bSp/uCTjgJrP/PR0JOE=; b=AZQWcpgcYSiwwiudL30Fd861pG9oK3KIVVJROh+RIeG20ufkoULp7Vj9WszrpG5c lgzEr5iR5zKiQRF6KLTxwWafUU1j+oqbChgb2e+XaPDiWbK3VCZ+RUpBI+KuKXqo D26CIUljGIr3oqjdJ+yzuabk10gqTElAvjQdRc2FvHs=; X-AuditID: c1b4fb2d-499ff70000005540-7b-5aafedceab49 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 66.66.21824.ECDEFAA5; Mon, 19 Mar 2018 18:05:18 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 18:05:18 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , Dave Thaler , Carsten Bormann Thread-Topic: [IANA #1051132] expert review for draft-ietf-core-object-security (Message Headers) Thread-Index: AQHTrzU1WaidTU0F20yroKdmepH2BqPB9HwAgBXlPwA= Date: Mon, 19 Mar 2018 17:05:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [5.148.130.171] Content-Type: text/plain; charset="utf-8" Content-ID: <3B9D92D28FD58A4A83C7B27EF6667FCC@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2J7uO65t+ujDLqfKFkcmXKX1WLf2/XM FpdWHGF1YPZYsuQnk0frjr/sHtMWZQYwR3HZpKTmZJalFunbJXBl7JqyiL3gAmvFpi+nmRsY 97B2MXJySAiYSBxY8x/I5uIQEjjMKNH59AYbhLOEUWLRg0lMIFVsAi4SDxoegdkiAlkSZ9e8 ZgSxhQWSJPa8/ssIEU+W+Nx0mB3CtpK4t+4fUD0HB4uAqsTMAwEgYV4BC4lZc5axQ8w/ySjR fWc32BWcApYSx98/BpvPKCAm8f3UGjCbWUBc4taT+UwQlwpILNlznhnCFpV4+fgfWK+ogJ7E 3p52NpBdEgKKEvt22IOYzAKaEut36UOY1hJHzitBDFSUmNL9kB3iGkGJkzOfsExgFJuFZNcs hOZZCM2zkDTPQtK8gJF1FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZghB3c8lt3B+Pq146H GAU4GJV4eMtvrY8SYk0sK67MPcQowcGsJML79Mq6KCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 Jz15o4QE0hNLUrNTUwtSi2CyTBycUg2M/Kk3CxeY/tdzfqaf76d3f9qj3M3H5JU4CzNS5n99 y9XsEBJ5/tRyxyctn1xL7HZOqE508T/P0/7aP9/0Zqnuv5ZXPpYNk/drS+nPPvpCa7llTX7h AhWPG/d0jXlX3FevYjTWEJh5dvLrgPTyDXfPVCi/FFy95/ickjMH/UVYmR1lRNpdIi2UWIoz Eg21mIuKEwESIRWcrAIAAA== Archived-At: Subject: [core] FW: [IANA #1051132] expert review for draft-ietf-core-object-security (Message Headers) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 17:05:22 -0000 DQpEdXJpbmcgdGhlIE9TQ09SRSBwcmVzZW50YXRpb24gaW4gdGhlIENvUkUgV0cgbWVldGluZyB0 b2RheSBDYXJzdGVuDQpwcm9wb3NlZCB5ZXQgYW5vdGhlciBuYW1lIGZvciB0aGUgSFRUUCBoZWFk ZXIgZmllbGQ6IE9TQ09SRS4gQXMgYQ0KY29uc2VxdWVuY2Ugd2Ugd291bGQgYWxzbyByZW5hbWUg dGhlIENvQVAgb3B0aW9uIE9TQ09SRSwgaW4gd2hpY2ggY2FzZSB3ZQ0KaGF2ZSB0aGUgc2FtZSBu YW1lIGZvciBwcm90b2NvbCwgcHJvdG9jb2wgbWVzc2FnZSwgQ29BUCBvcHRpb24gYW5kIEhUVFAN CmhlYWRlciBmaWVsZC4NCg0KQW55IG9iamVjdGlvbnMgdG8gdGhpcyBjaGFuZ2U/DQoNCkfDtnJh bg0KDQoNCk9uIDIwMTgtMDMtMDUgMTg6NDMsICJHw7ZyYW4gU2VsYW5kZXIiIDxnb3Jhbi5zZWxh bmRlckBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPg0KPldlIGFsc28gZm9sbG93ZWQgdGhlIHN1Z2dl c3Rpb24gdG8gcmVuYW1lIHRoZSBIVFRQIGhlYWRlciBmaWVsZA0KPkNvQVAtT2JqZWN0LVNlY3Vy aXR5Lg0KDQoNCg0K From nobody Mon Mar 19 12:25:24 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91912025C for ; Mon, 19 Mar 2018 12:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 MpuHwdrvJUyj for ; Mon, 19 Mar 2018 12:25:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 137D1124D6C for ; Mon, 19 Mar 2018 12:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521487516; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZojW9TVZ7wnVMBkwdO+TlUsoGK5LtyU5w9cFebk/cRY=; b=OpXJPsZMg7LJIEQ6VSP21rV3nlnzN3Nq6q0KxAsoTkC8y9tB5h8nju4/rB45iWUP WlShk+X7PpT9ZAhNfPa53bqQDGUrYF4vf39MZqU7dyUfJW9LrLHpnu3WNjSoRA2b RVr/wASa0OGek1/N2QVE2BVRNi0RJBtSY3s6go0HuqQ=; X-AuditID: c1b4fb3a-347ff700000067b4-b7-5ab00e9c64c7 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.79.26548.C9E00BA5; Mon, 19 Mar 2018 20:25:16 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 20:25:15 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Jim Schaad CC: core , "draft-ietf-core-coap-pubsub@ietf.org" Thread-Topic: PubSub - Questions round 1 Thread-Index: AdMtDUO/Se0FaC9oQ8e7prarOw47xiSolvAA Date: Mon, 19 Mar 2018 19:25:14 +0000 Message-ID: References: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> In-Reply-To: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.128.200] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <494DACF97BDA7C4DB5E91097075B8ED3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7ou4cvg1RBk++Sljse7ue2eLZ06PM Fqunf2dzYPbYOGc6m8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIu9M9mKrgrUrHw0jb2Bsb5Al2M nBwSAiYSMxreMnYxcnEICRxmlPg6dRkThLOEUWLN50VMIFVsAvYSk9d8ZASxRQTUJbauvgkW ZxbIlHj0+xgLiC0MFD9y9w5rFyMHUI2GxOU9khDlRhK7F29iA7FZBFQl1k24A1bOCzTy781j zCC2EJC9vH0KWA2ngIPEgcarYHFGATGJ76fWQK0Sl7j1ZD4TxNECEkv2nGeGsEUlXj7+xwph K0ksurCeHaJeT+LGVIiZzALWEpf3bYSytSWWLXzNDHGDoMTJmU9YJjCKzUKyYhaS9llI2mch aZ+FpH0BI+sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMAIO7jlt9UOxoPPHQ8xCnAwKvHw Jt1cHyXEmlhWXJl7iFGCg1lJhPfplXVRQrwpiZVVqUX58UWlOanFhxilOViUxHmd0iyihATS E0tSs1NTC1KLYLJMHJxSDYxLW04pHBZdpbRH4tgmn7jMYw6B3y6uOvXktte2mDtr37EziDyT F/OdE1+5WciptXryt7Yl9h7V2pV321Xnyd7bqvDFfFHc4dj2nVNbhe6GLBeZ7LROLW+Bl3bn jxch3TNN3W9Uxh1sm11cqZxdlXWm4/OJo1Pn1wgsrfmk4v1BJU3ntcBu64VKLMUZiYZazEXF iQBogvUBrAIAAA== Archived-At: Subject: Re: [core] PubSub - Questions round 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 19:25:20 -0000 Hi Jim, Here's finally answers to some of your questions. > On 14 Sep 2017, at 7.10, Jim Schaad wrote: >=20 > 1 I am not clear what the visibility of the intermediate subtopic notes > should be. Should these nodes appear in the link list when doing a GET o= n > the root of the pub-sub tree? Should these nodes appear when doing a > discovery on /.well-known/core? I think the explicitly created topics should be visible in discovery. Howev= er, this includes the "main topics" created with CREATE interface. Perhaps = the sub-topics under a main topic could be hidden from the root discovery s= ince they can be discovered from the main topic. But would be great to hear more opinions on this. > 2. I would appreciate a discussion for section 5 (resource directory) on > what the trade-offs for publishing items into a resource directory? What > sets of nodes does it make sense to publish vs not publish - topics of > discussion would include intermediate nodes and max-age for nodes that mi= ght > disappear quickly. I think lots of this is going to be implementation dependent. We could perh= aps discuss the benefits of sub-topics: that you can expose only the main t= opic(s), let client discover sub-topics if needed, and this way save bandwi= dth on discovery is there are lots of sub-topics under different main topic= s. I'll make a PR out of this. > 3. When doing discovery, I am not sure if you examples are correct. My > understanding is that since a URI path is being returned as part of the l= ink > format rather than a full path, the client is supposed to interpret this > value using the GET path as the context of the path. This would be rule= c > of section 2.1 of RFC6690. This rule seems to have been modified for the > /.well-known/core to say only use the scheme + authority and ignore the p= ath > to the resource. However, I do not believe that this rule is suspended i= n > this case. This means that the return value for figure 4 would be > ";rt=3Dtemperature;ct=3D50". Do you believe that I am wro= ng? I think you're correct here. But I wonder how can we generate then topics o= utside of the ps -- or if we want to do that. Let's discuss tomorrow. > 4. Just because I don't understand. In RFC 6690 - what is the origin f= or > rule (b)? I would have thought this was the target URI value itself, but= in > that case I would expect that (b) should be before (a) if it has a schema > and thus is an absolute path. I suppose it's the link authority. But let's check with Zach ;) Cheers, Ari= From nobody Mon Mar 19 13:11:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4569129C6A; Mon, 19 Mar 2018 13:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 o4eJwdykOy2z; Mon, 19 Mar 2018 13:11:03 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 3A9301273E2; Mon, 19 Mar 2018 13:11:03 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id n12so19939126wra.2; Mon, 19 Mar 2018 13:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rSV7b21rSqviYl+3WbrZEJtucH6xskGtvRtJikn4HC4=; b=Ue5Ju9qAuEkLD43FAsdP5c7j9smEjfNJSwtyWE+11uqUUXZQOhSi88A6Rjmh6SIbi4 n/FSIOQohSMTu1BpiabXt9Ic46dyZC0CO7ydKAXLYiPMiL/eRaqDyJzZ94TsCffZTZSt OYsCEHoZX4F+dfvjCHDl/pSe59Ga9tpaQCF6aV4z5sXdAfvC3BcyRkTfe1AenaZ1D8Dc 5oRVu/etJb/4zfpQFr/n+69xTMnz5xTRaAsY/REv1F71CMlB9upvnqqKeJ0GvDvy5rq5 lQPrjMmC137QraEwahqWNk6YRm60iTzA0wP+kPtx+gvLwUl3Awv/ZW6d71wI6WMp06QC iwfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rSV7b21rSqviYl+3WbrZEJtucH6xskGtvRtJikn4HC4=; b=DExQxR7LPykLdkiioLLegqrqIrwiJATkveNbSEj35v/swEwrCkk+cdO6QjbPgoTVrW scaHKtPC48iAU7PepTBAH6ZE9yA5jbv5/BwWW7PBB37oQiQv2Q3cAQFTL52I8wUHGpFk bAzAX3XUNl+v7zCnd1pG07Cu8zYsRnEM1jfAk0aufRPhJ5pPAL3wmbS9x9gMHelyHPz7 USb1RIl9X426d0BwNLQGX9Axn7G6fyDlfG9PRKD7AjA3c9fPJvyVHi0gAkSJ8Lw8JPuV RTvRgXkw9wr9v7isuhmIChEJgvzs/s/ZjLxNiiALtqjhvYrcLYAxQtiTOoiRaRRtD+Bw ZDdw== X-Gm-Message-State: AElRT7ENqFhFt/9N3soXLS6M9ImsPZN1hFp75dONf1fBcSRrJZFH1jQa dqh9OVasRqb8U8Rd3I7mb3M= X-Google-Smtp-Source: AG47ELvwF5xcdxhU7CGc6B+6/2tfg1IDCXV774NQc54ZuN/ggz5vprzm8WFJTaFVvptCHOGDOWRNFg== X-Received: by 10.223.185.25 with SMTP id k25mr9868375wrf.237.1521490261531; Mon, 19 Mar 2018 13:11:01 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:cd0:6da1:8b0f:4cc5? ([2001:67c:1232:144:cd0:6da1:8b0f:4cc5]) by smtp.gmail.com with ESMTPSA id d8sm29378wrf.8.2018.03.19.13.11.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 13:11:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: Date: Mon, 19 Mar 2018 20:10:59 +0000 Cc: Jim Schaad , "draft-ietf-core-coap-pubsub@ietf.org" , core Content-Transfer-Encoding: quoted-printable Message-Id: References: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> To: =?utf-8?Q?Ari_Ker=C3=A4nen?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] PubSub - Questions round 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 20:11:06 -0000 > On Mar 19, 2018, at 7:25 PM, Ari Ker=C3=A4nen = wrote: >=20 > Hi Jim, >=20 > Here's finally answers to some of your questions. >=20 >> On 14 Sep 2017, at 7.10, Jim Schaad wrote: >>=20 >> 1 I am not clear what the visibility of the intermediate subtopic = notes >> should be. Should these nodes appear in the link list when doing a = GET on >> the root of the pub-sub tree? Should these nodes appear when doing a >> discovery on /.well-known/core? >=20 > I think the explicitly created topics should be visible in discovery. = However, this includes the "main topics" created with CREATE interface. = Perhaps the sub-topics under a main topic could be hidden from the root = discovery since they can be discovered from the main topic. Specifically, I would say that the "main" topics are the ones that are = created using the resource labeled rt=3Dcore.ps. Sub-topics, which are = created under "main" topics can in turn have sub-topics created under = them, and so on. We propose that only the topics created under the = core.ps resource will be returned on discovery using core.ps.discover. = Any sub-topics would be discovered by using GET with an accept header = option value that specifies link-format content. Each level sub-topic = would need to be discovered this way, until there are no links returned = indicating theat there are no more sub-topics. >=20 > But would be great to hear more opinions on this. >=20 >> 2. I would appreciate a discussion for section 5 (resource = directory) on >> what the trade-offs for publishing items into a resource directory? = What >> sets of nodes does it make sense to publish vs not publish - topics = of >> discussion would include intermediate nodes and max-age for nodes = that might >> disappear quickly. >=20 > I think lots of this is going to be implementation dependent. We could = perhaps discuss the benefits of sub-topics: that you can expose only the = main topic(s), let client discover sub-topics if needed, and this way = save bandwidth on discovery is there are lots of sub-topics under = different main topics. I'll make a PR out of this. >=20 >> 3. When doing discovery, I am not sure if you examples are correct. = My >> understanding is that since a URI path is being returned as part of = the link >> format rather than a full path, the client is supposed to interpret = this >> value using the GET path as the context of the path. This would be = rule c >> of section 2.1 of RFC6690. This rule seems to have been modified for = the >> /.well-known/core to say only use the scheme + authority and ignore = the path >> to the resource. However, I do not believe that this rule is = suspended in >> this case. This means that the return value for figure 4 would be >> ";rt=3Dtemperature;ct=3D50". Do you believe that I am = wrong? >=20 > I think you're correct here. But I wonder how can we generate then = topics outside of the ps -- or if we want to do that. Let's discuss = tomorrow. To further discuss: If the "currentTemp" topic was created by doing POST to the rt-core.ps = resource (e.g. "/ps/") with a payload like ;ct=3D40 then = the discovery will return ;ct=3D40 If we wish to allow clients to create topics anywhere in the broker URI = space, they can be created by doing POST to the rt-core.ps resource with = a payload like ;ct=3D40 then the discovery will return = ;ct=3D40 IOW, if the POSTed link contains a relative path (not starting with a = slash) then the topic resource is created under the core.ps resource = ("/ps/" in the example). >=20 >> 4. Just because I don't understand. In RFC 6690 - what is the = origin for >> rule (b)? I would have thought this was the target URI value itself, = but in >> that case I would expect that (b) should be before (a) if it has a = schema >> and thus is an absolute path. >=20 > I suppose it's the link authority. But let's check with Zach ;) >=20 >=20 > Cheers, > Ari > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Mar 19 16:52:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EC212D864 for ; Mon, 19 Mar 2018 16:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 yR-7Q15JJhcW for ; Mon, 19 Mar 2018 16:52:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 4EDFD12D964 for ; Mon, 19 Mar 2018 16:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521503525; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zUFPHmMjB2iZpe8QXJpGiDGrEa9CkWmlz15rL14OGhc=; b=V33v/WrSsBjv+45Ui8B+x4NAOFkv3Vef9GmMaexTwIOIiEMleAT2IFe2MDIVb3BT /fw8S/nkDlZ0Qky8knaV+eq5XYJepE6/g/rrUwOk/DuJWpsefHiuWiEBhsv10CQI mVCFmF+5HcOgN32WEA4gVtT60WhZIo/lCHDJk1crWlE=; X-AuditID: c1b4fb2d-499ff70000005540-3d-5ab04d250f37 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1A.7D.21824.52D40BA5; Tue, 20 Mar 2018 00:52:05 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 00:52:04 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: New Version Notification for draft-keranen-core-too-many-reqs-01.txt Thread-Index: AQHTv9y1TuNDdMT3VU+febjxRsL7lg== Date: Mon, 19 Mar 2018 23:52:04 +0000 Message-ID: <737D6CB7-440E-4C7C-92AC-DCD6757C8A65@ericsson.com> References: <152150327555.9793.12762363833885027220.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.159.97] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <334AEDB82E0CCD42BB735B1ADD839ED3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7qK6q74Yogw9zlSz2vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFdbzrMWbBSo6Gl5ytjAuJy3i5GTQ0LAROLJ9N1MXYxcHEIC hxklfs+7zAbhLGGUeLNxMytIFZuAvcTkNR8ZQWwRAQmJzq/72bsYOTiEBUIkFqwuhgiHSFw9 vRGqRE9i2/nbbCA2i4CqxOS3y9hBbF6gMQef3ACLCwn4Sqzq3Q9mMwqISXw/tYYJxGYWEJe4 9WQ+E8RxAhJL9pxnhrBFJV4+/scKYStK7N57nxGiXk/ixtQpbBC2tcS/5TNYIGxtiWULXzND 7BWUODnzCcsERpFZSFbMQtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+nl5da sokRGBMHt/zW3cG4+rXjIUYBDkYlHt4C+w1RQqyJZcWVuYcYJTiYlUR4n15ZFyXEm5JYWZVa lB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2ampBahFMlomDU6qBcQFL+nOv/adLG/q/nzJr XXDZ787DwG1H7sZKWV7U2KVssdEw4Mg+2fKPu/frXNFTe+FttbbPeJcSf71pw3anZ3oO821/ nXYM29IVHvr2+ZVzLn1TlBkjO/vsztdXLHR47n6lf8XW1mPrGswl178pY2ZjVt90VuSOeEvU lJ69Xuc1o1SiXK6/U2Ipzkg01GIuKk4EAC541WCFAgAA Archived-At: Subject: [core] Fwd: New Version Notification for draft-keranen-core-too-many-reqs-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Mar 2018 23:52:09 -0000 This version updates the draft according to the discussion at the CoRE WG s= ession today: the potential methods for a server to indicate what kind of a= ctions are OK for the client are out of scope for this draft and hence the = related TBDs were removed. This version also addresses Klaus Hartke's review comments regarding redund= ant re-definitions of MaxAge option behavior. Cheers, Ari > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-keranen-core-too-many-reqs-01= .txt > Date: 19 March 2018 at 23.47.55 GMT > To: Ari Keranen >=20 >=20 > A new version of I-D, draft-keranen-core-too-many-reqs-01.txt > has been successfully submitted by Ari Keranen and posted to the > IETF repository. >=20 > Name: draft-keranen-core-too-many-reqs > Revision: 01 > Title: Too Many Requests Response Code for the Constrained Application P= rotocol > Document date: 2018-03-19 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-keranen-core-t= oo-many-reqs-01.txt > Status: https://datatracker.ietf.org/doc/draft-keranen-core-too-m= any-reqs/ > Htmlized: https://tools.ietf.org/html/draft-keranen-core-too-many-r= eqs-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-keranen-core-= too-many-reqs > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-keranen-core-to= o-many-reqs-01 >=20 > Abstract: > A Constrained Application Protocol (CoAP) server can experience > temporary overload because one or more clients are sending requests > to the server at a higher rate than the server is capable or willing > to handle. This document defines a new CoAP Response Code for a > server to indicate that a client should reduce the rate of requests. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Tue Mar 20 01:13:04 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847A91201F2; Tue, 20 Mar 2018 01:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 PGuZsWvP1kOs; Tue, 20 Mar 2018 01:13:01 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D079124207; Tue, 20 Mar 2018 01:13:01 -0700 (PDT) Received: from Jude (31.133.136.157) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Mar 2018 01:10:50 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Ari_Ker=E4nen'?= CC: 'core' , References: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> In-Reply-To: Date: Tue, 20 Mar 2018 08:12:51 +0000 Message-ID: <03dd01d3c023$403bb700$c0b32500$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHFRtZcOzaEH4+m2HRjYGdoNGI0SQI/ImqQo+O+mQA= Content-Language: en-us X-Originating-IP: [31.133.136.157] Archived-At: Subject: Re: [core] PubSub - Questions round 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 08:13:03 -0000 > -----Original Message----- > From: Ari Ker=E4nen > Sent: Monday, March 19, 2018 7:25 PM > To: Jim Schaad > Cc: core ; draft-ietf-core-coap-pubsub@ietf.org > Subject: Re: PubSub - Questions round 1 >=20 > Hi Jim, >=20 > Here's finally answers to some of your questions. >=20 > > On 14 Sep 2017, at 7.10, Jim Schaad wrote: > > > > 1 I am not clear what the visibility of the intermediate subtopic > > notes should be. Should these nodes appear in the link list when > > doing a GET on the root of the pub-sub tree? Should these nodes > > appear when doing a discovery on /.well-known/core? >=20 > I think the explicitly created topics should be visible in discovery. However, > this includes the "main topics" created with CREATE interface. Perhaps = the > sub-topics under a main topic could be hidden from the root discovery since > they can be discovered from the main topic. >=20 > But would be great to hear more opinions on this. No, that is not what I asked. If I do a create of the topic /PubSub/Hidden/MyTopic Hidden has not yet be created as a topic so it will be implicitly = created. When I do the GET, I expect that MyTopic would be visible as part of the link list but I am not clear that Hidden would be returned in the link = list because nobody explicitly created it. >=20 > > 2. I would appreciate a discussion for section 5 (resource = directory) > > on what the trade-offs for publishing items into a resource = directory? > > What sets of nodes does it make sense to publish vs not publish - > > topics of discussion would include intermediate nodes and max-age = for > > nodes that might disappear quickly. >=20 > I think lots of this is going to be implementation dependent. We could > perhaps discuss the benefits of sub-topics: that you can expose only = the > main topic(s), let client discover sub-topics if needed, and this way = save > bandwidth on discovery is there are lots of sub-topics under different main > topics. I'll make a PR out of this. >=20 > > 3. When doing discovery, I am not sure if you examples are correct. > > My understanding is that since a URI path is being returned as part = of > > the link format rather than a full path, the client is supposed to interpret > this > > value using the GET path as the context of the path. This would be rule c > > of section 2.1 of RFC6690. This rule seems to have been modified = for > > the /.well-known/core to say only use the scheme + authority and > > ignore the path to the resource. However, I do not believe that = this > > rule is suspended in this case. This means that the return value = for figure 4 > would be > > ";rt=3Dtemperature;ct=3D50". Do you believe that I = am > wrong? >=20 > I think you're correct here. But I wonder how can we generate then = topics > outside of the ps -- or if we want to do that. Let's discuss tomorrow. Christian, please verify this for me. Jim >=20 > > 4. Just because I don't understand. In RFC 6690 - what is the > > origin for rule (b)? I would have thought this was the target URI > > value itself, but in that case I would expect that (b) should be > > before (a) if it has a schema and thus is an absolute path. >=20 > I suppose it's the link authority. But let's check with Zach ;) >=20 >=20 > Cheers, > Ari From nobody Tue Mar 20 02:13:21 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852E512420B for ; Tue, 20 Mar 2018 02:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 JD0udDxHlW3H for ; Tue, 20 Mar 2018 02:13:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 C3350120227 for ; Tue, 20 Mar 2018 02:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521537195; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TZoE/33aXF8+vk2NFR1cfDwzEDxH+3YyTL8UK6Bu2aI=; b=TdFTXU9JH7IXsWJdYovbB1Zgry43SKF4V706reBBDkQ9JBqxAHfS7EyfwJDnNNDY 5+ABpXTOP5Ht4PNNn7JVDEOgIO7lo0kPwtN5mMP2Xgj3o4/KwMOBpKS51pz1/M7J SVUDD/+TMy/f7dmapyNXPbU0v2LNWd2aFCcgOU71VwU=; X-AuditID: c1b4fb25-a4a959c000006222-e4-5ab0d0ab3874 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1C.AF.25122.BA0D0BA5; Tue, 20 Mar 2018 10:13:15 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 10:13:13 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG (core@ietf.org)" Thread-Topic: Distributed Resource Directory Thread-Index: AQHTwCursRFt48kExECRIG6tDKVaQw== Date: Tue, 20 Mar 2018 09:13:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.128.199] Content-Type: multipart/signed; boundary="Apple-Mail=_6BEB01E9-9027-40A4-B01F-941773367E26"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7ge7qCxuiDFY8MrbY93Y9swOjx5Il P5kCGKO4bFJSczLLUov07RK4MhqOP2Aq2ONTse2cXgPjU+cuRk4OCQETidffZrJ0MXJxCAkc ZpRo6X7ODpIQEljCKLFyajaIzSbgLPHpWSNYXETATGLLrq+sILawgLrEwtmfoeI6Eu9Wr4Cy 9STWH5kNZrMIqEpsWXGHBcTmFbCXuNB9kxnEZhQQk/h+ag0TiM0sIC5x68l8JoiDRCQeXjzN BmGLSrx8/I8VwlaS2LL/CzvIocwCUxgl7t2aywgxVFDi5MwnLBMYBWchmTULWd0sJHUQRUkS h+69Z4awtSWWLXwNZWtK7O9ezoIpriHR+W0iK4RtKvH66EdGCNtaYsavg2wQtqLElO6H7AsY uVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbXwS2/VXcwXn7jeIhRgINRiYf305kNUUKs iWXFlbmHGFWA5jzasPoCoxRLXn5eqpIIr3o0UJo3JbGyKrUoP76oNCe1+BCjNAeLkjjvHOH2 KCGB9MSS1OzU1ILUIpgsEwenVAOjR/B7bfbOgkdaYStPLVKbY3Ds7vff5d9nnN7y+IycUL36 4tOe27Ueq8rWX/kSnL9Xbb1TnIjfF5f1v19wtt9vmlRyWuHI5fLDVdMu/BVmemqys91cqrmZ MX0n75Giul3C7MtPTV11mTmHOXTmUrUa9cOf00/p8TAKXnxxNODQxaxd0fM3PebrV2Ipzkg0 1GIuKk4EAEnQofe2AgAA Archived-At: Subject: [core] Distributed Resource Directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 09:13:20 -0000 --Apple-Mail=_6BEB01E9-9027-40A4-B01F-941773367E26 Content-Type: multipart/alternative; boundary="Apple-Mail=_527FFDBA-2F30-490D-A58F-06332C6FDE60" --Apple-Mail=_527FFDBA-2F30-490D-A58F-06332C6FDE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, In the context of draft-amsuess-core-rd-replication-01 I did a = resubmission of a similar -yet old- work on a distributed RD. The high level view is that of recreating the registration and lookup = functions of RD within a DHT for scalability. Registration Lookup | | +----+ CoAP | +---+ +----+ | HTTP +--------+ | EP |----- | | P |-----| HP | | -----| Client | +----+ | +---+ +----+ | +--------+ +----+ CoAP | | | | | EP |----- | ---- | DRD | ---- | +----+ | | | | +----+ CoAP | +---+ +---+ | CoAP +--------+ | EP |----- | | P |-----| P | | -----| Client | +----+ | +---+ +---+ | +--------+ https://tools.ietf.org/html/draft-jimenez-t2trg-drd-00 = Ciao! - - Jaime Jim=C3=A9nez --Apple-Mail=_527FFDBA-2F30-490D-A58F-06332C6FDE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

    In = the context of draft-amsuess-core-rd-replication-01 I did a = resubmission of a similar -yet old- work on a distributed RD.
    The high level view is that of recreating the registration = and lookup functions of RD within a DHT for scalability.

              Registration             =
   Lookup
               |                         |
   +----+ CoAP |     +---+     +----+    | HTTP +--------+
   | EP |----- |     | P |-----| HP |    | -----| Client |
   +----+      |     +---+     +----+    |      +--------+
   +----+ CoAP |       |         |       |
   | EP |----- | ----  |   DRD   |  ---- |
   +----+      |       |         |       |
   +----+ CoAP |     +---+     +---+     | CoAP +--------+
   | EP |----- |     | P |-----| P |     | -----| Client |
   +----+      |     +---+     +---+     |      +--------+

    https://tools.ietf.org/html/draft-jimenez-t2trg-drd-00

    Ciao!
    - - Jaime Jim=C3=A9nez

    = --Apple-Mail=_527FFDBA-2F30-490D-A58F-06332C6FDE60-- --Apple-Mail=_6BEB01E9-9027-40A4-B01F-941773367E26 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDMyMDA5MTMxMlowIwYJKoZIhvcNAQkEMRYEFBI6iGfgS/YWc/VRVt70HQGgQsSg MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEANv73cLqy+jUWJOHR/eftkV7qQV5l8HmQgfHTRq0C77IDterOVhMFgiP1rfZeM3A2 u2kDTW/glr4XeFaSE4Gcg9wZiGnZqEm4qF7yu1MciySAD2cV83Xn3H6OQef7+u1BC0NpNSDAxis7 8/qxMrqWd6niukvsvKvfy1o+qQuH7y1/9t/8ZthoHdID2VAiY5gae+jgUi13O/br2kGXtARQ1rlo VpfhSWRGWkUBm7sPK6ArOCNTiEoidD6kZRGHrrdulZgio9jBcFzinlfyqCXMA8cbAT72GI/pHgAJ gKunmT/0xk8jEQ0z0jYNpKVzxYyWOIB8rbaWJU3bbC+WoobngwAAAAAAAA== --Apple-Mail=_6BEB01E9-9027-40A4-B01F-941773367E26-- From nobody Tue Mar 20 02:41:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA181242F7 for ; Tue, 20 Mar 2018 02:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SJi59XFT; dkim=pass (1024-bit key) header.d=ericsson.com header.b=BqNeyP52 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 lrHy537STJ1X for ; Tue, 20 Mar 2018 02:41:04 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8DAF61200F1 for ; Tue, 20 Mar 2018 02:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521538862; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ygf+KTCuTNo6GPGmVE2WWvG6d5tXAImfIb8zfPnQBRQ=; b=SJi59XFTiCULEho6E6azmFW3TFUmPHRre0ykJs46Q+B6MoTqmdH3AqIml2dI5Lex AosK+9Eb3+t8C2r+5TTSZfumY/XwAQsqCAUQjrg8+y+yWOWkA1fAnC04xgATHAUm 7LqzfSeDvX74gzLKVBYaDuN7e/6qeirjP3xJjpF/JnI=; X-AuditID: c1b4fb3a-e26ef9c000003647-47-5ab0d72ef937 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3D.6B.13895.E27D0BA5; Tue, 20 Mar 2018 10:41:02 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSHC021.ericsson.se (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 20 Mar 2018 10:41:01 +0100 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Tue, 20 Mar 2018 10:41:02 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Tue, 20 Mar 2018 10:41:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ygf+KTCuTNo6GPGmVE2WWvG6d5tXAImfIb8zfPnQBRQ=; b=BqNeyP52XxioPKs3hbaMHkhvmZ04s/QwEz550ESK6UWoz3Bf5cdjO3eL7RtzSgao20JyZpfoX2jmA8sy9otJODW+hEvYpjTaRXQb/Os2keQH8+dT6XlUASSOldRuUhz5TLRz6KmAajsqhV1xcHf8GEn72sv4z3EAyzzf/KwdPNI= Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com (10.167.189.149) by HE1PR0701MB2091.eurprd07.prod.outlook.com (10.168.35.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.6; Tue, 20 Mar 2018 09:41:00 +0000 Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::7d80:1860:283c:5ef2]) by HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::7d80:1860:283c:5ef2%3]) with mapi id 15.20.0609.009; Tue, 20 Mar 2018 09:41:00 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-core-coap-actuators-05.txt Thread-Index: AQHTwC4XQeBONYcpGUuIDlxARO38WqPY71oA Date: Tue, 20 Mar 2018 09:41:00 +0000 Message-ID: <199FF2C1-5493-4972-9DC9-8EA3DDB3F7D1@ericsson.com> References: <152153820054.9784.5166596956143552571.idtracker@ietfa.amsl.com> In-Reply-To: <152153820054.9784.5166596956143552571.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-originating-ip: [2001:67c:370:1998:345a:5971:e09e:9ae3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2091; 7:ynzoFAiFb/MQzqFlWXv1eBGIjKrOwVjWApbE6/0cx5QABHwA9VeoVa6L8uJrWWgnGatPAswpc1UDxDHcsdtOjSoQDlP978CMaHRhJPcf6dzmOUaTWA7TzakKb50MAw0i00UjOfiBvjWl5EJxcLGu31FI4ZacYvVGfGWAFA9hx7tbt1Nnfmv1EYovYqjITP+qfZ4TKBBRvzsygI5VoKoWw9yInQCZ4ZDYnPP0LOq0Ya8AdAJqpApVEqZ3cMzv1+HK x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 21226fca-5b27-456d-69ed-08d58e46b085 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2091; x-ms-traffictypediagnostic: HE1PR0701MB2091: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231221)(944501309)(52105095)(3002001)(93006095)(93001095)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0701MB2091; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2091; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(376002)(396003)(346002)(377424004)(189003)(199004)(3660700001)(2906002)(2501003)(7736002)(5250100002)(3280700002)(305945005)(2950100002)(6916009)(6116002)(97736004)(83716003)(99286004)(58126008)(76176011)(2900100001)(6486002)(36756003)(8936002)(59450400001)(1730700003)(81156014)(966005)(2351001)(316002)(5660300001)(5640700003)(6346003)(6436002)(8676002)(105586002)(6306002)(6512007)(6506007)(25786009)(81166006)(186003)(2473003)(33656002)(53936002)(102836004)(46003)(86362001)(68736007)(15650500001)(229853002)(14454004)(106356001)(82746002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2091; H:HE1PR0701MB2011.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-microsoft-antispam-message-info: DDNEnPbBJl3MRGOsWncVc6b4jMfYz2n1fhrGDqN2y0NpGFgxVAR19jlC40JUpJcct7Rjbcq8B2RxZZq3JVSeydpJyNwy0n3uajgClZqEhvqqR7AddC7uqg090K8m44k7tZy5Okm/Ru0SioOC422TeLlRsIz+n2aQ7m43YHZiBdh4eP3lC3Fz7sM7xfpdS3JcZJVjKvQfQsJxvabTCyQK9lxFGH3V3U2gJ6Auv1OtbQBjphfEB7/CyclRMZv+02wMOMYFImYkvdIEghjr1CmiHoGknmOqkVsCbN9DQi7u/M3LUnOwzRsmYqLdlzW/fmyq77udjKgjlwjqTegSr7Ysig== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1B26D0AAB8096C4E8F9F48026C095B70@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 21226fca-5b27-456d-69ed-08d58e46b085 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 09:41:00.1619 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2091 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85c8fR4m1u+bRKcBKp6NQlaPfLh/CDVkKWbB905fFC6uwc Hc4vjfSDKNLFSyqpM5Rais5ctmyFm4amC+2GJfQhFPOClZcSKaUdj0Hffu///3/+PA+8NCkr ESnprNx8hs3VZ6t8JFRd8pPEcPW4TRs54AiLfbHQSZ5AcS0ta8Q5pJUcSWOys4wMG3EsVZJp vf6JzLutLLSVjJJm5NxVhnxpwNHw7d0GybMM9yMonzwgsB3B/IisDEm8vIpg7qOLEIxWAsY8 Ot6g8BIBjdWdIiFVQ8Dj/u+U8JhGsDjYLuZHfHAkNDjNPjzLcRB0e+YRz344Cey1Q4SgX4Di WadYYA2sz5VuMoX3wUrXgneWpqX4OPzpKhK2iIfGRTvFsy9OgNa77s04wjthdbh9s5LE/jAx 1UQIZ2JocY6SAitgdnJDxLMCq6F4aVzM1wM+CBUTIUJkL7xtKkf8KYB7CJjpmxQJRjj8qK7e 6kmAgZFuSuBhBB9KtjJhsFbVsaUbYHz+81Y+Hm703hMLpVYSZm51kTeRpv6/Xeu9e5A4BDp7 IwQ5DuwNfZTAgVBV/kXMsxTvgFd1U5QFiR4iBcdwXE6GRqNm2KzLHGfIVecy+Y+Q92+47L8P OZDr60k3wjRSbZOuvLZpZSK9kTPluBHQpEou3a/zStI0vamIYQ0pbEE2w7nRbppS+UtPpcdq ZThDn89cYZg8hv3nErSv0owKY5LOWpqk7oVfIefXMwvbqivuv08L0j09PXbGbr8YXOAXXftz j06VohwsnZIHKkwDkg3jnUjH1TeV/siS7EjyPDCNewLULlCbyznbrGW5p+aZYYhqXt5ubal8 zuab5dlSY/DLaeulmPQGj588gO2XWQ4nNocejbqWmt7RpqK4TH1UKMly+r/NBlguFwMAAA== Archived-At: Subject: [core] FW: New Version Notification for draft-mattsson-core-coap-actuators-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 09:41:06 -0000 SGksDQoNCk5vdyB3aGVuIHdlIGhhdmUgc2V2ZXJhbCBzb2x1dGlvbiBkcmFmdHMgcmVmZXJyaW5n IHRvIGRyYWZ0LW1hdHRzc29uLWNvcmUtY29hcC1hY3R1YXRvcnMgSSB0aGluayBpdCBpcyBpbXBv cnRhbnQgdGhhdCB0aGUgZG9jdW1lbnQgaXMgdXAgdG8gZGF0ZSBhbmQgdG9vayBzb21lIHRpbWUg dG8gdXBkYXRlIGl0Lg0KDQoNCi0gQWRkZWQgYSBzdW1tYXJ5IChjb25jbHVzaW9uKSBpbiB0aGUg aW50cm9kdWN0aW9uICBvbiBwcm9wZXJ0aWVzIChkYXRhLXRvLWRhdGEgYmluZGluZywgZGF0YS10 by1zcGFjZSBiaW5kaW5nLCBkYXRhLXRvLXRpbWUgYmluZGluZykgdGhhdCBvZnRlbiBhcmUgcmVx dWlyZWQgaW4gSW9UIHNldHRpbmdzLg0KLSBBZGRlZCByZWZlcmVuY2VzIHRvIHRoZSBzb2x1dGlv biBkcmFmdHMgaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWcgYW5kIGxpdS1jb3JlLWNvYXAtZGVs YXktYXR0YWNrcw0KLSBVcGRhdGVkIHNvbWUgb2YgdGhlIHRleHQgdG8gYWxpZ24gd2l0aCBpZXRm LWNvcmUtZWNoby1yZXF1ZXN0LXRhZyBhbmQgbGl1LWNvcmUtY29hcC1kZWxheS1hdHRhY2tzDQot IE1hbnkgZWRpdG9yaWFscw0KDQpDaGVlcnMsDQpKb2huDQoNCu+7v09uIDIwMTgtMDMtMjAsIDA5 OjMwLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PiB3cm90ZToNCg0KICAgIA0KICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXR0c3Nv bi1jb3JlLWNvYXAtYWN0dWF0b3JzLTA1LnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgSm9obiBNYXR0c3NvbiBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVw b3NpdG9yeS4NCiAgICANCiAgICBOYW1lOgkJZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWFjdHVh dG9ycw0KICAgIFJldmlzaW9uOgkwNQ0KICAgIFRpdGxlOgkJQ29udHJvbGxpbmcgQWN0dWF0b3Jz IHdpdGggQ29BUA0KICAgIERvY3VtZW50IGRhdGU6CTIwMTgtMDMtMTkNCiAgICBHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOgkJMTgNCiAgICBVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hdHRzc29uLWNvcmUt Y29hcC1hY3R1YXRvcnMtMDUudHh0DQogICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hdHRzc29uLWNvcmUtY29hcC1hY3R1YXRvcnMvDQog ICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0 c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3JzLTA1DQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWFj dHVhdG9ycw0KICAgIERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWFjdHVhdG9ycy0wNQ0KICAgIA0KICAgIEFi c3RyYWN0Og0KICAgICAgIEJlaW5nIGFibGUgdG8gdHJ1c3QgaW5mb3JtYXRpb24gZnJvbSBzZW5z b3JzIGFuZCB0byBzZWN1cmVseSBjb250cm9sDQogICAgICAgYWN0dWF0b3JzIGFyZSBlc3NlbnRp YWwgaW4gYSB3b3JsZCBvZiBjb25uZWN0ZWQgYW5kIG5ldHdvcmtpbmcgdGhpbmdzDQogICAgICAg aW50ZXJhY3Rpbmcgd2l0aCB0aGUgcGh5c2ljYWwgd29ybGQuICBJbiB0aGlzIG1lbW8gd2Ugc2hv dyB0aGF0IGp1c3QNCiAgICAgICB1c2luZyBDT0FQIHdpdGggYSBzZWN1cml0eSBwcm90b2NvbCBs aWtlIERUTFMsIFRMUywgb3IgT1NDT1JFIGlzIG5vdA0KICAgICAgIGVub3VnaC4gIFdlIGRlc2Ny aWJlIHNldmVyYWwgc2VyaW91cyBhdHRhY2tzIGFueSBvbi1wYXRoIGF0dGFja2VyIGNhbg0KICAg ICAgIGRvLCBhbmQgZGlzY3Vzc2VzIHRvdWdoZXIgcmVxdWlyZW1lbnRzIGFuZCBtZWNoYW5pc21z IHRvIG1pdGlnYXRlIHRoZQ0KICAgICAgIGF0dGFja3MuICBXaGlsZSB0aGlzIGRvY3VtZW50IGlz IGZvY3VzZWQgb24gYWN0dWF0b3JzLCBzb21lIG9mIHRoZQ0KICAgICAgIGF0dGFja3MgYXBwbHkg ZXF1YWxseSB3ZWxsIHRvIHNlbnNvcnMuDQogICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KICAgIA0KICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgDQogICAgDQoNCg== From nobody Tue Mar 20 07:27:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2A412EB05 for ; Tue, 20 Mar 2018 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Zr88MFbmDb7e for ; Tue, 20 Mar 2018 07:27:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 86B5B12D879 for ; Tue, 20 Mar 2018 07:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521556036; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=G72Hh386K4MAmRTAjlhIV8+jGgDPR5I/TgDXas/b0B0=; b=BvCT93NehfVolYt3STVCt2BDccCgFRNwn4PFrY/JtwqVEFODjgG6qqSfeJv6oWFF QNjrhzkyB/MWi3kSDRxlA09h5QTPHkOqWju1f8FeQkaVb7TUpP0vivxi43EOYyrN J5SH1/2Wdyvpzt8gElerElYDjjM308Y3jet2/8+AEfE=; X-AuditID: c1b4fb2d-4b1ff70000005540-7b-5ab11a449922 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.7C.21824.44A11BA5; Tue, 20 Mar 2018 15:27:16 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 15:27:16 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Jim Schaad CC: core , "draft-ietf-core-coap-pubsub@ietf.org" Thread-Topic: PubSub - Questions round 1 Thread-Index: AdMtDUO/Se0FaC9oQ8e7prarOw47xiSolvAAABrPB4AADRNlgA== Date: Tue, 20 Mar 2018 14:27:15 +0000 Message-ID: <3AFC9256-260C-42EC-9BA2-CE73B69A21C9@ericsson.com> References: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> <03dd01d3c023$403bb700$c0b32500$@augustcellars.com> In-Reply-To: <03dd01d3c023$403bb700$c0b32500$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.128.200] Content-Type: text/plain; charset="utf-8" Content-ID: <4E760311C8A4B0499BA11669F7765DE5@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7ma6L1MYog6k7zSz2vV3PbPHs6VFm i9XTv7M5MHtsnDOdzWPJkp9MAUxRXDYpqTmZZalF+nYJXBmzu+8zFpwTrvhwaipzA2OPcBcj B4eEgInE4emCXYxcHEIChxklXm6fwgrhLGGUmHH5NpDDycEmYCvxpHUfmC0ioC6xdfVNJhCb WSBT4tHvYywgtjBQ/MjdO6wgQ0UENCQu75GEKHeSWLXpF1gJi4CqxK01DWBjeAXsJSbcuc8O YgsJrGaU+NQhB2JzCjhITJn1ghnEZhQQk/h+ag3UKnGJW0/mg9kSAgISS/acZ4awRSVePv7H CmErSSy6sJ4d5ARmAU2J9bv0IVqtJbYe/wo1RlFiSvdDdogTBCVOznzCMoFRbBaSDbMQumch 6Z6FpHsWku4FjKyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQJj6+CW37o7GFe/djzEKMDB qMTD+1VgY5QQa2JZcWXuIUYJDmYlEV716A1RQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJG CQmkJ5akZqemFqQWwWSZODilGhjX139bP+WXaN+d5E0fr81OUMicO2/lltneLG3+S8LLE+U4 px+arvNfoe5j0iXb2fMSlmcxzfWzlb+61tfjSuzVC383aNnfd1PcciElUde/LOtpQGry1jln bk1fqOVbXvr+zSnHjbub5/yXV56Vr1Ht9dr2WOu8nwc5wv8cWL63+PqSjZ/PhJxoVWIpzkg0 1GIuKk4EADFM+wGpAgAA Archived-At: Subject: Re: [core] PubSub - Questions round 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 14:27:31 -0000 SGkgSmltLA0KDQo+IE9uIDIwIE1hciAyMDE4LCBhdCA4LjEyLCBKaW0gU2NoYWFkIDxpZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCj4+IEZyb206IEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFu ZW5AZXJpY3Nzb24uY29tPg0KPj4gU2VudDogTW9uZGF5LCBNYXJjaCAxOSwgMjAxOCA3OjI1IFBN DQo+Pj4gT24gMTQgU2VwIDIwMTcsIGF0IDcuMTAsIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2Vs bGFycy5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IDEgIEkgYW0gbm90IGNsZWFyIHdoYXQgdGhlIHZp c2liaWxpdHkgb2YgdGhlIGludGVybWVkaWF0ZSBzdWJ0b3BpYw0KPj4+IG5vdGVzIHNob3VsZCBi ZS4gIFNob3VsZCB0aGVzZSBub2RlcyBhcHBlYXIgaW4gdGhlIGxpbmsgbGlzdCB3aGVuDQo+Pj4g ZG9pbmcgYSBHRVQgb24gdGhlIHJvb3Qgb2YgdGhlIHB1Yi1zdWIgdHJlZT8gIFNob3VsZCB0aGVz ZSBub2Rlcw0KPj4+IGFwcGVhciB3aGVuIGRvaW5nIGEgZGlzY292ZXJ5IG9uIC8ud2VsbC1rbm93 bi9jb3JlPw0KPj4gDQo+PiBJIHRoaW5rIHRoZSBleHBsaWNpdGx5IGNyZWF0ZWQgdG9waWNzIHNo b3VsZCBiZSB2aXNpYmxlIGluIGRpc2NvdmVyeS4NCj4gSG93ZXZlciwNCj4+IHRoaXMgaW5jbHVk ZXMgdGhlICJtYWluIHRvcGljcyIgY3JlYXRlZCB3aXRoIENSRUFURSBpbnRlcmZhY2UuIFBlcmhh cHMgdGhlDQo+PiBzdWItdG9waWNzIHVuZGVyIGEgbWFpbiB0b3BpYyBjb3VsZCBiZSBoaWRkZW4g ZnJvbSB0aGUgcm9vdCBkaXNjb3ZlcnkNCj4gc2luY2UNCj4+IHRoZXkgY2FuIGJlIGRpc2NvdmVy ZWQgZnJvbSB0aGUgbWFpbiB0b3BpYy4NCj4+IA0KPj4gQnV0IHdvdWxkIGJlIGdyZWF0IHRvIGhl YXIgbW9yZSBvcGluaW9ucyBvbiB0aGlzLg0KPiANCj4gTm8sIHRoYXQgaXMgbm90IHdoYXQgSSBh c2tlZC4gIElmIEkgZG8gYSBjcmVhdGUgb2YgdGhlIHRvcGljDQo+IA0KPiAvUHViU3ViL0hpZGRl bi9NeVRvcGljDQo+IA0KPiBIaWRkZW4gaGFzIG5vdCB5ZXQgYmUgY3JlYXRlZCBhcyBhIHRvcGlj IHNvIGl0IHdpbGwgYmUgaW1wbGljaXRseSBjcmVhdGVkLg0KPiBXaGVuIEkgZG8gdGhlIEdFVCwg SSBleHBlY3QgdGhhdCBNeVRvcGljIHdvdWxkIGJlIHZpc2libGUgYXMgcGFydCBvZiB0aGUNCj4g bGluayBsaXN0IGJ1dCBJIGFtIG5vdCBjbGVhciB0aGF0IEhpZGRlbiB3b3VsZCBiZSByZXR1cm5l ZCBpbiB0aGUgbGluayBsaXN0DQo+IGJlY2F1c2Ugbm9ib2R5IGV4cGxpY2l0bHkgY3JlYXRlZCBp dC4NCg0KWWVzLCAiSGlkZGVuIiBwYXJ0IHdvdWxkIG5vdCBiZSBldmVyIHZpc2libGUgYWxvbmUs IG9ubHkgYXMgcGFydCBvZiB0aGUgZnVsbCAiL1B1YlN1Yi9IaWRkZW4vTXlUb3BpYyIgdG9waWMu DQoNClRoZSAiaW1wbGljaXRseSBjcmVhdGVkIiBIaWRkZW4gdG9waWMgaXMgbm90IGFjdHVhbGx5 IGEgc3RhbmQtYWxvbmUgdG9waWMgYXQgYWxsLiBZb3UgY2FuIGNyZWF0ZSBzdGFuZC1hbG9uZSAi cGFyZW50IiB0b3BpY3MgdXNpbmcgdGhlIGxpbmsgZm9ybWF0IGN0LiANCg0KSSBzdGFydGVkIHll c3RlcmRheSB0byB3cml0ZSBhIFBSIG9uIHRoaXMgdG9waWM6DQpodHRwczovL2dpdGh1Yi5jb20v Y29yZS13Zy9wdWJzdWIvcHVsbC8yMy9maWxlcw0KDQpBbHNvIHJlbGF0ZWQgZWRpdG9yaWFsIGZp eGVzOg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvcHVic3ViL3B1bGwvMjAvZmlsZXMNCg0K Q29tbWVudHMgdmVyeSB3ZWxjb21lIQ0KDQoNCkNoZWVycywNCkFyaQ0KDQpbY2xpcHBlZCB0d28g b3RoZXIgcXVlc3Rpb25zIHRoYXQgYXJlIHdhaXRpbmcgZm9yIGFuc3dlciBmcm9tIHNvbWVvbmUg ZWxzZV0NCg0K From nobody Tue Mar 20 08:05:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB4C12704A for ; Tue, 20 Mar 2018 08:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 xCMUVXgrPNx1 for ; Tue, 20 Mar 2018 08:05:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 D8A57126D74 for ; Tue, 20 Mar 2018 08:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521558308; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Izk3Qx8JVJ4fxyGFvbp74XGOvvJ9t2LcR7dmk8N6KAg=; b=enXdjkJfPtoxUWz6O+SmSGgtUZzUmblHjrnx11tV6cpQZIqx5C77BdeNW2xwmfej fy6cjJKTWE7jTH7QR3oNgAun07xp+KuWRVZ90jGMk3/U1RGwcyAwb1920+JGos0b I+nFb/wlVNh5OFZ1NKBFfTv1jLSKuFkkdeSMS8y/xEY=; X-AuditID: c1b4fb2d-499ff70000005540-33-5ab123232cc7 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.E6.21824.32321BA5; Tue, 20 Mar 2018 16:05:08 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.151]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 16:05:07 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG (core@ietf.org)" Thread-Topic: WGA of draft-keranen-core-too-many-reqs Thread-Index: AQHTwFzUUXD1pdlpk0CpmQeBCea5Yw== Date: Tue, 20 Mar 2018 15:05:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.128.199] Content-Type: multipart/signed; boundary="Apple-Mail=_B123E72D-7DED-49B1-A407-7A4046F1FA82"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7tK6K8sYog75+Zot9b9czOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+PxySwFcx0rzu+/wdTAeNa2i5GTQ0LARKKpZTpzFyMXh5DA YUaJf1sXMkI4SxglOqe+ZAKpYhNwlvj0rJEdxBYRMJPYsusrK4gtLGAgcfb2Cqi4qcS/eyeh bD2JBxtesYHYLAKqEs0f9zKD2LwC9hJtx1vBehkFxCS+n1oDNp9ZQFzi1pP5TBAXiUg8vHia DcIWlXj5+B8rhK0ksWX/F3aQ45gFpjBKPF10mwliqKDEyZlPWCYwCs5CMmsWsrpZSOogipIk Gh4cZoSwtSWWLXzNDGFrSuzvXs6CKa4h0fltIiuEbSrx+uhHqF5riRm/DrJB2IoSU7ofsi9g 5F7FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhhB7f81t3BuPq14yFGAQ5GJR7eTMWNUUKs iWXFlbmHGFWA5jzasPoCoxRLXn5eqpIIb6YCUJo3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/e KCGB9MSS1OzU1ILUIpgsEwenVANjwaqeuo9nfdnitLgONXao8db0NHSoPN/UdELr+OmWa463 jhe/P5K8OsJpXn238CK7WRb/ksrn370p9LtV0MZWZtdGnx/LahK4j0a7zqiX+p4Y5W++VSJB LHKtqcT6ltXy74paHCK2Xp53I9oio0E3VEbWb+v8YwdfuDpqsO/jZ95xduPN6Y+VWIozEg21 mIuKEwGyx3nbuAIAAA== Archived-At: Subject: [core] WGA of draft-keranen-core-too-many-reqs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 15:05:12 -0000 --Apple-Mail=_B123E72D-7DED-49B1-A407-7A4046F1FA82 Content-Type: multipart/alternative; boundary="Apple-Mail=_0DB0AB03-847C-4228-AEB0-5F1E95819B1E" --Apple-Mail=_0DB0AB03-847C-4228-AEB0-5F1E95819B1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear CoRE, yesterday we had the presentation of the = https://tools.ietf.org/html/draft-keranen-core-too-many-reqs-00 draft, = which registers the =E2=80=9C4.29=E2=80=9D error code when =E2=80=9Ctoo = many requests=E2=80=9D are sent. While there was in-room consensus that = this document is needed the chairs would like to take it to the list for = further comments before working group adoption.=20 Thanks, - - Jaime Jim=C3=A9nez --Apple-Mail=_0DB0AB03-847C-4228-AEB0-5F1E95819B1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = CoRE,

    yesterday we = had the presentation of the https://tools.ietf.org/html/draft-keranen-core-too-many-reqs-00= draft, which registers the =E2=80=9C4.29=E2=80=9D error code when = =E2=80=9Ctoo many requests=E2=80=9D are sent. While there was in-room = consensus that this document is needed the chairs would like to take it = to the list for further comments before working group = adoption. 

    Thanks,
    - - Jaime Jim=C3=A9nez

    = --Apple-Mail=_0DB0AB03-847C-4228-AEB0-5F1E95819B1E-- --Apple-Mail=_B123E72D-7DED-49B1-A407-7A4046F1FA82 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDMyMDE1MDUwNlowIwYJKoZIhvcNAQkEMRYEFMzAixd3gBU9ERH5pO7WXeGeUYSK MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAa+A36WzniYKOGYmP+yC3W4McmItBugzfaZ3Mo6+4OnfWe2x1YrdhfUWTtjXoGS30 1PiHCQGNycwd3/K4J+F2ptR+DyEzoxmAL+TCIXnFQBgmKqHoI+YgDoAD5lABHn9v0CawbBGvyKG2 MTpIU4wVNqWrF7M4YbTmcRyNFgkYzfiPDgnnbRZp+Mn+aT15HQd4YYMIaxBC3svUfEuwUWI5XdQF +tn32czPJyqUkQVYq4FRtYSYH5lv6htFmLJQMuatAqm9pN/d7oy4xqYOA+/PTf2IgR35p8cOIaBD cQA+D+rX/Y5ZsLVL6/dcflGKulXOyp7vB5eGB78WoeamK2IMlwAAAAAAAA== --Apple-Mail=_B123E72D-7DED-49B1-A407-7A4046F1FA82-- From nobody Tue Mar 20 08:17:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6451F12704A for ; Tue, 20 Mar 2018 08:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 qovUh0v6iU_Q for ; Tue, 20 Mar 2018 08:17:14 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 76A13126D74 for ; Tue, 20 Mar 2018 08:17:14 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id o8so2091113wra.1 for ; Tue, 20 Mar 2018 08:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KfMjNzZrUjauSStiCm6G+s581a4rF/+sRf8Df4SLdEI=; b=WHgMAu8558po8wGAtwREzBl2Lj8QiSr/zHMzm/SVSYhmAiGyNb+tDAGmClUSyMAzfL rKMi42UsbdylU2pQw7BhQqvNIe3vWqXf4CPzJv0QLwLRvDgb0XPVTvBPJadWVkKx9rzp JiznUJiyBDImaj5u5F2QcW8RnrUkF8Dasz9pT8GVqI6wKi+YUjnNjaAzhTeGqez+OYxA CSQ7rosOcvkwTtMlR1QTxFVv7EaHP+j1AtY70PQjIsIhhSpbp+vBXfeSCqwK2225t3vh wme31pV/0ROKuIc6Kkqyla+ViYmU23ybrDKWHlLdAxLR+US9D8LepC5xSRgfp1EBBxL2 Rzlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KfMjNzZrUjauSStiCm6G+s581a4rF/+sRf8Df4SLdEI=; b=tlG/cEtgFBKh3FA9uxALlj8sDgSqno/fnGAyX1M80Yng/rUOdUgjigljwbCsYp8Pyo 9xsUYJbcyjD5xDLNrEZ/1BCesJTZGM24SJcNYJcijFtcoyls+TI/MXao67P4u0IPssFi T6rh4HXYLE8HEmsRAGOyTNy/z6fgDT9TGPn9tvPgaSngIPR5BzVQgAsgAi7LZszLqg4J oKkIiKUg0TBzrLoqnJEKaVomlvcZfYjM43tpIU8Gy8ZsqqzSSRo5+U2UPWWTfCFpyTv2 BUuir2sd6+hMdknM+I4s5ZIFdh4K26o5Nt3g8I0OskoodtimIzAahEErVD+2LHmNT26j toFw== X-Gm-Message-State: AElRT7HuVpbk2/f0vC8jEA7fwi/d843zHpKkljDjDM6SMSVjfFORHXrv r1sahbvZJHxVk6Jm74Vi2AcAb+VvhOXVLEcOVA0= X-Google-Smtp-Source: AG47ELt6uADMae0wHtS+3cbReGmF6hfxtgoaJqmABowlPPBNqWiXx6HzkDOh2AelWA0iKD/tqdSsVhoRBelaB6OsRiY= X-Received: by 10.223.139.144 with SMTP id o16mr12959542wra.279.1521559033045; Tue, 20 Mar 2018 08:17:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Padmakumar Subramani Date: Tue, 20 Mar 2018 15:17:02 +0000 Message-ID: To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="f403045ea466ab6b5c0567d991f8" Archived-At: Subject: Re: [core] WGA of draft-keranen-core-too-many-reqs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 15:17:16 -0000 --f403045ea466ab6b5c0567d991f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Tue, 20 Mar 2018 at 3:05 PM, Jaime Jim=C3=A9nez wrote: > Dear CoRE, > > yesterday we had the presentation of the > https://tools.ietf.org/html/draft-keranen-core-too-many-reqs-00 draft, > which registers the =E2=80=9C4.29=E2=80=9D error code when =E2=80=9Ctoo m= any requests=E2=80=9D are sent. > While there was in-room consensus that this document is needed the chairs > would like to take it to the list for further comments before working gro= up > adoption. > > Thanks, > - - Jaime Jim=C3=A9nez > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --f403045ea466ab6b5c0567d991f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    +1

    On Tue, = 20 Mar 2018 at 3:05 PM, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
    Dear CoRE,

    yesterday we had the presentat= ion of the https://tools.ietf.org/html/draft-keranen-cor= e-too-many-reqs-00 draft, which registers the =E2=80=9C4.29=E2=80=9D er= ror code when =E2=80=9Ctoo many requests=E2=80=9D are sent. While there was= in-room consensus that this document is needed the chairs would like to ta= ke it to the list for further comments before working group adoption.=C2=A0=

    Thanks,
    - - Jaime Jim=C3=A9nez

    _______________________________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/mailman/listinfo/core
    --f403045ea466ab6b5c0567d991f8-- From nobody Tue Mar 20 09:22:39 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF938127137 for ; Tue, 20 Mar 2018 09:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 cf90q3BncZ8S for ; Tue, 20 Mar 2018 09:22:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 25798126C0F for ; Tue, 20 Mar 2018 09:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521562954; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zyfvQfTYKynxgYEtmcuH+q7wngDa28AHyPIXPy1kuRg=; b=CF3uEny3AadgXAkwC1ImUPFhqWtcHvc4wOES4oHbYzo9Jf6ZQWRppzbdNWSYD2rL 95o5h7OjlEfs+BG710sV9oTt6pIjCou5S4eFZAZSZiz8VPZwXB8KVx07sCGzItt/ KjyCqYHloJmuyia1IwmoxE8IMQ0uf+1JVnYFDIm1lVU=; X-AuditID: c1b4fb2d-87c029c000005540-67-5ab1354ad227 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.C9.21824.A4531BA5; Tue, 20 Mar 2018 17:22:34 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 17:21:48 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: core Thread-Topic: [core] WGA of draft-keranen-core-too-many-reqs Thread-Index: AQHTwFzUUXD1pdlpk0CpmQeBCea5Y6PZPZwA Date: Tue, 20 Mar 2018 16:21:47 +0000 Message-ID: <4EEE6D91-C549-4C06-991E-09FCB87D81D5@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.128.200] Content-Type: text/plain; charset="utf-8" Content-ID: <4D1A20AA151A5B41A4993F44AEA122F8@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbHdW9fLdGOUwYqTEhb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqdt8xgLHnBWPDt6m72B8QBnFyMnh4SAicSd/Q8Zuxi5OIQE DjNKfF/ZyAbhLGGUePX3IgtIFZuArcST1n2sILaIgIRE59f97CA2s4CjRNOphUwgtrCAtcSu 2XOAbA6gGhuJebvLIMqNJHrOXgQrYRFQlbj1/iFYK6+AvcSxe+vAbCEgu2v2L7AaTgEHif/H N4KtZRQQk/h+ag0TxCpxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksSiC+vZQU5gFtCUWL9L H6LVWmLfgVPMELaixJRumBMEJU7OfMIygVFsFpINsxC6ZyHpnoWkexaS7gWMrKsYRYtTi4tz 042M9VKLMpOLi/Pz9PJSSzYxAuPn4JbfujsYV792PMQowMGoxMObqbgxSog1say4MvcQowQH s5IIb6YCUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgsEwenVANj rHn/tjMn5Y690brw5NlSJdlKsaoXE3qTVC/vsC5ibpjFGbNw8a938lwajJwmrMYuXVveTJjW Pnd+h5bUx+e/w8O2v+5j+ZLGaeDjvu3hHRZWi/VWn9SnHZu/8YnXkfASIYE3UQcLg3WvizCY FBuoZ+3hcX3/duaB29cL9/MtvqFdlTbhpssnJZbijERDLeai4kQA7BHSrpsCAAA= Archived-At: Subject: Re: [core] WGA of draft-keranen-core-too-many-reqs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 16:22:39 -0000 SGksDQoNClRoZXJlJ3MgYWxzbyB1cGRhdGVkIHZlcnNpb24gYXZhaWxhYmxlLCBzbGlnaHRseSB1 cGRhdGVkIGZyb20gdGhlIHZlcnNpb24gcHJlc2VudGVkIGluIHRoZSBDb1JFIHNlc3Npb24sIHRo YXQgYWRkcmVzc2VzIHJldmlldyBjb21tZW50cyBhbmQgdGhlIGRpc2N1c3Npb24gcG9pbnRzIGZy b20gdGhlIHNlc3Npb246DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2VyYW5l bi1jb3JlLXRvby1tYW55LXJlcXMtMDENCg0KDQpDaGVlcnMsDQpBcmkNCg0KPiBPbiAyMCBNYXIg MjAxOCwgYXQgMTUuMDUsIEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNv bT4gd3JvdGU6DQo+IA0KPiBEZWFyIENvUkUsDQo+IA0KPiB5ZXN0ZXJkYXkgd2UgaGFkIHRoZSBw cmVzZW50YXRpb24gb2YgdGhlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXJh bmVuLWNvcmUtdG9vLW1hbnktcmVxcy0wMCBkcmFmdCwgd2hpY2ggcmVnaXN0ZXJzIHRoZSDigJw0 LjI54oCdIGVycm9yIGNvZGUgd2hlbiDigJx0b28gbWFueSByZXF1ZXN0c+KAnSBhcmUgc2VudC4g V2hpbGUgdGhlcmUgd2FzIGluLXJvb20gY29uc2Vuc3VzIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBu ZWVkZWQgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHRha2UgaXQgdG8gdGhlIGxpc3QgZm9yIGZ1 cnRoZXIgY29tbWVudHMgYmVmb3JlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24uIA0KPiANCj4gVGhh bmtzLA0KPiAtIC0gSmFpbWUgSmltw6luZXoNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Tue Mar 20 09:28:28 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D66127863 for ; Tue, 20 Mar 2018 09:28:26 -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 9-knysOWTj0C for ; Tue, 20 Mar 2018 09:28:24 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 399DA127871 for ; Tue, 20 Mar 2018 09:28:23 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id p142-v6so3515331lfd.6 for ; Tue, 20 Mar 2018 09:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=p6Dc6nuTpZpqXLrdcbn2Liol/t9G5kfW9vdnkkVRf2U=; b=flqMzwga7n46dXAMbMvNwbfg7mN3vPjBwSPGCQzK+DIX3omrs4+w0nWJ2Z/dw2DVdD X9yMlLju3bmrR0T8o6r/fj7Q+d54ek1qWFQBXJ8Bv1UjqIQIGdyBL4Lji+VzzyeONH3k EyAtx5n4nTqqxAMRaBX119SjR+RluiQuyYeweV+W1MrczEJ+lbIl6XcGlH0skOivqJoT NBoUtFwnKYAp5t5FRE6Gfm0yH0kFxc/GRssScqxqEPTHEWRJ/zYb3Xs8ZqMbJModVcyt MzInpb9yxaMXrDg4UoeFUm8vmooTCd+2EjbwdItknCmA8jg9oxgRTMyBXFXLbqo5ZD1D spIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=p6Dc6nuTpZpqXLrdcbn2Liol/t9G5kfW9vdnkkVRf2U=; b=d0XQ7LslVjbXAOlIkcfjq8mcuc/iY+h4Jg8IgZYkrMrvz5zlL3YOFzQOh0I1Io2fSE YBAvKreo+kHFzaIiVMTJg5Th7Ej130tahuZd/lT+V8mnpvC3YG/ev72JCf6nUiRXxgKP VUGwQIQRzI6unA6zoG20Gj9CtfxQ1R0vw/nVzJ1bsb1O9wRqZD6/9+8ZKhMI+efv2Nxc tLuTy9FUN1APWpj/QwEfRgvfhqOSY8ZgpVfrOW5vFDQkZhd3mPgExCxKgCRSRVsg70A5 BPB8VTfY0GfGGxhl+46ha4Gk74+mTS8RRoQmTnSPz2FnAGxhIZwWAbpq1+4wwMzspkie oxpA== X-Gm-Message-State: AElRT7G2lV21otaiJ25pRoMxIAzc9MwTcSoVpfvUMpyDToLLrwX6mr0h XQ/PE2JnjVH74kxlJ7D5uHAK8aiArYcbjzwcF9wZDg== X-Google-Smtp-Source: AG47ELu4liemfIWuuEZZ780YFNTXVGumgAXJ+jXU858fwmImeTbNmhgRDV4kRDMUydiHsv+WYPzfbobsQrGPRnXrKso= X-Received: by 10.46.108.3 with SMTP id h3mr5265803ljc.123.1521563301362; Tue, 20 Mar 2018 09:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d0cf:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 09:28:20 -0700 (PDT) In-Reply-To: <4EEE6D91-C549-4C06-991E-09FCB87D81D5@ericsson.com> References: <4EEE6D91-C549-4C06-991E-09FCB87D81D5@ericsson.com> From: JinHyeock Choi Date: Wed, 21 Mar 2018 01:28:20 +0900 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] WGA of draft-keranen-core-too-many-reqs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 16:28:27 -0000 +1 We got a request from an OCF developer for such response code. best regards JinHyeock On Wed, Mar 21, 2018 at 1:21 AM, Ari Ker=C3=A4nen wrote: > Hi, > > There's also updated version available, slightly updated from the version= presented in the CoRE session, that addresses review comments and the disc= ussion points from the session: > https://tools.ietf.org/html/draft-keranen-core-too-many-reqs-01 > > > Cheers, > Ari > >> On 20 Mar 2018, at 15.05, Jaime Jim=C3=A9nez wrote: >> >> Dear CoRE, >> >> yesterday we had the presentation of the https://tools.ietf.org/html/dra= ft-keranen-core-too-many-reqs-00 draft, which registers the =E2=80=9C4.29= =E2=80=9D error code when =E2=80=9Ctoo many requests=E2=80=9D are sent. Whi= le there was in-room consensus that this document is needed the chairs woul= d like to take it to the list for further comments before working group ado= ption. >> >> Thanks, >> - - Jaime Jim=C3=A9nez >> >> _______________________________________________ >> 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 Tue Mar 20 16:24:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095C7120727 for ; Tue, 20 Mar 2018 16:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 M4SE_dC9m-f7 for ; Tue, 20 Mar 2018 16:24:13 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D434F1200B9 for ; Tue, 20 Mar 2018 16:24:12 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id E35284962C for ; Wed, 21 Mar 2018 00:24:10 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0916861 for ; Wed, 21 Mar 2018 00:24:10 +0100 (CET) Received: from hephaistos.amsuess.com (host217-34-38-220.in-addr.btopenworld.com [217.34.38.220]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7C2A23A for ; Wed, 21 Mar 2018 00:24:09 +0100 (CET) Received: (nullmailer pid 27027 invoked by uid 1000); Tue, 20 Mar 2018 23:24:08 -0000 Date: Tue, 20 Mar 2018 23:24:07 +0000 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20180320232407.GA18172@hephaistos.amsuess.com> References: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] PubSub - Questions round 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Mar 2018 23:24:15 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello working group, On Wed, Sep 13, 2017 at 09:10:34PM -0700, Jim Schaad wrote: > This would be rule c > of section 2.1 of RFC6690. This rule seems to have been modified for the > /.well-known/core to say only use the scheme + authority and ignore the p= ath > to the resource. However, I do not believe that this rule is suspended in > this case. This means that the return value for figure 4 would be > ";rt=3Dtemperature;ct=3D50". Do you believe that I am wro= ng? There's nothing special about .well-known/core, but Jim did discover something nasty that I did not spot before: RFC6690 link-format not only resolves the target relative to the link's Context, but also has the default Context depend on the target reference and strips any implicit base URI using the Origin concept of RFC6454; something known neither from RFC5988 nor the current RFC8288. This breaks the examples and convenient representations of core-interfaces, core-coap-pubsub, and contradicts the mental model of link-format semantics of everyone I have ever talked to about it. Unless you have an anchor, links need to be absolute or path-absolute to behave as expected. (resource-directory is largely safe because it exports absolute URIs in resource lookups due to an already known part of those issues). So when you see GET coap://host/123/456/ returning <789/abc>;rel=3Dmember,<777/569>;rel=3Ddescription it expresses links coap://hosts/ --(has member)--> coap://host/789/abc --(has member)--> coap://host/777/569 where you would have expected (also in accordance to RFC8288) coap://hosts/123/456/ --(has member)--> coap://hosts/123/456/789/abc --(has member)--> coap://hosts/123/456/789/569 . On the other hand, GET coap://host/123/999/ returning <789>;rel=3Dboundto;anchor=3D"coap://other/567/" expresses per RFC6690 coap://other/567/ --(bound to)--> coap://other/567/789 where a more intuitive interpretation would be coap://other/567/ --(bound to)--> coap://host/123/999/789 . Also, the rules make it impossible to express the respective RFC8288 links at all in a relative fashion; to make these statements, the server producing the representation needs to be aware of the host name it is queried as (and to draw the right conclusions, needs to agree with the client on this). This is prone to misunderstandings when reverse proxies are in use, and means that links that can be statically known (and thus served directly from flash) need to be needlessly assembled by constrained devices. There is no motivation for this deviation from web linking in the document. It is my impression (and please PLEASE reply if I'm wrong) that nobody has implemented those rules as they are laid out, at least not in a system that deals with links where it makes a difference. 6690 is a request for comments. My I comment that its href/anchor component is broken, and I propse that we do an RFC6690bis that redefines ct=3D40 into to be closer to RFC8288. If my impression about the state of deployment is wrong, my next best suggestion is to deprecate it in favor of something that has better defined semantics like CBOR-link-format (it does ... right?). Best regards Christian --=20 Ceterum censeo Carthaginem delendam esse. -- M. Porcius Cato --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqxmBMACgkQOY0REtOk veFPfhAAk1xgIgTevyr0MaHT+lmWBZEFyl5UXiyGCSe+7jZqOlzDYO916ro19IR0 qO4rqyGj9f7zl3jsxwpeIDpecN5dvnK5YOaXWkRD7w0rdUQmuByAQF2plt/7Wr40 hwrlsAMb4bb6v7wptKtoMqkUU6xuB+dOd8rAxnA+DGO5KSmvyzBdzo3kYl2JteSA OT7RI1M+cu870ChFBQ/FqFGvynfWavKmcLm1z+gk3LTHDURPnTE+8QMHTaguaYW8 5+VgJ6C91GWb+lb3IuRkUesSpCXdqJfuSrRyjbXNSvO3Ys6fzmv+sfmp+fiY0NyE lDC3/CJ1f88e1gMqsqUiYA7OlkvLBvDk5ntoeL41bPaFMgbckF5lFa0FY+TFVvxu Pxj1dKRG5vXMrJk30QKW0wje+C3GpXYAqFh8wbou1MJ2mcWH7Q2SF0MO107dzPdq q4ceTZjjNtrNgpV/MxhdnQROUh5PbNMD5wWihUlwFN5ppflSHoSgxx888BWsIRPX c0BUocSr3JkJ2hu/7V7RtqQjsks7I73pisAhPozka940Yx7vvcdhM1vA3wx9gNia 1oIWBsU0mP757t6uyhM3+GizYKiH1TWZM4bZ62McLnCBdiqLPpKneDByKK70FSqw DSIFr6SJpnyB/+7ByDwpFUtvqN7IQCf5ltqkZtvFw3ztdP3qBxE= =3V3+ -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From nobody Tue Mar 20 19:09:34 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F7D12D7F0 for ; Tue, 20 Mar 2018 19:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 obUKD-1Hz6QD for ; Tue, 20 Mar 2018 19:09:31 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 154A212D7E8 for ; Tue, 20 Mar 2018 19:09:31 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id j85so2199858vke.0 for ; Tue, 20 Mar 2018 19:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qW/fkdZu/zt5yTDi1SV/zBx9YRS3SPjedA/Tk4axNJA=; b=NXhEGDX93tILuc8e+WMEcKmanLxRlxcfadKzPPzi6R8b/5L5xHDdxni2bugIjtpbMT V4rvODnZOTuBTJMEhlog3dujJEXivDH6ef5Oy4J8xIRnqCXVWixeA2Ko7AbDO6XTpvf3 4JMj61MYWPiwQu6oXB+GL3RNNGLI2Yetgqd3cSrwnMxseVGQ+cMv73NsL0ANUdLnx9Vv a0r5eXfFIo4z7bpriNyPoEqAKKSAcCFOLw5Ky5pmScRcUzD1PM3OhCppY0TJxzOjI9Sg oP2NwjTFkeXpzPn9hBq13VXrZduUEgeV3jQebsucZ1bmo/H2PQfOf/rMX4QXG1YIfs2w qZfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qW/fkdZu/zt5yTDi1SV/zBx9YRS3SPjedA/Tk4axNJA=; b=QlcizIIWZSutC7GSKhH6Kti+jrGATvVkH2un9OnzH7LTk0/x9hvf8kDGSCMW3IJxXj o+/7J+Uno+K3xibL26HxCgxf3INUlr//aoeHyBwDVaFvtXMlhUYpEo1HfVsk7rX97wdv TZiqxFs3sp/qHymLviycfo8Hu0MabPZERQ43saJ5nqdeZQwbxyvhtgClxE+WExojMs9M q0JRGh62bDiE8GSDa+nn8n6n+FS8GyRcS4TPhvtrpDUnObOA70T/w8g5yXdwwkX1i6xJ mUxTuslZ6Gk+XJhGm0T9pvk4OU5QNzqoAhqE2/ntuItX4ZNZZEQSDJRB57a0sWcKMl2C 0Qwg== X-Gm-Message-State: AElRT7GoLjSg5vkQ3q4+9NoNNgl1Qo7aRcUT7b3XT6MUr8Q4nG2w3i7r UbuzxcgeXcu/h3HKh8vY7jZtdbiMIN4uAeP2FWnxmzEP X-Google-Smtp-Source: AG47ELub+KP8/GZDFgXGPDpfv2sbcp/gIqubLCseIhPmdp5QNm56CxtvIqaA8VAZYnlIQBmtUUr/SkCN9Ht4xSqQRsk= X-Received: by 10.31.196.131 with SMTP id u125mr11805526vkf.27.1521598169861; Tue, 20 Mar 2018 19:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.213 with HTTP; Tue, 20 Mar 2018 19:09:28 -0700 (PDT) In-Reply-To: References: From: Tanguy Ropitault Date: Tue, 20 Mar 2018 22:09:28 -0400 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="001a114bcfc267d33a0567e2ae5b" Archived-At: Subject: Re: [core] CoMI server implementation available for remote interop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Mar 2018 02:09:33 -0000 --001a114bcfc267d33a0567e2ae5b Content-Type: text/plain; charset="UTF-8" For those interested, you can find some details about the interoperability test we defined here: https://drive.google.com/drive/folders/1LxKdMeusLdHmJreYshwNY-XIHGz30mxh?usp=sharing More particularly: - InteropDescription: describes the interop scenario and the expected results - CoMIFiles folder: contains the YANG and SID files - AcklioToAcklio folder: pcap of Acklio's CoMI client and server executing the interop test If you have any questions/feedback, do not hesitate. Cheers, Tanguy Ropitault (Acklio) On Fri, Mar 16, 2018 at 4:54 PM, Tanguy Ropitault < tanguy.ropitault@gmail.com> wrote: > Hi, > we are pleased to announce that we have a CoMI Server implementation > available for remote interoperability testing. > > In order to ease the process, we use f-interop (go.f-interop.eu). For > those who don't know, f-interop allows to automatically manage the > interoperability process. It also facilitates the remote testing process by > creating tunnels, allowing two different implementations to interact with > only few clicks. > > I also defined a YANG interoperability file (and generated its associated > SID file). It's a very simple YANG file but I think we need to start with a > very simple one. Our implementation manages so far GET, FETCH, PUT, IPATCH > and DELETE request. > > For those interested, please-send me an email in order to discuss about > what we can do/how to use f-interop, obtain the YANG and SID file, etc. > > Cheers, > Tanguy > PS: f-interop can be used only for Linux Debian-like OS and macOS for the > time-being. > > --001a114bcfc267d33a0567e2ae5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    For those interested, you can find some details a= bout the interoperability test we defined here:

    More particularly:
    -= =C2=A0InteropDescription: describes the interop scenario and the expected r= esults
    - CoMIFiles folder: con= tains the YANG and SID files
    -= AcklioToAcklio folder: pcap of Acklio's CoMI client and server executi= ng the interop test

    =
    If you have any questions/feedback,= do not hesitate.

    Cheers,=C2=A0
    Tanguy Ropitault (Acklio)


    On Fri,= Mar 16, 2018 at 4:54 PM, Tanguy Ropitault <tanguy.ropitault@gmai= l.com> wrote:
    = Hi,
    we are pleased to announce that we have a CoMI Server implementati= on available for remote interoperability testing.

    In order t= o ease the process, we use f-interop (go.f-interop.eu). For t= hose who don't know, f-interop allows to automatically manage the inter= operability process. It also facilitates the remote testing process by crea= ting tunnels, allowing two different implementations to interact with only = few clicks.

    I also defined a YANG interoperability file (and= generated its associated SID file). It's a very simple YANG file but I= think we need to start with a very simple one. Our implementation manages = so far GET, FETCH, PUT, IPATCH and DELETE request.

    For those= interested, please-send me an email in order to discuss about what we can = do/how to use f-interop, obtain the YANG and SID file, etc.

    =
    = Cheers,
    Tanguy
    PS: f-interop can be used only for Linux Debian-li= ke OS and macOS for the time-being.


    --001a114bcfc267d33a0567e2ae5b-- From nobody Wed Mar 21 02:23:54 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AFB12D94E for ; Wed, 21 Mar 2018 02:23:52 -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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 rduRfEIqvpdJ for ; Wed, 21 Mar 2018 02:23:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AB31201F2 for ; Wed, 21 Mar 2018 02:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q0pnTroy7O6GUWxcjU13UZS3QWUQajYBo4Om6e+990M=; b=eRX4hMn/hx6NlM9m8TQXr/F5w/Bwfeq26LwNJ3bUe70izPzAF0eVPthHsSTRh/Udfy2RFHcJ/ARawgJ9eeNLTfSswhXe84SDILg2mIeN1aLObOdejUbKAJXUz+RxqNKUNWu2Y6tLowGkT0DagEXbfqXV2+WYBZRuBeWUHCoWSAA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1280.eurprd08.prod.outlook.com (10.167.197.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Wed, 21 Mar 2018 09:23:45 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d%17]) with mapi id 15.20.0588.017; Wed, 21 Mar 2018 09:23:45 +0000 From: Hannes Tschofenig To: "core@ietf.org WG" Thread-Topic: COSE Implementations Thread-Index: AdPA8FBRio7kzkUzRU+sWyKsuFzD8w== Date: Wed, 21 Mar 2018 09:23:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:128:cc50:50b9:1f3f:69d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1280; 7:zk8mUtOsMsqLREdPA+8NN5tiou1DjpAgPW3Pf2zpLA0GUFUiUb8ujH5VKFVR0FuvEBTCUlX3KH9O7GoSZexXuDEY4D4gheBugMg1fcOmsWxSnfqcI6YOCVASsD+sGhkUzbLo4clxqYgqE/RwlECALHI4hrNTUSlI38q6LJsaahGEU0d+RzN7PT97uDhrRmuE3kROKU1JTYq4EbNSjNOm/PS1BGo6ITYXhOVBwVoCh1mimC0LXTcFRe+T8rfzgub+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 660d7bb6-0e56-42e4-2f2d-08d58f0d722a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1280; x-ms-traffictypediagnostic: VI1PR0801MB1280: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231221)(944501321)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1280; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1280; x-forefront-prvs: 0618E4E7E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(376002)(39380400002)(40434004)(53754006)(199004)(189003)(6116002)(68736007)(8936002)(102836004)(105586002)(53936002)(7696005)(3660700001)(74316002)(7736002)(72206003)(33656002)(6506007)(99286004)(6306002)(54896002)(2900100001)(6916009)(9686003)(7116003)(316002)(3280700002)(186003)(5890100001)(25786009)(14454004)(97736004)(3480700004)(2906002)(55016002)(46003)(8676002)(106356001)(81156014)(478600001)(81166006)(790700001)(59450400001)(6436002)(86362001)(221733001)(5250100002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1280; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bBctulFFM3B/Z7/H9yPx8lYosJ147y0EBxCN22CV8b2OVD+gFlTcNGy7P7mOd8apZphmO4bkSrTEN/AR9ZW7tBZLstMKC+F1b6WwQWEPgg784cZV5azgwKksk5mi1nJdeH7aSDGdz1IE6qjh84D9+B02OU2dAk9aUuL59OOdCDps1geuPjpozp3woMLvT8/CAV+FGERepBphOMHJKprrUY9qSaPlQ24rkLt9MCIvwsmeFO1Y4xkNFpahcUD9JXQq058aPhWJY+VdYh+qJiATVhcK5k1vyNRAgpchwTIPDDkOwT9ArMZ6DQRAAPIvXCjIfQMiAUJY24FeTohkXQ7vLw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211208CFA8F16F35DD09762DFAAA0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 660d7bb6-0e56-42e4-2f2d-08d58f0d722a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2018 09:23:45.4257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1280 Archived-At: Subject: [core] COSE Implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Mar 2018 09:23:52 -0000 --_000_VI1PR0801MB211208CFA8F16F35DD09762DFAAA0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, At the end of the SUIT WG meeting the chairs asked whether those working (o= r interested in contributing) a COSE implementation in C with an embedded c= rypto library could step forward. Nobody showed up. This may probably be due to the overlap of the SUIT and t= he CORE meeting slots. I am wondering whether some folks here are working on an embedded COSE impl= ementation in C they are willing to share. Given that COSE is being promote= d in many drafts in CORE and in ACE I would be surprised if there is no imp= lementation work going on. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB211208CFA8F16F35DD09762DFAAA0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

    At the end of the SUIT WG meeting the chairs asked w= hether those working (or interested in contributing) a COSE implementation = in C with an embedded crypto library could step forward.

     

    Nobody showed up. This may probably be due to the ov= erlap of the SUIT and the CORE meeting slots.

     

    I am wondering whether some folks here are working o= n an embedded COSE implementation in C they are willing to share. Given tha= t COSE is being promoted in many drafts in CORE and in ACE I would be surpr= ised if there is no implementation work going on.

     

    Ciao

    Hannes

     

    IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB211208CFA8F16F35DD09762DFAAA0VI1PR0801MB2112_-- From nobody Wed Mar 21 02:37:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DE612D963 for ; Wed, 21 Mar 2018 02:37:44 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 KDgodYv2hVsu for ; Wed, 21 Mar 2018 02:37:42 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D42612D95B for ; Wed, 21 Mar 2018 02:37:42 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id A507C224183 for ; Wed, 21 Mar 2018 09:37:41 +0000 (UTC) Received: from [31.133.142.90] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 21 Mar 2018 10:37:39 +0100 To: References: From: Ludwig Seitz Message-ID: Date: Wed, 21 Mar 2018 09:37:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=N659UExz7-8A:10 a=v2DPQv5-lfwA:10 a=NEAV23lmAAAA:8 a=85MaOuo1HFLJqhqWOZIA:9 a=pILNOxqGKmIA:10 X-Virus-Scanned: clamav-milter 0.99.4 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [core] COSE Implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Mar 2018 09:37:45 -0000 On 2018-03-21 09:23, Hannes Tschofenig wrote: > Hi all, > > At the end of the SUIT WG meeting the chairs asked whether those working > (or interested in contributing) a COSE implementation in C with an > embedded crypto library could step forward. > > Nobody showed up. This may probably be due to the overlap of the SUIT > and the CORE meeting slots. > > I am wondering whether some folks here are working on an embedded COSE > implementation in C they are willing to share. Given that COSE is being > promoted in many drafts in CORE and in ACE I would be surprised if there > is no implementation work going on. > > Ciao > > Hannes Hannes, I think part of the problem is that in the embedded space people tend to implement only the parts they need and hardcode most of the moving parts to the tiny subset of options they support. You can find some code here: https://github.com/Gunzter/contiki-ng/blob/oscore_dev/os/net/app-layer/oscore/cose.c that does a limited subset of Encrypt0 /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Mar 21 04:42:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD8F126DD9 for ; Wed, 21 Mar 2018 04:42:31 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 KH8kMd2Eh3uV for ; Wed, 21 Mar 2018 04:42:30 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7639112DA27 for ; Wed, 21 Mar 2018 04:42:15 -0700 (PDT) Received: from wangari.tzi.org (dhcp-86b0.meeting.ietf.org [31.133.134.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id C204F205EA; Wed, 21 Mar 2018 12:42:13 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig Cc: "core\@ietf.org WG" References: Date: Wed, 21 Mar 2018 12:42:13 +0100 In-Reply-To: (Hannes Tschofenig's message of "Wed, 21 Mar 2018 09:23:45 +0000") Message-ID: <87in9ppsdm.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] COSE Implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Mar 2018 11:42:32 -0000 Hannes, Hannes Tschofenig writes: > I am wondering whether some folks here are working on an embedded COSE > implementation in C they are willing to share. Given that COSE is > being promoted in many drafts in CORE and in ACE I would be surprised > if there is no implementation work going on. I started an implementation for the ACE DTLS profile work but plan to extend that. Will be open-source soon (i.e., days, not months). Gr=C3=BC=C3=9Fe Olaf From nobody Thu Mar 22 07:45:05 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCC6127337 for ; Thu, 22 Mar 2018 07:45:02 -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, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-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 SEiISXMrKJyy for ; Thu, 22 Mar 2018 07:45:00 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D7E126DFB for ; Thu, 22 Mar 2018 07:44:59 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3B94949632; Thu, 22 Mar 2018 15:44:57 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E893D61; Thu, 22 Mar 2018 15:44:55 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2001:67c:370:128:d1a4:586c:a5dc:33d8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 396493A; Thu, 22 Mar 2018 15:44:55 +0100 (CET) Received: (nullmailer pid 16999 invoked by uid 1000); Thu, 22 Mar 2018 14:44:53 -0000 Date: Thu, 22 Mar 2018 14:44:53 +0000 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: <20180322144452.GA13008@hephaistos.amsuess.com> References: <20180302092637.GA10917@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20180302092637.GA10917@hephaistos.amsuess.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Mar 2018 14:45:03 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello parties interested in the RD interop, please fill out which dates would work for you for a first interop: https://doodle.com/poll/hxx6ryh4359tsvnb The times were chosen to accomodate participants from the the American west coast and Europe, let's see if we find convenient overlap. We will meet in voice chat (probably IETF's own Jitsi) and do all testing over the Internet. I've assembled a questionnaire at the end of the mail to help in setting expectations and identifying problems ahead of time, please reply off-list preferably before April 1st. A first interop that will happen as doodled with whoever is ready to do it by that time. There will not be a precise test specification for that event, we'll just try out some operations driven by the client implementor. =46rom the experience in that, we can develop a more formal test workflow and have a second interop based on that, probably around June. Best regards Christian Foreword to participant data ---------------------------- These questions are here to determine in advance whether we we will at all have implementations that can interact meaningfully. You are a perfectly good participant if you only tick one or two of the feature options. Older versions are OK too: a -00 client should be able to register with a known -13 RD and vice versa. The feature list is not a compliance check lists and implies nothing about those things being optional. Feel free to add free-form comments if you want to volunteer additional information or think I missed a point. Participant data ---------------- I implemnt RD as of draft version [ ] / as of a derived specification, in particular [ ]. In terms of roles and features, I implement...=20 [ ] an Endpoint that can do [ ] finding of the RD using [ ] a configured host name [ ] a configured IP address [ ] expicitly configured DNS-SD [ ] by receiving to a SLAAC RDAO option [ ] by falling back to a "close device" like a 6LBR [ ] by discoverying an RD using multicast [ ] simple registration [ ] do full registration [ ] execute URI discovery to find a registration resource [ ] send an explicit con or other registration parameters [ ] delete my own registration on shutdown [ ] any of the above with content formats other than link-format, in particular: [ ] [ ] an RD that can [ ] send SLAAC RDAO announcements [ ] respond to multicast requests [ ] accepts simple registrations [ ] accepts regular registrations [ ] implements lookup, in particular [ ] endpoint lookuo [ ] resource lookup [ ] group lookup [ ] accept group registrations [ ] accept registration with another formats than link-format [ ] process generic registration parameters [ ] process specific registration parameters (RD extension), in particular=20 [ ] RD-DNS-SD [ ] proprietary [ ] other: [ ] [ ] a lookup Client [ ] that can do endpoint lookups [ ] that can do resource lookups [ ] that can do group lookups [ ] that can observe lookups [ ] can deal with other formats than link-format [ ] that isn't actually a lookup client, but if you ask me to look something up during an interop, I have a client at hand to do it semi-manually [ ] a Commissioning Tool As schemes and authentication methods, I support... [ ] coap [ ] coaps [ ] coap+tcp [ ] coaps+tcp [ ] http [ ] OSCORE over any of the above I will have a route to the general internet using... [ ] IPv4 [ ] IPv6 [ ] my endpoint will have multiple addresses that are routable to the internet [ ] my endpoint will have at least one routable address that is firewalled Participant privacy: [ ] I'm OK with being publically identified by name, email address and comp= any in the course of this interop. [ ] Please anonymize my participation. --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqzwWAACgkQOY0REtOk veFvchAAmNuDhL2sh/zata1GyYIMtbampcfRG597lB8+94dpCpBxj4ZiZUAlkMU6 F4fUJeML5G12jKlfrRmC1rzkjXnnXbpZNg0kxZjeJ3jIAqqE51vtUQC3Wy5N29zK Xhq0mmh+DHnUllhU59I23Vm4Bzh3V8UeQYmnFcOQ0BhsIynnUhxVf/X2LRn+EoI7 +xJlWp6BYPLDHobAZbU9dg0tAXMdGhmHeWMG/EOS8vsU5gXzifYgTxhAT+mPRfh0 5X5mjdQzrol406Iyx3UT5t3C2E7E0EvGqW0bzCOFzhZyJ13LGoatt6sbE+CY5ew0 OFeWp4hx3b7/h2F/3kyCHl//VSEfhrO5M8cBKEfHM7bkvNud/qlJ6pB5ONf/aB5S eeQw2x8yDQxJPBWt6gvRGBrz6n63i64RiHrtVOkUINUYv2oCKvlsgZFOWhaJZ9mh T90HT+1keKgBSHfu7dfncViMQrAduh76nZ2MOgwUuFdhB8t9HQ0XmlLt+Z8aGQcs zHNFmBZo0KXdxU/iFQHxnOyY4+1KZS2QKPAy3SfcJLO8JtDotRRlc1f1daRX1GQM wHeaN3UJ+/IvIRtUJ+YwbJseCb0pEKdMGr6jEw60P053pburx8xsDxOev5hw4ZP5 3mG6EMuuz1m9+b5kYgQKzY9brGUbgnRhFr6oTzD+FoQf2PJCe9w= =ukhC -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From nobody Fri Mar 23 15:01:37 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55CA12DB70 for ; Fri, 23 Mar 2018 15:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 dhaAQ4ZygRs7 for ; Fri, 23 Mar 2018 15:01:32 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3788127077 for ; Fri, 23 Mar 2018 15:01:31 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B869C49410 for ; Fri, 23 Mar 2018 23:01:28 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 004DB61 for ; Fri, 23 Mar 2018 23:01:26 +0100 (CET) Received: from hephaistos.amsuess.com (089144216227.atnat0025.highway.a1.net [89.144.216.227]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7DDC83A for ; Fri, 23 Mar 2018 23:01:26 +0100 (CET) Received: (nullmailer pid 2726 invoked by uid 1000); Fri, 23 Mar 2018 22:01:24 -0000 Date: Fri, 23 Mar 2018 23:01:24 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Core WG mailing list Message-ID: <20180323220123.GA29610@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [core] TCP (RFC8323) interop report X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Mar 2018 22:01:35 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, there has been some testing of CoAP-over-TCP interoperability before and during IETF101. At a remote interop set up by Hannes, Szymon and I tested java-coap[1] against aiocoap[2] respectively, and achieved interoperability for regular requests (unfragmented up to around Max-Message-Size) and Block2 operations with BERT. During IETF101, Jim and I tested requests from my client to his server. We achieved interoperability for both Block1 and Block2 operations that were fragmented to BERT messages. No observation was tested. In an additional test, I ran a very quick-and-dirty Rust WASM CoAP-over-WS client over an equally ad-hoc coap+ws-to-coap+tcp "proxy" (both at [3]) against Szymon's server. The client obtained a simple small resource from the server, which is almost everything it can do so far. (It can do observe, but no such resource was available to test against). Issues we encountered and largely fixed right during those tests: * A client could not deal with initial CSMs not carrying any options. * A server did not abort when receiving malformed (TKL > 8 or unreasonable length) packages. * A server expected all Block1 exchanges to happen using the same token. * A server replied to the last Block1 request with a final successful message but using the first blocks's token. * A server did not consider the non-payload size of the message, and tried to send 16k-payload plus header and options to a client that announced a CSM of exactly 16k. * Tests with TLS were impeded by one implementation only supporting PSK and the other only supporting certificates in the current incomplete state of implementation. * The question came up of how a large request payload be best managed if it is the first message a client sends (see thread at [4]). During tests, BERT operation was in some of these cases made possible by the client delaying its first request until CSM was received, or by requesting another resource before initiating the large PUT. I have recorded the traffic during one of the tests, in case anyone needs samples for building a Wireshark dissector (nudge nudge). Best regards Christian [1]: https://github.com/ARMmbed/java-coap [2]: https://github.com/chrysn/aiocoap [3]: https://gitlab.com/chrysn/coap-wasm-demo [4]: https://mailarchive.ietf.org/arch/msg/core/2CutxE3xjuDrvQaisWgcXk03cIE --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlq1eSsACgkQOY0REtOk veH/iBAAmpH9PEz0v0yo3m8m799KKAMzSe1MWV9H/9JYvj4VCUOG1PEdd2jXm2xg v9DE84xtQX78UajnGThSi0G/SBHqtcnioo0h76EW7J5H5nC88gjG/qo4EwctWUNv 5UwrpqBqZRGy4cUQtS8E0SMHoBU2Npqujm4fzZWGMnnYpbAj62Zlw3uLYuHqwhkr cyGWmi7sXE+v+feHk3X1I/DjnzI8L52k9HTHIfI02pa7tDUrw7g7xLmpYmZlQ6on 8rtrm/5pNkalRLrh5SMfMSmBCma9Z59X8AZfow1Y04mkt2dfcxmfsVOfySuiDTnX 64HD/WhUKh8UYVNKax65Ln7Psokb/HwhwA8sdAf503HElHl4kNrB1fY/QSEN2raa d4gCjx4B9qpMgpH+qOXmhKB3T4+HvqhmnNwCxY+daynzln2TDo8ka1HAXqCC2dgh xJqEnf9LTYxZG95WKCPVJT7ZdBgyypqU5T+ky4zojQ8+IqCbwKKQsdHuxskvMRfL +4Uhdge08NeN9usT49gFSHib+/dt/pbgZ//0naYJVyvixRXQeggs6vWCBNgpifkV nz6ekviVo3rOVLs5GJ+uf0UimNADW7Smjz/r0GPrpW3XGxliHXvInXPNB78rVV2y e03cWM3Dd/pGOQP1EfWaGKdzH671SAxZJgl1dDfBlRLc79oNvIM= =qVT/ -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From nobody Sat Mar 24 13:09:59 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC86126CB6 for ; Sat, 24 Mar 2018 13:09:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 WW951oJVns4U for ; Sat, 24 Mar 2018 13:09:56 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CF01200C1 for ; Sat, 24 Mar 2018 13:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KLX/2ontws46PkPRxNi112vf+tiCrs5FaFQTGgQh1TU=; b=JEXh9NtldONBwMNHxOZQqeiPbKrNJeSmDF6zsMiBLIVu6vMYJKAsXnV0MaK/P70PbPaFrWVv5kEZjpW0qBPzHzvSjR+S3WiXeYx3sjwpB+ZMdNBxwR414sPMg20/+cf1Fx53qgOlrKaplLnQzXcpcKH9TXvp9gtdBxn6lOTfc9Y= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0588.eurprd07.prod.outlook.com (10.160.46.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.6; Sat, 24 Mar 2018 20:09:52 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e%5]) with mapi id 15.20.0609.009; Sat, 24 Mar 2018 20:09:51 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: "core@ietf.org" Thread-Topic: DTLS CID update (and follow-up) Thread-Index: AQHTw6wQTCG6kr9X1kKuWJHcAGy/Rg== Date: Sat, 24 Mar 2018 20:09:51 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-originating-ip: [92.18.200.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0588; 7:VY73J/LpAcp0hgX0yclZVN4vTKn+cA3ZSmkZ4EIVa2spBC/XcX5MDWiuRv01lQivHeuAggc4cp6w2VU63YJsyMvea/7nvxpe8fY7ZNnlsyqlxOoNLg9UeDjvoJp7rq0v73kYKQPxv541OUILcfBP0FlmVA5jlABItCoG3QT8Yy1zXZ9feaW1hZZ3tIan4Gk+E6miJX+lEynnynUQ8shOeE3geoQZbLdGnt/CJuHwcwUcYxHIg23kUS+2KL18+De7 x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(39380400002)(366004)(39860400002)(396003)(346002)(189003)(199004)(478600001)(1730700003)(2906002)(3280700002)(6512007)(82746002)(6116002)(25786009)(305945005)(3660700001)(2501003)(5660300001)(8676002)(2351001)(2616005)(81156014)(3846002)(5250100002)(83716003)(2900100001)(14454004)(58126008)(36756003)(53936002)(102836004)(6916009)(86362001)(107886003)(316002)(6486002)(33656002)(8936002)(66066001)(15650500001)(99286004)(5640700003)(561944003)(68736007)(81166006)(97736004)(26005)(106356001)(105586002)(7736002)(6436002)(59450400001)(6506007)(186003)(4326008)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0588; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9747e503-6762-4207-e2ac-08d591c3339d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DB3PR07MB0588; x-ms-traffictypediagnostic: DB3PR07MB0588: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231221)(11241501184)(806099)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR07MB0588; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0588; x-forefront-prvs: 0621E7E436 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Na6qqcbnwP693IMJOEAV1IHmXvLRDCvcSGNgrWjOvKn4ZwwOWgnQRCsZm9ZXHhktFwjiM5Bk4Kx9SD15qtfioWwWcFU9SOP34iLbnVrFqAZBuL4bT99UnFk3565oBJrOkTpP/SfklotBx8qPMD6B3dizvU/TOS9W9yuQ1TiTHD26r23VuevXrWoslQZyjAMaIrwvTgu8s8Zxr2JSep/1tF9XVFTosegEVcPwRau0sQR6deyif9Aa22vCwXR7WYQAFEnfgt6GMVVuAbhF8tfXwIUIsxsYsQjWkXkN1x19GyoKUL8xJCcMwQWdt0REkvQbWc5E0xRQDDcXUEb0gk8EuEl9D0AESV1QJVooVUOH8yCwUcp07p/V4CYI4jVMNRdY spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9747e503-6762-4207-e2ac-08d591c3339d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2018 20:09:51.2022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0588 Archived-At: Subject: [core] DTLS CID update (and follow-up) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Mar 2018 20:09:58 -0000 SGkgZm9sa3MsDQoNCkZvciB0aG9zZSB3aG8gY291bGRuJ3QgY29tZSB0byBXZWRuZXNkYXkncyBU TFMgc2Vzc2lvbiwgdGhlIGRlY2lzaW9uIHdhcw0KdG8gcHJvZ3Jlc3MgQ0lEIGZvciBEVExTIDEu MiBzZXBhcmF0ZWx5IGZyb20gMS4zLCBpbiBvcmRlciB0byBtYWtlIGl0DQphdmFpbGFibGUgZWFy bGllci4NCg0KVGhlIG90aGVyIGRlY2lzaW9uIHdhcyB0byBub3QgYmFjay1wb3J0IHRoZSAiQ0lE IHVwZGF0ZSIgc2lnbmFsbGluZyBmcm9tDQoxLjMgdG8gMS4yLCB3aGljaCBtZWFucyB0aGF0IGlm IHdlIHdhbnQgYSBjb2hlcmVudCBwcml2YWN5IHN0b3J5IGZvcg0KMS4yLCB3ZSBuZWVkIHRvIGRv IHNvbWV0aGluZyBvdXRzaWRlIERUTFMuDQoNCjx0bGRyPg0KICBEaWZmZXJlbnRseSBmcm9tIERU TFMgMS4zLCB3aGVyZSB0d28gZGVkaWNhdGVkIHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzDQogIGV4 aXN0IHRvIHJ1biBhICJDSUQgdXBkYXRlIiBzdWItcHJvdG9jb2wgb3ZlciBhbiBleGlzdGluZyBz ZXNzaW9uLCBpbg0KICBEVExTIDEuMiBlbmRwb2ludHMgYXJlIHN0dWNrIHdpdGggdGhlIGNvbm5l Y3Rpb24gaWRzIHRoYXQgaGF2ZSBiZWVuDQogIG5lZ290aWF0ZWQgYXQgaGFuZHNoYWtlIHRpbWUu ICBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCBsYWNraW5nDQogIHRoZSBhYmlsaXR5IHRv IHVwZGF0ZSBjb25uZWN0aW9uIGlkcyBtaWQtc2Vzc2lvbiBsaW1pdHMgdGhlIHBvdGVudGlhbA0K ICB0byBwcm90ZWN0IGFnYWluc3QgYW4gYWR2ZXJzYXJ5IHRoYXQgY2FuIG9ic2VydmUgbXVsdGlw bGUgcGF0aHMgYW5kDQogIGNhbiBjb3JyZWxhdGUgZGV2aWNlcycgaW50ZXJhY3Rpb25zIGFjcm9z cyB0aG9zZSBwYXRocy4NCjwvdGxkcj4NCg0KU28sIEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHdl IGNvdWxkIGFkZCBhIGNvdXBsZSBvZiBDb0FQIG9wdGlvbnMgd2l0aA0Kc2FtZSBzZW1hbnRpY3Mg YXMgMS4zJ3MgUmVxdWVzdENvbm5lY3Rpb25JZCBhbmQgTmV3Q29ubmVjdGlvbklkIGFuZA0KcGln Z3liYWNrIHRob3NlIG9uIGNvbmZpcm1hYmxlIHRyYW5zYWN0aW9ucyAtIHllcywgQUNLaW5nIHRo b3NlIHNpZ25hbHMNCmlzIG5vdCBhbiBvcHRpb24uDQoNClRoaXMgaXMgY2VydGFpbmx5IG5vdCB0 aGUgY2xlYW5lc3QgZGVzaWduIHBvc3NpYmxlIC0gaXQgYWJ1c2VzIGENCmNvbnN0cnVjdCB0aGF0 IGlzIGludGVuZGVkIGZvciBjYXJyeWluZyByZXByZXNlbnRhdGlvbiBzZW1hbnRpY3MgYW5kDQpz dHVmZnMgcGF0aCBhdHRyaWJ1dGVzIGludG8gaXQhIC0gYnV0IEkgY291bGRuJ3QgY29tZSB1cCB3 aXRoIGFueXRoaW5nDQpiZXR0ZXIsIGFwcGFyZW50bHkuDQoNCkJlZm9yZSBzdGFydGluZyB0byB3 cml0ZSB1cCBhIHByb3Bvc2FsLCBJJ2QgbGlrZSB0byBoZWFyIGZyb20gdGhlIHlvdQ0Kd2hldGhl ciB5b3UgdGhpbms6DQphKSBUaGlzIGFwcHJvYWNoIHVuYWNjZXB0YWJsZT8NCmIpIFRoZXJlJ3Mg YW4gYWx0ZXJuYXRpdmUgZGVzaWduPw0KDQpUaGFua3MgZm9yIHlvdXIgdGltZSwNCkNoZWVycywg dO+7vw0KDQo= From nobody Sat Mar 24 13:52:00 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88001242EA for ; Sat, 24 Mar 2018 13:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] 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 cS3jBIC51Wjt for ; Sat, 24 Mar 2018 13:51:56 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425711204DA for ; Sat, 24 Mar 2018 13:51:55 -0700 (PDT) Received: from mail-qt0-f178.google.com ([209.85.216.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1ezq8l-0008TZ-OK; Sat, 24 Mar 2018 21:51:51 +0100 Received: by mail-qt0-f178.google.com with SMTP id i8so16026390qtj.0 for ; Sat, 24 Mar 2018 13:51:51 -0700 (PDT) X-Gm-Message-State: AElRT7GStwr9ndH/6xt4rQsUY1l7jrvLrOdAKlz9KJTqV/G2JAlb9/za vqRnQYsa3fIOo/0QUgZwC24+Jjl1D2mnq2LdSs0= X-Google-Smtp-Source: AG47ELu9AgKEO2uFyd4ezLVnM8zwzSDC2xSW5/fOm8QbsbANcGGsHbsEkc6IGZQCmB+iomXNev0BrQ9qrjye9Awk2Qc= X-Received: by 10.200.22.211 with SMTP id y19mr47959747qtk.216.1521924710653; Sat, 24 Mar 2018 13:51:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.170.140 with HTTP; Sat, 24 Mar 2018 13:51:10 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Sat, 24 Mar 2018 21:51:10 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge)" Cc: "core@ietf.org" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1521924716; 767a8a20; X-HE-SMSGID: 1ezq8l-0008TZ-OK Archived-At: Subject: Re: [core] DTLS CID update (and follow-up) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Mar 2018 20:51:58 -0000 Thomas Fossati wrote: > a) This approach unacceptable? > b) There's an alternative design? We have the 7.xx CoAP signalling codes to manage a TCP connection. I could imagine doing something similar here if that's really necessary. Tacking new options onto requests or responses for that, which are not related to those requests and responses, is probably not a good idea. After glancing at draft-ietf-tls-dtls-connection-id-00, it looks like this belongs more to the DTLS layer. Will DTLS implementations need to provide an API for managing connection IDs from applications? Or are DTLS implementations expected to scan CoAP messages for magic fields? It seems this could be solved more cleanly if all information needed was provided within DTLS itself. I didn't follow the discussion in the TLS WG, though. Klaus From nobody Sat Mar 24 17:13:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEDC126D73 for ; Sat, 24 Mar 2018 17:13:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 5EEW25fInSMS for ; Sat, 24 Mar 2018 17:13:47 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01D812025C for ; Sat, 24 Mar 2018 17:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LzObinagMjR+EOItA219SkcFJHEkK/Ke/jAVX7mAC/o=; b=pNnXZSvgoNHupFn39HsgDDWLrqJZHOhlpFhwpUFTBtX0voeqp/ztXBYYo7BTt+Na5DjC9G1oonwR9VGkDc0EyROfzES5+fL1zCgIEpqaq8Ey/k2HRgtIjY4hALT2sRZHupzMAkoskhEF+CI+arWH2Vh0hrWdCTQADbIH8kC5TWg= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0569.eurprd07.prod.outlook.com (10.160.45.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.6; Sun, 25 Mar 2018 00:13:42 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e%5]) with mapi id 15.20.0609.009; Sun, 25 Mar 2018 00:13:41 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Klaus Hartke CC: "core@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge)" Thread-Topic: [core] DTLS CID update (and follow-up) Thread-Index: AQHTw6wQTCG6kr9X1kKuWJHcAGy/RqPf3FQAgAA4lAA= Date: Sun, 25 Mar 2018 00:13:40 +0000 Message-ID: <6A56388F-C819-49C6-A88A-35E8A1DEBEC8@nokia.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [92.18.200.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0569; 7:aO+Glf0TVR8oubXbIpz1ddSwrzemwg6Z54O65Vpory/p1kaYgh3ydxP9hCZdTKQEN94s0gJg46+t2euNKoMBlBi4nZZo2ZtTSsvvaxdS/bjVDHL1WNecYHJ9B8FE3YHkmraV++WBdJTm4NC95ZInTL5UAdapuJt5lg1Z7ZU8m7525jEA88hB8Gl0poexoZMoOjJK3e/398mlA1LRzKZwDfR+8f5gM7ypVq58sB0LqInj8+uh7ljMkNC3wg3psxOR x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(396003)(39380400002)(199004)(189003)(966005)(5250100002)(5660300001)(8936002)(36756003)(58126008)(83716003)(3846002)(3280700002)(6116002)(3660700001)(82746002)(81156014)(33656002)(2616005)(8676002)(106356001)(105586002)(26005)(102836004)(97736004)(107886003)(81166006)(446003)(6512007)(6436002)(4326008)(6486002)(229853002)(6246003)(2900100001)(54906003)(6916009)(6306002)(14454004)(53936002)(305945005)(25786009)(53546011)(15650500001)(66066001)(316002)(11346002)(186003)(99286004)(68736007)(2906002)(86362001)(6506007)(7736002)(59450400001)(76176011)(478600001)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0569; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3409d71a-9692-45c0-3591-08d591e543a3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DB3PR07MB0569; x-ms-traffictypediagnostic: DB3PR07MB0569: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231221)(11241501184)(806099)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR07MB0569; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0569; x-forefront-prvs: 0622A98CD5 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9XY37J9qJN2EB7UjWnNv+qan080AFWI7W/xJBD0HMDuo+L0V/EGUuP2bA8RWd91juJQZU3KQbq0T61qUx/pxYkg6uzn+gS8dQMLfELnmSOSRYwwf4Vr7nfW66QQoL7LAsA/urxq5C0dtY1gyGqw1SuYtlc/FmNerlpT1Rw4bOkvAXXZoYlUMTwZhc9GFHZNVsj+QXmQFChjOJWyNhaq5ZA04SzO0BXPqfU3SjOQcqo2jnCdnXGgoAM0SaYgXoqU+pNTDnu2JjWEgVBN/AuNOmiOxBWLe8dBkdQ1XbTGVPvBAISe5Y+TgLv2ry3SAwa7dhaFtw+g+90t7tEMK2bfrk8KfdD60eBsaAdlaM2U/AU7dslDMvQ7///x53+U7sa9T spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <085BE3E3CD4A40479FD500BCC301168F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3409d71a-9692-45c0-3591-08d591e543a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2018 00:13:40.9538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0569 Archived-At: Subject: Re: [core] DTLS CID update (and follow-up) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Mar 2018 00:13:49 -0000 SGkgS2xhdXMsDQoNCk9uIDI0LzAzLzIwMTgsIDIwOjUxLCAiS2xhdXMgSGFydGtlIiA8aGFydGtl QHByb2plY3Rjb29sLmRlPiB3cm90ZToNCj4gVGhvbWFzIEZvc3NhdGkgd3JvdGU6DQo+ID4gYSkg VGhpcyBhcHByb2FjaCB1bmFjY2VwdGFibGU/DQo+ID4gYikgVGhlcmUncyBhbiBhbHRlcm5hdGl2 ZSBkZXNpZ24/DQo+IA0KPiBXZSBoYXZlIHRoZSA3Lnh4IENvQVAgc2lnbmFsbGluZyBjb2RlcyB0 byBtYW5hZ2UgYSBUQ1AgY29ubmVjdGlvbi4gSQ0KPiBjb3VsZCBpbWFnaW5lIGRvaW5nIHNvbWV0 aGluZyBzaW1pbGFyIGhlcmUgaWYgdGhhdCdzIHJlYWxseSBuZWNlc3NhcnkuDQoNCkl0IGxvb2tz IGxpa2UgNy54eCBhbmQgYSBjb3VwbGUgb2YgYWQgaG9jIG9wdGlvbnMgbWlnaHQgZG8gdGhlIHRy aWNrDQp0aGVuPw0KDQo+IFRhY2tpbmcgbmV3IG9wdGlvbnMgb250byByZXF1ZXN0cyBvciByZXNw b25zZXMgZm9yIHRoYXQsIHdoaWNoIGFyZSBub3QNCj4gcmVsYXRlZCB0byB0aG9zZSByZXF1ZXN0 cyBhbmQgcmVzcG9uc2VzLCBpcyBwcm9iYWJseSBub3QgYSBnb29kIGlkZWEuDQoNCkkgYWdyZWUg aXQncyBwcmV0dHkgbWVzc2VkIHVwLiAgVGhlIG9ubHkgbmljZSBwcm9wZXJ0eSBpcyB5b3UgY2Fu DQpwaWdneWJhY2sgQ0lEIHVwZGF0ZXMgb24gZXhpc3RpbmcgZXhjaGFuZ2VzIHNvIHlvdSBkb24n dCBuZWVkIGV4dHJhDQpyb3VuZC10cmlwcy4uLg0KDQo+IEFmdGVyIGdsYW5jaW5nIGF0IGRyYWZ0 LWlldGYtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0wMCwgaXQgbG9va3MgbGlrZQ0KPiB0aGlzIGJl bG9uZ3MgbW9yZSB0byB0aGUgRFRMUyBsYXllci4gV2lsbCBEVExTIGltcGxlbWVudGF0aW9ucyBu ZWVkIHRvDQo+IHByb3ZpZGUgYW4gQVBJIGZvciBtYW5hZ2luZyBjb25uZWN0aW9uIElEcyBmcm9t IGFwcGxpY2F0aW9ucz8gT3IgYXJlDQo+IERUTFMgaW1wbGVtZW50YXRpb25zIGV4cGVjdGVkIHRv IHNjYW4gQ29BUCBtZXNzYWdlcyBmb3IgbWFnaWMgZmllbGRzPw0KDQpZZXMsIGlmIHdlIGdvIGRv d24gdGhpcyByb3V0ZSB3ZSBuZWVkIHRvIGFsc28gZXh0ZW5kIHRoZSBEVExTIEFQSSB0bw0Kc3Vw cG9ydCBhdCBsZWFzdCB0d28gdGhpbmdzOiBnZXR0aW5nIGEgbmV3IENJRCBhbmQgc2V0dGluZyB0 aGUgcGVlcidzDQpDSUQgZm9yIHRoZSBzZXNzaW9uLg0KDQo+IEl0IHNlZW1zIHRoaXMgY291bGQg YmUgc29sdmVkIG1vcmUgY2xlYW5seSBpZiBhbGwgaW5mb3JtYXRpb24gbmVlZGVkDQo+IHdhcyBw cm92aWRlZCB3aXRoaW4gRFRMUyBpdHNlbGYuIEkgZGlkbid0IGZvbGxvdyB0aGUgZGlzY3Vzc2lv biBpbiB0aGUNCj4gVExTIFdHLCB0aG91Z2guDQoNClllcywgSSBhbHNvIHRoaW5rIERUTFMgd291 bGQgYmUgdGhlIHJpZ2h0IHBsYWNlIGZvciBkb2luZyB0aGlzLg0KSG93ZXZlciwgdGhlIFRMUyBj aGFpcnMgd2VyZSBwcmV0dHkgY2xlYXIgdGhhdCBwb3J0aW5nIDEuMyBmZWF0dXJlcyAoYW5kDQp0 aGUgY29tcGxleGl0eSB0aGF0IGNvbWVzIHdpdGggdGhhdCkgdG8gMS4yIHdhcyBub3QgaW4gc2Nv cGUuDQoNClRoZSBhbHRlcm5hdGl2ZSBpcyB0aGF0IHdlIGRlc2lnbiB5ZXQgYW5vdGhlciBDSUQg d2l0aCB0aGUgcHJpdmFjeQ0KcHJvcGVydGllcyB3ZSBuZWVkIGFuZCB0aGF0IGNhbiBsaXZlIHdp dGggdGhlIHJlZHVjZWQgc2lnbmFsbGluZw0KYXZhaWxhYmxlIGluIDEuMi4gIEFzIGEgbWF0dGVy IG9mIGZhY3RzLCB3ZSBvcmlnaW5hbGx5IHdvcmtlZCBvbiBhbiBIT1RQDQpiYXNlZCBjb25zdHJ1 Y3Rpb24gdGhhdCBwcmVjb21wdXRlcyB0aGUgc2FtZSwgYXJiaXRyYXJpbHkgbG9uZywgc3RyaW5n DQpvZiA0LWJ5dGVzIENJRHMgb24gYm90aCBlbmRzIGFuZCB0aGVyZWZvcmUgZG9lc24ndCBuZWVk IGFueSBleHBsaWNpdA0KdXBkYXRlIHNpZ25hbGxpbmcgcG9zdC1oYW5kc2hha2UuICBUaGUgdHJv dWJsZSBpcyB0aGUgY29sbGlzaW9uDQpwcm9wZXJ0aWVzIGFyZSBwcmV0dHkgcnViYmlzaCBbMV0s IG1ha2luZyB0aGUgc2NoZW1lIGJyaXR0bGUgd2hlbiB0aGUNCm51bWJlciBvZiBjb25jdXJyZW50 IHNlc3Npb25zIGdldHMgbW9kZXJhdGVseSBoaWdoLg0KDQpBbm90aGVyIHBvc3NpYmlsaXR5IGlz IHdlIGp1c3QgZHJvcCB0aGUgcHJpdmFjeSByZXF1aXJlbWVudCBmb3IgMS4yLA0KdGhhdCdkIGJl IHByZXR0eSBzYWQgdGhvdWdoLg0KDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgaW5wdXQh DQoNCkNoZWVycywgdA0KDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bWF2cm9naWFubm9wb3Vsb3MtdGxzLWNpZC0wMSNzZWN0aW9uLTQNCg0K From nobody Sun Mar 25 01:33:03 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BFD12422F for ; Sun, 25 Mar 2018 01:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] 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 tI1itiqGCa0x for ; Sun, 25 Mar 2018 01:33:00 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474FD1200B9 for ; Sun, 25 Mar 2018 01:33:00 -0700 (PDT) Received: from mail-qt0-f181.google.com ([209.85.216.181]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1f015E-00039W-Vz; Sun, 25 Mar 2018 10:32:57 +0200 Received: by mail-qt0-f181.google.com with SMTP id j26so16712719qtl.11 for ; Sun, 25 Mar 2018 01:32:56 -0700 (PDT) X-Gm-Message-State: AElRT7FicukUf/YlS1ULJod4+h9w2ntj3kn+uj0B5TQFOz/rZvc6/sbS 3KJg7c1OQ4/BOU8lIm9+WTI4Yb7iDdPNIE9Sgmw= X-Google-Smtp-Source: AG47ELsz8s6W3Cc83qBMx9tjgsK8q6Bpk/nCfKN2eWqFwTxWvDewcRikqIR/7sYIl7AbTYVrVrZbDS1761dPSFLOW6I= X-Received: by 10.200.22.211 with SMTP id y19mr49799570qtk.216.1521966775896; Sun, 25 Mar 2018 01:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.170.140 with HTTP; Sun, 25 Mar 2018 01:32:15 -0700 (PDT) In-Reply-To: <6A56388F-C819-49C6-A88A-35E8A1DEBEC8@nokia.com> References: <6A56388F-C819-49C6-A88A-35E8A1DEBEC8@nokia.com> From: Klaus Hartke Date: Sun, 25 Mar 2018 10:32:15 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge)" Cc: "core@ietf.org" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1521966780; 6c118283; X-HE-SMSGID: 1f015E-00039W-Vz Archived-At: Subject: Re: [core] DTLS CID update (and follow-up) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Mar 2018 08:33:02 -0000 Thomas Fossati wrote: > It looks like 7.xx and a couple of ad hoc options might do the trick > then? Well, CoAP over DTLS is currently not specified to have 7.xx codes. So you would need to specify a new protocol version, let's call it CoAP 1.1, that adds support and specify some version negotiation mechanism that allows clients and servers to discover if the other side understands the 7.xx codes over DTLS or not (ALPN?). My gut feeling is that this combined (plus the APIs to manage CIDs from applications) would create much more complexity than just extending DTLS 1.2. Another idea: You let each end of the DTLS connection offer a CoAP resource that represents the DTLS connection. If one end wants to change the connection parameters, it can manipulate the remote resource with POST or PATCH requests. That's not much better complexity-wise, but at least it wouldn't put the complexity into DTLS or CoAP. Klaus From nobody Sun Mar 25 04:34:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6759127599 for ; Sun, 25 Mar 2018 04:34:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 IZAs_LnvjXez for ; Sun, 25 Mar 2018 04:34:45 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40118.outbound.protection.outlook.com [40.107.4.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA12E120454 for ; Sun, 25 Mar 2018 04:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bzgmSnAj9Wf1FZ3GbnRM4rM6UnV1XCFTcW1fT8Zwo5o=; b=eAWJsJvH89WfbgfLQK05hiG95RBJD4EA4MlgUvRE04fryOx+V33MiG9YDYsqDFw/2qhQ9HboPik+l5EhF8VZixciYkOEZytjW1uKdDWfpzeDESU0DEv0prIxurgz6o1PYZtlVO3AHTZs55AHLputbuSicaltRlwNSW+N8d9RGGI= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0508.eurprd07.prod.outlook.com (10.160.44.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.6; Sun, 25 Mar 2018 11:34:42 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e%5]) with mapi id 15.20.0609.009; Sun, 25 Mar 2018 11:34:41 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Klaus Hartke CC: "core@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge)" Thread-Topic: [core] DTLS CID update (and follow-up) Thread-Index: AQHTw6wQTCG6kr9X1kKuWJHcAGy/RqPf3FQAgAA4lACAAItOgIAAQ7sA Date: Sun, 25 Mar 2018 11:34:41 +0000 Message-ID: References: <6A56388F-C819-49C6-A88A-35E8A1DEBEC8@nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [92.18.206.104] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0508; 7:z5mOQJn5ZFfkwmODjRnRbvE02p8XYyLbWvUDid5Xx3IM+VK7AqSEsWFBoH6g2dcf1hOopk1Yx3gE6CsBz7fS+4CU9RuemNskHzHnY4VtgxLzHXTSoo5L2Gim+4WxxHGnbDBDhYrK1SgYKKIoMrC00ucrC3oaGiQ5K8tNIS3uGyNu1ul319u7YbnBMF+1K0EGHPob9RPtejYVO8iOy0T9ybw80ZYT0xeTzz9kiCl6Vj5hRZiHULfe4FPPusahS+jJ x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(39380400002)(39860400002)(346002)(396003)(366004)(189003)(199004)(86362001)(2900100001)(8676002)(54906003)(7736002)(58126008)(305945005)(81166006)(81156014)(53546011)(14454004)(68736007)(6486002)(2616005)(97736004)(26005)(5660300001)(6436002)(59450400001)(186003)(3660700001)(6506007)(99286004)(93886005)(66066001)(83716003)(2906002)(6916009)(8936002)(6512007)(478600001)(82746002)(102836004)(3280700002)(105586002)(4326008)(25786009)(36756003)(6116002)(6246003)(53936002)(11346002)(76176011)(5250100002)(3846002)(316002)(229853002)(107886003)(33656002)(106356001)(446003)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0508; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 861c32b7-1fa3-443c-3eb4-08d592446680 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DB3PR07MB0508; x-ms-traffictypediagnostic: DB3PR07MB0508: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(11241501184)(806099)(944501327)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DB3PR07MB0508; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0508; x-forefront-prvs: 0622A98CD5 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dDKhO8NoiTiyhRPK5pp9Wq0qXyh8VTQ8oA5SvkmayfqKHaIFGN3ZWoznZ182s27NWkWOz/0tskKCUMnJ5o706Kp/TwNkLiRtjaQWL62YsS8sCjZFfE9xIvtojOwFdsGtK0WCL+q2rMnD279frpU9OUhOqX4LmsW6gJUgxWQkgy3gaTAL0TWRbTtbHxORkw/2IH0Aa4vd08EoHPJTibXWULer09+2BPcqBoRWWnlw6P/qKsBq+UjdNZtvHAHaLI4uSuk+o6dmOxb4eU27km8cLtapEbxSlDywdt7OQQSWjgUZgoYyJabDS7fzR+NYQrGXFbX/0WBPcj86bJjJInlki7INVoFXNHf85xDaoBauUWzyo+aODPLH7v8Q33y8xCk/ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 861c32b7-1fa3-443c-3eb4-08d592446680 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2018 11:34:41.6185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0508 Archived-At: Subject: Re: [core] DTLS CID update (and follow-up) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Mar 2018 11:34:47 -0000 SGkgS2xhdXMsDQoNCk9uIDI1LzAzLzIwMTgsIDA5OjMzLCAiS2xhdXMgSGFydGtlIiA8aGFydGtl QHByb2plY3Rjb29sLmRlPiB3cm90ZToNCj4gVGhvbWFzIEZvc3NhdGkgd3JvdGU6DQo+ID4gSXQg bG9va3MgbGlrZSA3Lnh4IGFuZCBhIGNvdXBsZSBvZiBhZCBob2Mgb3B0aW9ucyBtaWdodCBkbyB0 aGUgdHJpY2sNCj4gPiB0aGVuPw0KPiANCj4gV2VsbCwgQ29BUCBvdmVyIERUTFMgaXMgY3VycmVu dGx5IG5vdCBzcGVjaWZpZWQgdG8gaGF2ZSA3Lnh4IGNvZGVzLiBTbw0KPiB5b3Ugd291bGQgbmVl ZCB0byBzcGVjaWZ5IGEgbmV3IHByb3RvY29sIHZlcnNpb24sIGxldCdzIGNhbGwgaXQgQ29BUA0K PiAxLjEsIHRoYXQgYWRkcyBzdXBwb3J0IGFuZCBzcGVjaWZ5IHNvbWUgdmVyc2lvbiBuZWdvdGlh dGlvbiBtZWNoYW5pc20NCj4gdGhhdCBhbGxvd3MgY2xpZW50cyBhbmQgc2VydmVycyB0byBkaXNj b3ZlciBpZiB0aGUgb3RoZXIgc2lkZQ0KPiB1bmRlcnN0YW5kcyB0aGUgNy54eCBjb2RlcyBvdmVy IERUTFMgb3Igbm90IChBTFBOPykuIE15IGd1dCBmZWVsaW5nIGlzDQo+IHRoYXQgdGhpcyBjb21i aW5lZCAocGx1cyB0aGUgQVBJcyB0byBtYW5hZ2UgQ0lEcyBmcm9tIGFwcGxpY2F0aW9ucykNCj4g d291bGQgY3JlYXRlIG11Y2ggbW9yZSBjb21wbGV4aXR5IHRoYW4ganVzdCBleHRlbmRpbmcgRFRM UyAxLjIuDQoNCkFjdHVhbGx5LCBkb2luZyB0aGUgQVBJIGlzIHByb2JhYmx5IHRoZSBlYXNpZXN0 LCBpdCdzIHRoZSBjYXBhYmlsaXR5DQpuZWdvdGlhdGlvbiB0aGF0IGxvb2tzIG92ZXJraWxsLg0K DQpXaXRoIHJlZ2FyZHMgdG8gZXh0ZW5kaW5nIERUTFMsIEkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ug YW5kIHRoYXQgd2FzIGFsc28NCm15IGluaXRpYWwgc3RhbmNlLCBidXQgdGhlIHNpZ25hbCBmcm9t IHRoZSBUTFMgV0cgd2FzIHZlcnkgY2xlYXIsIGFuZA0KaW4gYSBzZW5zZSB1bmRlcnN0YW5kYWJs ZS4NCg0KVGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IHRoZSBJb1QgdXBncmFkZSB0byBUTFMgMS4z IG9wZXJhdGVzIG9uDQpjb21wbGV0ZWx5IGRpZmZlcmVudCB0aW1lIHNjYWxlcyB0aGFuIHRoYXQg b2YgYnJvd3NlcnMsIGFuZCB0aGUgcmlzayBvZg0KaGF2aW5nIGEgcmVsZXZhbnQgbnVtYmVyIG9m IGRlcGxveW1lbnRzIG9uIDEuMiBmb3IgbG9uZ2VyIHRoYW4gZGVzaXJhYmxlDQppcyBub3QgbmVn bGlnaWJsZS4NCg0KQW5kIHNpbmNlIHdlIGFyZSB0aGUgbWFpbiBjb25zdW1lcnMgb2YgdGhlIENJ RCBjb25zdHJ1Y3QgKGF0IGxlYXN0IGZvcg0KdGhlIHRpbWUgYmVpbmcpLCBpdCBpcyBub3QgY29t cGxldGVseSBib25rZXJzIHRvIHRyeSBhbmQgd29yayBvdXQgYQ0Kc29sdXRpb24gaGVyZSBpbiBD b1JFLg0KDQo+IEFub3RoZXIgaWRlYTogWW91IGxldCBlYWNoIGVuZCBvZiB0aGUgRFRMUyBjb25u ZWN0aW9uIG9mZmVyIGEgQ29BUA0KPiByZXNvdXJjZSB0aGF0IHJlcHJlc2VudHMgdGhlIERUTFMg Y29ubmVjdGlvbi4gSWYgb25lIGVuZCB3YW50cyB0bw0KPiBjaGFuZ2UgdGhlIGNvbm5lY3Rpb24g cGFyYW1ldGVycywgaXQgY2FuIG1hbmlwdWxhdGUgdGhlIHJlbW90ZQ0KPiByZXNvdXJjZSB3aXRo IFBPU1Qgb3IgUEFUQ0ggcmVxdWVzdHMuIFRoYXQncyBub3QgbXVjaCBiZXR0ZXINCj4gY29tcGxl eGl0eS13aXNlLCBidXQgYXQgbGVhc3QgaXQgd291bGRuJ3QgcHV0IHRoZSBjb21wbGV4aXR5IGlu dG8gRFRMUw0KPiBvciBDb0FQLg0KDQpUaGUgZGlzYWR2YW50YWdlIGlzIHRoYXQgdGhpcyBtb3Zl cyB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIG1lY2hhbmlzbQ0KZnJvbSB0aGUgc3RhY2sgdG8g dGhlIGFwcGxpY2F0aW9uIC0gd2l0aCBhbGwgdGhhdCBpdCBlbnRhaWxzLg0KDQpCdXQgdGhhbmtz IGZvciB0aHJvd2luZyBpZGVhcyBhdCB0aGUgcHJvYmxlbSAtIG11Y2ggYXBwcmVjaWF0ZWQhDQoN Cg== From nobody Mon Mar 26 05:52:21 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A8A12DA51 for ; Mon, 26 Mar 2018 05:52:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 I_L9a7J2wC6A for ; Mon, 26 Mar 2018 05:52:10 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0102.outbound.protection.outlook.com [104.47.2.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4A612D88E for ; Mon, 26 Mar 2018 05:52:10 -0700 (PDT) Received: from VI1P121CA0006.EURP121.PROD.OUTLOOK.COM (129.75.190.16) by VI1P121MB0047.EURP121.PROD.OUTLOOK.COM (129.75.190.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.12; Mon, 26 Mar 2018 12:52:07 +0000 Received: from AM5EUR02FT040.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::207) by VI1P121CA0006.outlook.office365.com (2603:10a6:821:2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.609.12 via Frontend Transport; Mon, 26 Mar 2018 12:52:07 +0000 Authentication-Results: spf=neutral (sender IP is 13.80.155.198) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.80.155.198 is neither permitted nor denied by domain of philips.com) Received: from EDGE-VM-002.westeurope.cloudapp.azure.com (13.80.155.198) by AM5EUR02FT040.mail.protection.outlook.com (10.152.9.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.631.7 via Frontend Transport; Mon, 26 Mar 2018 12:52:07 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.214) by autodiscover.lighting.com (192.168.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1034.26; Mon, 26 Mar 2018 12:52:04 +0000 Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM (129.75.24.213) by VI1P121MB0045.EURP121.PROD.OUTLOOK.COM (129.75.190.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.12; Mon, 26 Mar 2018 12:51:35 +0000 Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::481b:1c16:5798:8142]) by VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::481b:1c16:5798:8142%14]) with mapi id 15.20.0609.012; Mon, 26 Mar 2018 12:51:35 +0000 From: Esko Dijk To: "core (core@ietf.org)" Thread-Topic: draft-ietf-core-resource-directory-13 review - Sections 1-4 Thread-Index: AdPFAJ52MMhMabDPT/u+a+VlN7oSlg== Date: Mon, 26 Mar 2018 12:51:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [80.246.199.209] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; VI1P121MB0045; 7:Mhq4jIGKcIhA4VFCX1tubYKuTcyObuDBUfdkXFtragWxn6CyVfO5vkjSAZeoKnNoR9/GkUmT5GdeuN7an4ISWp+4OYSwYtVuqelAiLuLo36MjrLM/wNutHra1aMvIRBKiRHnjeYm5gjjn9MHQQTW5E0niUHSeA1rlat3+CGdHXh0EVWeiQCu7juLmOd/vS+dAYB7nWGJpjjvp3YNKKnDu92+HruBboXU3ex1gOGrX+i6OTcE9IzkrT6q4Iv0Xn44 x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: de147071-e41f-4253-a333-08d5931861e0 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:VI1P121MB0045; X-MS-TrafficTypeDiagnostic: VI1P121MB0045:|VI1P121MB0047: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:VI1P121MB0045; BCL:0; PCL:0; RULEID:; SRVR:VI1P121MB0045; BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061750153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:VI1P121MB0047; BCL:0; PCL:0; RULEID:; SRVR:VI1P121MB0047; x-forefront-prvs: 06237E4555 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(39380400002)(346002)(366004)(376002)(199004)(189003)(76104003)(8936002)(6506007)(478600001)(14454004)(413944005)(966005)(3846002)(5250100002)(54896002)(6116002)(790700001)(6306002)(316002)(9686003)(81156014)(81166006)(5660300001)(86362001)(25786009)(74316002)(7736002)(606006)(3660700001)(59450400001)(3280700002)(68736007)(2900100001)(99286004)(6436002)(2906002)(53936002)(7696005)(106356001)(105586002)(8676002)(236005)(26005)(55016002)(102836004)(66066001)(97736004)(33656002)(6916009)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P121MB0045; H:VI1P121MB0014.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) X-Microsoft-Antispam-Message-Info-Original: q7Upg0oZVEmMQrCGnNd+XHAQpdUKVDvbXdns8ViVNlUkbnnqGVZMJ/XWtu0Bvg4l5mjaev0JR1zL7rvgmON5wY/sF+WSOCtWGGKKvutHR/a+JTIe8IPS0VWXu2YGxXXr4/YLYI3OAouSmvTIfWox7x5vy5fwaS5EjRfSMvLbDT1ZCIKTPf+Ynmt2xZc9bVki8rXdJlR4FHZ0ncBBQr+46/IvuPmofOHxHpePtTh/j+hdCpozveqDLxwzWdJxtGEtsMuBWhmr1eXywBxEoet7Wv1lgxKXqMXnuAtk5MTAF3aTMlJrRmJly6gP0AbArn2e9WyFNuvMS6cKSl8M/kJl+w== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1P121MB00141A728FCF2A719469B0F49BAD0VI1P121MB0014EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0045 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR02FT040.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.80.155.198; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39380400002)(346002)(396003)(39860400002)(2980300002)(76104003)(189003)(199004)(81156014)(81166006)(5660300001)(5250100002)(8676002)(68736007)(53936002)(236005)(61614004)(54896002)(6306002)(9686003)(55016002)(106466001)(102836004)(26005)(6916009)(33656002)(84326002)(22756006)(6506007)(66066001)(25786009)(498600001)(2906002)(26826003)(413944005)(14454004)(7696005)(97736004)(790700001)(966005)(2900100001)(16586007)(316002)(6116002)(3846002)(74316002)(99286004)(7736002)(606006)(59450400001)(8936002)(336012)(86362001)(105586002)(260700001)(356003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P121MB0047; H:EDGE-VM-002.westeurope.cloudapp.azure.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT040; 1:8BcWLOpac8ZujIO7W9QpdKm+bpX147fTNzJLZICEBmzwgeRVucIrI9iHCB6zzmiOo2T/LoLZD2RzSlz8LD+VOXrNJ2gbh+S3nxqU3a5sD7X63e6MMInAdHpY3P2ilqmg X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(4534165)(4627221)(201703031133081)(8990040)(2017052603328)(7193020); SRVR:VI1P121MB0047; X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0047; 3:oujwxMAWzJrPtn/bFexABQ1RETxXWZr7L9qgj3jDnNjFn1scFz62yBprj4/7jknbXXRw4VzruYA99dnhLH2+Db8QZyu65YpeJydcyriICrUQ11ALKsxWbARgOWYHmXZ/XQtaFPYe1PXy135oXgpZZWr3Z8uPL5Qe8KGbRm6tA72jqaSPAK4F6C4QmNPvEeKmUTecz3LWG7lt7gxX1nytDG2ANc2Du/DZxGgtiNLHPu/7ae5eg229gMKjlIU1SKSv1pfXC+j0mQUKi1OEzbjlMy4q+2t2dJkKDqTRm02J3MhoG6LTdX09r2mx7nqRbSn2FcuyszqFNIydnME2v52VIgq12i5FXSpZ/lmEIvFvtwo=; 25:EqH44D2rjJt8fu6pHCmDcu11k+BJ8+OKjDoEOnml7X7O33httkzlcpI/NRfEUewVLPMOHnRGOcSIIdXjZnk2XXBeGRtuDsRT3RlCvdeqBqFGjMZbyJARgrSnEbA5qcPFnTuxX1ZNih7IXl6CCyDegEXLWUJkOWwTv0fyFsaad97CbJcaAEw0QulyNGu/1T3AzwpRrm2KMbnKRlk/21l7ydk0IkI86p7oEZk2EsKv2Dhr28kHeHQyyNWS7ttY4XRORAGMyZpqMh7UaXTob/sntBLEWdEOQ1Rq6VL6S4fwzt1D14MGsLmrW/Z6mC3ccdvzLmrBf5E530qBaVcFdOSkQw== X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0047; 31:xDlOSnc1qosDFmtVAhsnAmOFvhdcPR0QRcLPq8TCSDF6nnKbX/Wtvcwji55xDV74HZdX6KiqNGEszgGqBtQRc1WVftLohJ/25pXIJ5B4378aw1x6HfbSKASYTLXfwxkp36eZiqOqqC8BZeJQjwfYUEHdMROVIWRv/0OTU/C968OwHdIzNAMkq9L4FypaFObM28mCLeb7AXSlB+CPRDQNn99cEQnhJZUb5Z6Op0JHHIc=; 20:8CJgbVJT+iZFbuKSYtvx4R26XyAzJE7cTkXMWxHWwrpkQeweT8cya5XayQkD6lsPoLLz3TK513YOg+z/zTywDiGH2Sem769QueirdJzHCLwajOpo24GaP+nTShtH4g0+SXw2xfRCKzY21ImkbJ+1x32AGV3tbWuGsrboYwaWWdk2A2NTcHyidRXDQ5gGQzthNABHSngctzxkR3pUvFyXBenMv2RxAyfZUvNEHADsQprPnQXxrgTskXFaAy+BiaJLdU1P/Rrsnd0PjyROddFIgocCDpAnD+yIAYrEJ1ocY2b0H4vo1kfVm80wN8gpaiHAEo6xgtfvSLIB/RGDW4CHarPPjNUNn8fKqu3CCRt4uAKLoB1s6JJzCNx+bfYFebHU7xUk8NR/i84jHohjsXu9o6vzuFFMyDYp/0yQ6egSiDjl/DalCoxZtzwYrfT7ZHCFB0HV+e0bF++4TTubGlsDv2ttvgGLyl/mYN50F2TpDoAZBrPkYTFB8H8PlvWt9pKh X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0047; 4:/q3OFberquYMJrOhMNV2F8+wnGSPCsauy3/Ozbrde2BoeQA9LbiujKzAv1+aDhdPIV5UeoZKrugUwSrIEW2jE+fM+2pm9BMzkD2UneSiMZsOcgv7Wq24d7BcElnx7vB1/5VylALq8q97q345x9wgLPHaq0bdinr6zuerPN6dXYmFTDR1f0vM41w/d7dJz+mi/q7T1d26i7RPxDCfdxG9idu17mvX6C5o1z53SRdFBR37eXn11xOv8bxbL6aNlujTZTST8ifJ3So1/5wJ9INnlO8e23OF41UEzpN5dmQ2riJOg3xhaRdp8NwD9j/Hs05SjF1wCRkLnZB724W0SCTg0m21i48LBFrn2PAd9fiT7wx1yShwn3nS+Y59Jv1R6s3s X-Forefront-PRVS: 06237E4555 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1P121MB0047; 23:kFGG+LJje0GaN9ItkD3owNtkzS6c3SFSx9Zhfcgf8?= =?us-ascii?Q?ELbeA+b1zrYJlky7qRNi+nko++I3dHPwE9ZzFjmkUopO/91NFS54RKZOsvTA?= =?us-ascii?Q?CoRIniKCIsCJoPXbHO5J63nvVlDMWoakl6AV9L58U/rZOCMRkK8OyXRnLwnM?= =?us-ascii?Q?xQw+uyJFdaYq4fXOkyeUFTVTOkOQLBpnQKQz4HlhSWdV+aeSdPYF/C7U7QYQ?= =?us-ascii?Q?TfpQ0cCPfQ4YscvJ3WBQuR3nr1kxhj7ezzdv6DVFHsu8xiRZ6NkQDlbh6qfi?= =?us-ascii?Q?MrFa3BYduEhS4XRtIz4M/ZGhCKmbLwgC2i53BPmcWPfA69k+bu8fHa66DyyY?= =?us-ascii?Q?6Nm0RjR00pxzoH/SufnzalAhxygv6YMlIM+5z/UT47+ibyBkOKawGx9JUoRj?= =?us-ascii?Q?ZY91Z54lOieUrVcbJqwXgKD4NgDkxhqfXzNQnOlhIMXEIP53zC5TQ5rymDRK?= =?us-ascii?Q?obq6IECb5A7JGK5sT0T3AEMRZtIPGsQ4lFPqu/E7HblnP1/BoZ1NulS/o4q2?= =?us-ascii?Q?5Zn1oCnblioYTDgWq86ERHIVKH1foWDaJrhp5ohdiT4cepANNVGMOHulfgRw?= =?us-ascii?Q?TjqEEEEw5q83W7mTy6geDRcTJzLwT/R/Ui+/PIYyNTnnocLaeMI962YRXf9f?= =?us-ascii?Q?K3O5KFQx9qayNOsnJ8BPkPbFr5/O1iOW8+Z7tT3wPObzXguaOdCj7W38OM5K?= =?us-ascii?Q?n2djub2rXuKfl31J4yjHnROfBcfPC/BLZ8Wy4pFw6TptfTcEOdWrUZzImfIn?= =?us-ascii?Q?xwhPZ503aFixSLl6H/z2xyU1jvpTUfSE8SMurrENrrnk0Lb4X2i6zaSlL6nF?= =?us-ascii?Q?ovRQlsqFIKjQYgnS2eb/mBBIgS2TB1wAE5NwogOWFxLlFyZ+x47VrpUiTP+e?= =?us-ascii?Q?UeHtoUMRxiFzKKqIJOCZuJW9uhLWoY9EJWPC1Bxqk5c4XhZz8L6leoJki9Ak?= =?us-ascii?Q?z6s3D2B0cBroOmkGPLkt6JVBBPEQO3QbrhZH05A4v8uAVMFP6r8iVRSNocdR?= =?us-ascii?Q?wgnFszuzi7RdwEtzF8B1eOwGvCW9+XAgzbuvN7tLAHVTDqs/MlsOMPxUHX8X?= =?us-ascii?Q?rgCWcHE8KgcepNJEzjzOvX5i90PXW4tj0dLQkB1j4/5jnRPsHU0AEWAIyqqc?= =?us-ascii?Q?D/HRgfQ6d0TaeEYyV4hNadA+YJr/Be2z2TbP5OnpRanmISMosqF8cgm80GGZ?= =?us-ascii?Q?5i5qozh0y/PgfAxkanzdopylT9L0DjWvvmeyE7vPbMZAnEltJCUah4clgjGW?= =?us-ascii?Q?jm3IQWMpggY2jSgcz5VqRa4fBcCjFHPDNKAGbfngmRdj4asNBscAm2DBZmnn?= =?us-ascii?Q?eqIem6mUSVazXho5LNqwHc=3D?= X-Microsoft-Antispam-Message-Info: Eemi4b+WZhUiBD8+YG7eK+VhfJxdD7SvRnh/rEo4f/9qysof/RQRBjhUiYXWYF4n4g2sBdH2jtKwS/nd9V7BwxcqaaL3huR5wKkW3O0gxtTKTWkGVGsXNeHv2ut6dNcO1yU6gyPtSer5IYAsP4n0IRLJiJJc1T4XNhBIiN3Xf//jt5zsWSKy2XLHA0jmpJzCfU+3EgxhH/fhVtzQXRHh5O+tlYrZSkfPElGsln8cEkssAbSQTZtytgRipu9hq2ZJtEI5eWuuM6x6nrW/2pxdZyfKpiFTxp5+pVEnOR+1uU6yODeRByQaeR1+LvKvX0oVF4cC0d2lr1nfnqgCfrynKw== X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0047; 6:0LFgaBt3sZXZQeJnoF9/e40MA3FHQiP9de7608OLbcdO17cLQK6ET9UjRm04B5UxewY/MUnGJmoj409j/wYakFeuuJWvcF12ZffPVWMA3rOEf+ZpB41NEjatSg7d2h1fqk3XZ/mdCnxmv4nTqVcPMEZFyaefrN8dz1H8q2YTgGjoAOVFssGwO099rFAuHHUdD+o7hitUlFXqFEei5BHHJQdFYMNiuINz8uGcxFaujzg3Az9KtHCl4S0XTacrxyZ7x9bCrlmVcDOgfMpOS8zb049fYC/E6emgyfrvolwrugDtV2GP42fSKKSdmkcMPL0RD5GZY/TPgIXkBP8FZfVTqqqwJW3bNtjWNlAuS0Y7qKfWk6vC/gvm0iAjNAX6slPHrLegQMJnfEEzOkcSS8MsH+FvBX1Kdx2G5KrPepoXhqo2lisLDIQBTR1P71w5DMPIWZr/NSLc3t6gR97pWQoopfs8tijSm93+ZiQ2E8YPyG+epOU27vk4tV0fKketb+6w; 5:1yPTnlw8Xohfzyr9AibHSLXeDKkMopU09NSQiIKqo41AkhHApmewkd+STy88XfVwcsf3gzEdnUnLPnbwJfgNIKzrsUa+qfb/wT4omrXVP8SiIlQx7ppfkyRKbRWuSVUGF+RWVDEhVAEu/s93GPGwcoqWojxBcEGXxoVVzr3tN7Q=; 24:2QfejkDY0uDiwjZmDc7tewEPq3vqQJ8JOk/FMscvcCTZI4NhgMTRWzvjp8YLtpRul75aOc34X1qFsy49ULUUbLxEfsoXTulDD8BB2Ik5eBw= X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0047; 7:5vEmequEuDUp5F0yoDV7EQM/PB0j3pbh3BLiiRDEGxqTxK+KvCHQuyRSNIH/0mrpuF5JcONFtOZ+pOl2OdNY5S85Rbb/8s01TDinbwn1UIzR/3eNdohR69Or1Pr7AlJIsOnosi6jiZjUfPDgPw4sNbB6zHGmPkkC3TSIwiq30Lvid2wqGXYkO/ZMAstb9eOJMgFXgAK1KiP2So0Gqjk80xB3E2Bm+9ES7sWlrVcMcEVKLbBSNUXEU4B1OGYQbBkH X-OriginatorOrg: lightingaad.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2018 12:52:07.3090 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de147071-e41f-4253-a333-08d5931861e0 X-MS-Exchange-CrossTenant-Id: 75b2f54b-feff-400d-8e0b-67102edb9a23 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=75b2f54b-feff-400d-8e0b-67102edb9a23; Ip=[13.80.155.198]; Helo=[EDGE-VM-002.westeurope.cloudapp.azure.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0047 Archived-At: Subject: [core] draft-ietf-core-resource-directory-13 review - Sections 1-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 26 Mar 2018 12:52:17 -0000 --_000_VI1P121MB00141A728FCF2A719469B0F49BAD0VI1P121MB0014EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear RD authors, Below are my review remarks for a partial review of RD-13: Sections 1 to 4.= I thought it good to submit now already, because any clarifications of the= model (3.2 and 3.3) could help the understanding in doing further review o= f the rest of the document. Best regards, Esko Dijk 3.1 accessing those resources -> accessing that resource act on behalf -> act on behalf of "Changes in the Resource Directory do not propagate automatically back to i= ts source" could use some clarification. -> what is "its source" here exactly? Source of the change, or rather the w= eb server that a registration entry is about? -> in case the source is the registering web server itself, why would a cha= nge need to be propagated back to it at all? The server device is itself th= e initiator of the change. -> in case the source is the CT, why would a CT's change to an RD entry nee= d to be propagated back to the CT? 3.2 Figure 2 and other places in the document use "Target" as a term; because n= ot everyone may be familiar with this abbreviation I would add "Target" in = the Section 2 list of terms. Because [RFC 3986][RFC 6690] also do not defin= e this abbreviation. 3.3 The term "host" is now used here for the first time in the document while p= reviously it was a (constrained) "web server". So in the bullet "a set of l= inks belonging to the host" we could clarify this by changing to: "a set of links belonging to the host (the web server whose resources are r= egistered with an RD)" This links the two terminologies together nicely. "Host" is still a good te= rm to use in 3.3 since we also introduce the "hosts" relation here. Last bullet on page 10: adapt formatting to show this bullet is part of the= bullets-list above it. Now it looks as if the link attributes bullets list= that starts on page 9 has only 3 bullets. Figure 4: lifetime 'lt' should be '1' according to the text, not '0-1' Figure 4: Direction of reading the relations seems not always consistent. F= or example, I can read "group is composed of 1 or more registrations" or I = can read "registration is composed of 1 or more groups". The latter is sugg= ested by the placement of the "+1" in the figure, but this seems wrong, so = best to have the "+1" text moved close to the "registration" box to make i= t clear and use the UML class diagram way of directionality of relations. In case the relation goes *both* ways then a solution is to apply the UML c= lass diagram association notation, which means two numbers are placed next = to a relationship line showing that 1 group can be associated to 1+ registr= ations and at the same time one registration can be associated to 0+ groups= . See https://en.wikipedia.org/wiki/Class_diagram#Association for some info a= nd examples. I feel this UML class diagram is a better representation used = most commonly in today's (IT) industry - and we'd better use a graphical re= presentation that provides the expresssion of directionality that we need. "A Group has no or one Multicast address attribute and is composed of 0 or = more endpoints" -> that should be -> "A Group has zero or one Multicast add= ress attribute and is composed of zero or more registrations" if I read Fi= gure 4. There is no line going from the "Group" box to an "Endpoint" box in= the figure. 3.6 "Resource groups may defined to allow batched reads from multiple resources= " -> sentence is unclear whether this is 'an additional RD feature' as mentio= ned in the paragraph, or not. "Batch" does not come back in the RD draft. A= lso the concept of "resource groups" does not come back in the RD draft, we= only have endpoint groups in Section 6. 4 (re-e)starting -> (re)starting RD directory servers -> resource directory servers the service with name rd._sub._coap._udp -> here we specify a new subtype '= rd' under the service name 'coap'. If I read https://tools.ietf.org/html/r= fc6763#section-16 correctly, then it is not mandatory to register this at = IANA. Still it might be best to place this definition in a new Section 9.6 = under 9 IANA Considerations, mentioning this subtype is specified here but = not registered in the IANA Services Names registry because that's optional.= What do you think? Edge Router (6LBR) -> Border Router (6LBR) 4.1 "This information is needed when endpoints cannot discover the Resource Dir= ectory with a link-local multicast address because the endpoint and the RD = are separated by a border Router" -> I would suggest "This information is needed when endpoints cannot discover the Resource Dir= ectory with a link-local or realm-local scope multicast address because the= endpoint and the RD are separated by a border router" "The lifetime 0x0 means that the RD address is invalid and to be removed." -> this information is already provided in the diagram below, in the text f= or the "Valid Lifetime" field. So I suggest removing here to avoid double d= efinition of the same. ________________________________ The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original email. --_000_VI1P121MB00141A728FCF2A719469B0F49BAD0VI1P121MB0014EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear RD authors,

     

    Below are my review remarks for a partial review of = RD-13: Sections 1 to 4. I thought it good to submit now already, because an= y clarifications of the model (3.2 and 3.3) could help the understanding in= doing further review of the rest of the document.

     

    Best regards,

    Esko Dijk

     

     

    3.1

    accessing those resources -&g= t; accessing that resource

     

    act on behalf -> act on be= half of

     

    "Changes in the Resource= Directory do not propagate automatically back to its source"  co= uld use some clarification.

    -> what is "its sourc= e" here exactly? Source of the change, or rather the web server that a= registration entry is about?

    -> in case the source is t= he registering web server itself, why would a change need to be propagated = back to it at all? The server device is itself the initiator of the change.=

    -> in case the source is t= he CT, why would a CT's change to an RD entry need to be propagated back to= the CT?

     

    3.2

    Figure 2 and other places in = the document use "Target" as a term; because not everyone may be = familiar with this abbreviation I would add "Target" in the Secti= on 2 list of terms. Because [RFC 3986][RFC 6690] also do not define this abbreviation.

     

    3.3

    The term "host" is = now used here for the first time in the document while previously it was a = (constrained) "web server". So in the bullet "a set of links= belonging to the host" we could clarify this by changing to:

    "a set of links belongin= g to the host (the web server whose resources are registered with an RD)&qu= ot;

    This links the two terminolog= ies together nicely. "Host" is still a good term to use in 3.3 si= nce we also introduce the "hosts" relation here.

     

    Last bullet on page 10: adapt= formatting to show this bullet is part of the bullets-list above it. Now i= t looks as if the link attributes bullets list that starts on page 9 has on= ly 3 bullets.

     

    Figure 4: lifetime 'lt' shoul= d be '1' according to the text, not '0-1'

     

    Figure 4: Direction of readin= g the relations seems not always consistent. For example, I can read "= group is composed of 1 or more registrations" or I can read "regi= stration is composed of 1 or more groups". The latter is suggested by the placement of the "+1" in the figure, but= this seems wrong, so best to have the "+1" text moved close = to the  "registration" box to make it clear and use the UML = class diagram way of directionality of relations.

    In case the relation goes *bo= th* ways then a solution is to apply the UML class diagram association nota= tion, which means two numbers are placed next to a relationship line showin= g that 1 group can be associated to 1+ registrations and at the same time one registration can be associat= ed to 0+ groups.

    See https://en.wikipedia.org/wiki/Class_diagram#Association for some info a= nd examples. I feel this UML class diagram is a better representation used = most commonly in today's (IT) industry - and we'd better use a graphical re= presentation that provides the expresssion of directionality that we need.

     

    "A Group has no or one M= ulticast address attribute and is composed of 0 or more endpoints" -&g= t; that should be -> "A Group has zero or one Multicast address att= ribute and is composed of zero or more registrations"  if I read Figure 4. There is no line going from the "Group" box = to an "Endpoint" box in the figure.

     

    3.6

    "Resource groups may def= ined to allow batched reads from multiple resources"

    -> sentence is unclear whe= ther this is 'an additional RD feature' as mentioned in the paragraph, or n= ot. "Batch" does not come back in the RD draft. Also the concept = of "resource groups" does not come back in the RD draft, we only have endpoint groups in Section 6.

     

    4

    (re-e)starting -> (re)star= ting

    RD directory servers -> re= source directory servers

     

    the service with name rd._sub= ._coap._udp -> here we specify a new subtype 'rd' under the service name= 'coap'. If I read  https://tools.ie= tf.org/html/rfc6763#section-16  correctly, then it is not mandator= y to register this at IANA. Still it might be best to place this definition= in a new Section 9.6 under 9 IANA Considerations, mentioning this subtype is specified here but not registered in the IANA S= ervices Names registry because that's optional. What do you think?

     

    Edge Router (6LBR) -> Bord= er Router (6LBR)

     

    4.1

    "This information is nee= ded when endpoints cannot discover the Resource Directory with a link-local= multicast address because the endpoint and the RD are separated by a borde= r Router"

    -> I would suggest

    "This information is nee= ded when endpoints cannot discover the Resource Directory with a link-local= or realm-local scope multicast address because the endpoint and the RD are= separated by a border router"

     

    "The lifetime 0x0 means = that the RD address is invalid and to be removed."

    -> this information is alr= eady provided in the diagram below, in the text for the "Valid Lifetim= e" field. So I suggest removing here to avoid double definition of the= same.

     

     

     


    The information contained in= this email may be confidential and/or legally protected under applicable l= aw. The message is intended solely for the addressee(s). If you are not the= intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original email.
     --_000_VI1P121MB00141A728FCF2A719469B0F49BAD0VI1P121MB0014EURP_-- From nobody Tue Mar 27 22:43:14 2018 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 3A960126DC2; Tue, 27 Mar 2018 22:43:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-senml.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152221578820.29905.10455247933119493699@ietfa.amsl.com> Date: Tue, 27 Mar 2018 22:43:08 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-senml-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 05:43:08 -0000 Reviewer: Roni Even Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-senml-?? Reviewer: Roni Even Review Date: 2018-03-27 IETF LC End Date: 2018-03-30 IESG Telechat date: 2018-04-19 Summary: The document is ready for publication as a standard track RFC with nits Major issues: Minor issues: Nits/editorial comments: 1. in section 5.1.6 "another devices" should be "other devices" or "another device" 2. in section 8 "It can simply hard code the output replacing the 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's device ID". I think that the offset ix 0x10 to 0x1f From nobody Thu Mar 29 17:16:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38561127869 for ; Thu, 29 Mar 2018 17:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 Apx7ZouJfZ0r for ; Thu, 29 Mar 2018 17:16:34 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 B8AB2127775 for ; Thu, 29 Mar 2018 17:16:33 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id v205so2840781vkv.13 for ; Thu, 29 Mar 2018 17:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MQmBhNEQbG4ZUgAYC8YA75yJyoScr2nhUM5JxaoEIaE=; b=R3ri+f6waRl/A0x5YVkNlKj4ycW5z1PZhjeBFakJ/yOcomIboe1w5MK44no/W7tBj7 KuEB5Iep9TIVwVj6CFQNUubNpWSSaXMZQEcIlpiPFLO9QZLpmQBPy+mWN60T0j5l5EKP vW1iy0/cXJaNO5K6HYQph/k0hnpA8j69msamdYDrJru8LqMRC0I1QKMAgIiXic8ZMcol qQnbfpK3F5YCM0hGQZv0tz1pfN8Wnna2tqEwKCJfBQ0qXW37NaeTTpnrkAStpXmtrKeE aGi2rTwj+QCEFMfs/KyKdQ0BUIp22JQM6/TDEooXCknWmCN9XcK00d+9zzyyCmSonjKz mzOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MQmBhNEQbG4ZUgAYC8YA75yJyoScr2nhUM5JxaoEIaE=; b=B+DBECZa4rRR5t0VUXeNAqlS1/uoShKm2EJb4lxNCgqhHbcJWzeeid4Kkh/XoBdiny XiR0jZ7AfwexHfYU9L363T8Ss6nSGzeapK3XTCm1748grGZlLxaiNWk48jlF1sWnabS5 yh44aOuQJJyauGGrqRflqZSpWopaKEBj+puCugR88FLSO+M831qCNK5cpKZ3uevpRb5X hmVahrabw4tIzelDtUCUT8ClJCZCAG1bYLUaSU4uIZMc83hiJM1Kq/Apac9HGfzUvYxU eQ3WEHZKcHlKLpG6xqj1LO0vArN1iHzkRD51NxvaiDTSgepK5XqDAM3NX9MvzJFQkXjU pFvA== X-Gm-Message-State: ALQs6tDscjidZ+JBrkGfsIb2/73H4jhrEHASkkMAz4ErfRt7CKTxnnJ3 BbEWDDQp3dEJRRo9+BI4xdPHbLJ17Hh6mJilV5fjQfGT X-Google-Smtp-Source: AIpwx48EIpCz4//486gQGFt6mJRhUQ8vx1k9kf1XUXfjgD8NAhYRLzqp8xDlQ/ZDKeOFLKQcGJwT2LhjliOEZJZTmss= X-Received: by 10.31.234.193 with SMTP id i184mr6668035vkh.151.1522368992300; Thu, 29 Mar 2018 17:16:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.213 with HTTP; Thu, 29 Mar 2018 17:16:31 -0700 (PDT) From: Tanguy Ropitault Date: Thu, 29 Mar 2018 20:16:31 -0400 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0952a200d4880568962745" Archived-At: Subject: [core] draft-ietf-core-comi-02: SID and Delta SID usage inconsistencies ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 30 Mar 2018 00:16:36 -0000 --94eb2c0952a200d4880568962745 Content-Type: text/plain; charset="UTF-8" Hi, I'm wondering if there may be some inconsistencies between SID definition in draft-ietf-core-yang-cbor-05 and its usage in draft-ietf-core-comi-02. The short version of the story is: - draft-ietf-core-yang-cbor-05 defines SID as an unsigned integer "YANG Schema Item iDentifier (SID): Unsigned integer used to identify different YANG items." - draft-ietf-core-comi-02 uses in some sections and examples SID with a negative value (or to be sharp, use delta SID where SID should be normally used) Let's use an example for the long version of the story: Section 2.3 of draft-ietf-core-comi-02 states that: "When part of a payload, instance identifiers are encoded in CBOR based on the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" Section 5.13.1 of draft-ietf-core-yang-cbor-05 states that: "Single instance data nodes MUST be encoded using a CBOR unsigned integer data item (major type 0) and set to the targeted data node SID." *** Please note that I'm using the single instance identifier case for a matter of clarity but the same applies for list instance identifier. So according to the sentences above, a single instance identifier that is a part of a payload can only be an unsigned int. draft-ietf-core-comi-02 also states that FETCH request format must be: "The FETCH request payload contains a list of instance-identifier encoded based on the rules defined by Content-Format application/yang-selectors+cbor in Section 2.5" application/yang-selectors+cbor is defined in Section 2.5 as: "represents a CBOR YANG document containing a list of data node selectors (i.e. instance identifier)." Moreover, Section 2.5 clearly recall this: "YANG instance identifier, encoded based on the rules defined in [ I-D.ietf-core-yang-cbor ] section 5.13.1 ." So the FETCH request payload can only be made of instance identifier which are de-facto unsigned int (in the single instance identifier case) based on Section 2.3 and 5.13.1. However, due to the usage of delta SID for application/yang-selectors+cbor format, some instance identifier of a FETCH request can be negative (as shown in FETCH example in draft-ietf-core-comi-02). In fact, it seems that the sentence "When part of a payload, instance identifiers are encoded in CBOR based on the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" is most of the time superseded by DeltaSID usage. So IMO, it's a little bit confusing and something may need to be added. Tanguy Ropitault (Acklio) --94eb2c0952a200d4880568962745 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,
    I'm wondering if there may be some inconsistenc= ies between SID definition in draft-ietf-core-yang-cbor-05 and its usage in= draft-ietf-core-comi-02.=C2=A0
    The short version of the story is:
    - = draft-ietf-core-yang-cbor-05 defines SID as an unsigned integer "YANG = Schema Item iDentifier (SID): Unsigned integer used to identify different Y= ANG items."
    - draft-ietf-core-comi-02=C2=A0uses in some sections an= d examples SID with a negative value (or to be sharp, use delta SID where S= ID should be=C2=A0normally used)

    Let's use an example for the long version of the story:
    Section 2.3 =C2=A0of draft-ietf-core-comi-02 states that:
    "Wh= en part of a payload, instance identifiers are encoded in CBOR based on the= rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1"

    Sec= tion 5.13.1 of draft-ietf-core-yang-cbor-05 states that:

    "Singl= e instance data nodes MUST be encoded using a CBOR unsigned integer data it= em (major type 0) and set to the targeted data node SID."

    *** P= lease note that I'm using the single instance identifier case for a mat= ter of clarity but the same applies for list instance identifier.

    S= o according to the sentences above, a single instance identifier that is a = part of a payload can only be an unsigned int.

    draft-ietf-core-comi-= 02 also states that FETCH request format must be:
    "The FETCH reques= t payload contains a list of instance-identifier encoded based on the rules= defined by Content-Format application/yang-selectors+cbor in Section 2.5&q= uot;

    application/yang-selectors+cbor is defined in Section 2.5 as:
    "represents a CBOR YANG document containing a list of data node = selectors (i.e. instance identifier)."

    Moreover, Se= ction 2.5 clearly recall this:
    "YANG instance identifier, encoded based on the rul= es defined in=C2=A0[I-D.ietf-core-ya= ng-cbor] section 5.13.1."

    So the FETCH request payload can only be= made of instance identifier which are de-facto unsigned int (in the single= instance identifier case) based on Section 2.3 and 5.13.1. However, due to= the usage of delta SID for=20 application/yang-selectors+cbor=C2=A0forma= t, some instance identifier of a FETCH request can be negative (as shown in= FETCH example in=C2=A0draft-ietf-core-comi-02). In fact, it seems that the= sentence "When part of a payload, instance = identifiers are encoded in CBOR based on the rules defined in [I-D.ietf-cor= e-yang-cbor] section 5.13.1"=C2=A0is most of the time supersede= d by DeltaSID usage.=C2=A0

    So IMO, it's a little bit confusing a= nd something may need to be added.

    Tanguy Rop= itault (Acklio)

    --94eb2c0952a200d4880568962745-- From nobody Thu Mar 29 20:51:55 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FBE129C56 for ; Thu, 29 Mar 2018 20:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335] 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 8jgpP7-THm6U for ; Thu, 29 Mar 2018 20:51:52 -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 DA136124205 for ; Thu, 29 Mar 2018 20:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2U3plHP017148; Fri, 30 Mar 2018 05:51:47 +0200 (CEST) Received: from [10.216.97.133] (unknown [210.161.158.140]) (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 40C7353Ch6zDXGX; Fri, 30 Mar 2018 05:51:45 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-0AAF4450-8946-4480-900E-0542DA6DD4ED Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Fri, 30 Mar 2018 12:51:40 +0900 Cc: core@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: To: Tanguy Ropitault Archived-At: Subject: Re: [core] draft-ietf-core-comi-02: SID and Delta SID usage inconsistencies ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 30 Mar 2018 03:51:55 -0000 --Apple-Mail-0AAF4450-8946-4480-900E-0542DA6DD4ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Tanguy, SIDs are unsigned, indeed. They are sometimes encoded as deltas. We need to s= top calling those deltas SIDs. They aren't. If you find any place in the doc= ument where that is the case, please identify them. SID deltas are not confu= sing if they are not deliberately mixed up with SIDs.=20 Sent from mobile > On 30. Mar 2018, at 09:16, Tanguy Ropitault w= rote: >=20 > Hi, > I'm wondering if there may be some inconsistencies between SID definition i= n draft-ietf-core-yang-cbor-05 and its usage in draft-ietf-core-comi-02.=20 > The short version of the story is: > - draft-ietf-core-yang-cbor-05 defines SID as an unsigned integer "YANG Sc= hema Item iDentifier (SID): Unsigned integer used to identify different YANG= items." > - draft-ietf-core-comi-02 uses in some sections and examples SID with a ne= gative value (or to be sharp, use delta SID where SID should be normally use= d) >=20 > Let's use an example for the long version of the story: >=20 > Section 2.3 of draft-ietf-core-comi-02 states that: > "When part of a payload, instance identifiers are encoded in CBOR based on= the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" >=20 > Section 5.13.1 of draft-ietf-core-yang-cbor-05 states that: >=20 > "Single instance data nodes MUST be encoded using a CBOR unsigned integer d= ata item (major type 0) and set to the targeted data node SID." >=20 > *** Please note that I'm using the single instance identifier case for a m= atter of clarity but the same applies for list instance identifier.=20 >=20 > So according to the sentences above, a single instance identifier that is a= part of a payload can only be an unsigned int. >=20 > draft-ietf-core-comi-02 also states that FETCH request format must be: > "The FETCH request payload contains a list of instance-identifier encoded b= ased on the rules defined by Content-Format application/yang-selectors+cbor i= n Section 2.5" >=20 > application/yang-selectors+cbor is defined in Section 2.5 as: >=20 > "represents a CBOR YANG document containing a list of data node selectors (= i.e. instance identifier)." >=20 > Moreover, Section 2.5 clearly recall this: > "YANG instance identifier, encoded based on the rules defined in [I-D.ietf= -core-yang-cbor] section 5.13.1." >=20 > So the FETCH request payload can only be made of instance identifier which= are de-facto unsigned int (in the single instance identifier case) based on= Section 2.3 and 5.13.1. However, due to the usage of delta SID for applicat= ion/yang-selectors+cbor format, some instance identifier of a FETCH request c= an be negative (as shown in FETCH example in draft-ietf-core-comi-02). In fa= ct, it seems that the sentence "When part of a payload, instance identifiers= are encoded in CBOR based on the rules defined in [I-D.ietf-core-yang-cbor]= section 5.13.1" is most of the time superseded by DeltaSID usage.=20 >=20 > So IMO, it's a little bit confusing and something may need to be added. >=20 > Tanguy Ropitault (Acklio) >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail-0AAF4450-8946-4480-900E-0542DA6DD4ED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tanguy,

    SIDs are unsi= gned, indeed. They are sometimes encoded as deltas. We need to stop calling t= hose deltas SIDs. They aren't. If you find any place in the document where t= hat is the case, please identify them. SID deltas are not confusing if they a= re not deliberately mixed up with SIDs. 

    Sent from mobile
    <= div>
    On 30. Mar 2018, at 09:16, Tanguy Ropitault <tanguy.ropitault@gmail.com> wrote:

    <= /div>
    Hi,
    I'm wondering if= there may be some inconsistencies between SID definition in draft-ietf-core= -yang-cbor-05 and its usage in draft-ietf-core-comi-02. 
    The short v= ersion of the story is:
    - draft-ietf-core-yang-cbor-05 defines SID as an u= nsigned integer "YANG Schema Item iDentifier (SID): Unsigned integer used to= identify different YANG items."
    - draft-ietf-core-comi-02 uses in s= ome sections and examples SID with a negative value (or to be sharp, use del= ta SID where SID should be normally used)

    Let's use an example for the long version of the story:
    Section 2.3  of draft-ietf-core-comi-02 states that:
    "When part of a= payload, instance identifiers are encoded in CBOR based on the rules define= d in [I-D.ietf-core-yang-cbor] section 5.13.1"

    Section 5.13.1 of draf= t-ietf-core-yang-cbor-05 states that:

    "Single instance data nodes MUS= T be encoded using a CBOR unsigned integer data item (major type 0) and set t= o the targeted data node SID."

    *** Please note that I'm using the sin= gle instance identifier case for a matter of clarity but the same applies fo= r list instance identifier.

    So according to the sentences above, a s= ingle instance identifier that is a part of a payload can only be an unsigne= d int.

    draft-ietf-core-comi-02 also states that FETCH request format m= ust be:
    "The FETCH request payload contains a list of instance-identifier= encoded based on the rules defined by Content-Format application/yang-selec= tors+cbor in Section 2.5"

    application/yang-selectors+cbor is defined i= n Section 2.5 as:

    "represents a CBOR YANG document containing a list o= f data node selectors (i.e. instance identifier)."

    Moreov= er, Section 2.5 clearly recall this:
    "YANG instance identifier, encoded based on the rule= s defined in [I-D.ietf-core-yang-c= bor] section 5.13.1."

    So the FETCH request payload can only be made of insta= nce identifier which are de-facto unsigned int (in the single instance ident= ifier case) based on Section 2.3 and 5.13.1. However, due to the usage of de= lta SID for=20 application/yang-selectors+cbor format, som= e instance identifier of a FETCH request can be negative (as shown in FETCH e= xample in draft-ietf-core-comi-02). In fact, it seems that the sentence= "When part of a payload, instance identifiers are enco= ded in CBOR based on the rules defined in [I-D.ietf-core-yang-cbor] section 5= .13.1" is most of the time superseded by DeltaSID usage. 
    So IMO, it's a little bit confusing and something may need to be added= .

    Tanguy Ropitault (Acklio)

    ____________________= ___________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/mailman= /listinfo/core
    = --Apple-Mail-0AAF4450-8946-4480-900E-0542DA6DD4ED-- From nobody Fri Mar 30 03:39:36 2018 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 94F431200A0; Fri, 30 Mar 2018 03:39:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152240637454.20532.5020630750231797017@ietfa.amsl.com> Date: Fri, 30 Mar 2018 03:39:34 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 10:39:34 -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 WG of the IETF. Title : Object Security for Constrained RESTful Environments (OSCORE) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-12.txt Pages : 72 Date : 2018-03-30 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-12 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-12 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 Mar 30 03:44:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10212D7E8 for ; Fri, 30 Mar 2018 03:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 UUmO0Egw1CP4 for ; Fri, 30 Mar 2018 03:44:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E922A12D7E4 for ; Fri, 30 Mar 2018 03:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522406679; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aSPABEokEJvIHtdkBEaXgrljUpOHasaHj3XILCASldE=; b=LuO/Blp6Gy7L0QW6M3JZmoV/UMuCbXMdaPVsgzQqQoHk6+uVBviIGEXinLU6eEzF qOyh4Bvel+X2m3vEP0AQmjvsyko00Jk6a7Bfl8Iy+dezJZnTlSU1yTBAIK9AlW1z S84jp6m7eppRfdafZ0Xl1HuZ1ZUjsvijIJP5dVW9PQ0=; X-AuditID: c1b4fb3a-e21ff70000005d56-d8-5abe1517762c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.23.23894.7151EBA5; Fri, 30 Mar 2018 12:44:39 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.243]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0382.000; Fri, 30 Mar 2018 12:44:38 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: New Version Notification for draft-ietf-core-object-security-12.txt Thread-Index: AQHTyBNmxL3loroPoUSXStw9BfCnj6PomAuA Date: Fri, 30 Mar 2018 10:44:38 +0000 Message-ID: References: <152240637481.20532.13291350008033663118.idtracker@ietfa.amsl.com> In-Reply-To: <152240637481.20532.13291350008033663118.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.252.126.178] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbE9SldcdF+UwYKvghb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxosJF1kKjuhUvPlzg6mBcYN2FyMnh4SAicSMuW/Yuhi5OIQE jjBK/Pq7iRHCWcIoMW/vASaQKjYBF4kHDY/AbBEBZYnNZ14zgtjCAkESk64fYIeIB0v0Hb7G AmEbSXzuP8kGYrMIqErMfdgFVsMrYCGxauspsF4hAT+Jn7vnsoLYnAL+Eh833GAGsRkFxCS+ n1oDtotZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B9Yr6iAnsTennY2iLiSxO3NDUC7OIB6NSXW 79KHGGMtcbX5HiOErSgxpfsh1DmCEidnPmGZwCg2C8m2WQjds5B0z0LSPQtJ9wJG1lWMosWp xcW56UZGeqlFmcnFxfl5enmpJZsYgRF0cMtvqx2MB587HmIU4GBU4uFVer83Sog1say4MvcQ owQHs5IIr9VJoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFepzSLKCGB9MSS1OzU1ILUIpgsEwen VAOjotTpHYUPpfazzLR6z8fTFGd5ePvyzq7197J4ebftCGT6wvw10opTJDH4kFRbzkqBl1dv PhCyeynnYCX9IOpsgMeMIKOYI+ejGqV3zmK8kV4d6h/ieTEvxe61jvQhbeaOOZOvaIhE3ck8 17vCv3j9vomTn19bZO13XoPlEOM0o78TmX8FxrgrsRRnJBpqMRcVJwIAsvlz8pwCAAA= Archived-At: Subject: [core] FW: New Version Notification for draft-ietf-core-object-security-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 30 Mar 2018 10:44:45 -0000 SGVsbG8sDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgT1NDT1JFIHdoaWNo IHdlIGJlbGlldmUgYWRkcmVzc2VzIHRoZQ0KcmVtYWluaW5nIGNvbW1lbnRzIGZyb20gSUVTRyBh bmQgTWFydGluIFRob21zb24ncyBkZXRhaWxlZCBjb21tZW50cy4NCkp1ZGdpbmcgYnkgdGhlIHJl dmlld3MgdGhlcmUgd2FzIGEgbmVlZCBmb3IgZnVydGhlciBjbGFyaWZpY2F0aW9ucyBzbyBzb21l DQplZmZvcnQgaGFzIGJlZW4gc3BlbnQgaW4gcmVwaHJhc2luZyBhbmQgc3BlbGxpbmcgb3V0IHRo ZSBhc3N1bXB0aW9ucyBhbmQNCnByb2Nlc3Npbmcgc3RlcHMuIFRoaXMgcmVzdWx0ZWQgaW4gcXVp dGUgYSBmZXcgY2hhbmdlcywgc2VlIGJlbG93LCBidXQNCm1vc3QgYXJlIGFib3V0IHByb3ZpZGlu ZyBtb3JlIGV4cGxhbmF0aW9ucy4NCg0KTWVhbndoaWxlIHdlIHJlY2VpdmVkIHNvbWUgZGV0YWls ZWQgY29tbWVudHMNCihodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2NvYXAvaXNzdWVzLzIy MCkgZnJvbSBhIG5ldyBpbXBsZW1lbnRlciB0aGF0DQp3ZSBoYXZlIGFsc28gYWRkcmVzc2VkLg0K DQpUaGUgY2hhbmdlcyBhcmU6DQoNCi0gRWtyJ3MgY29tbWVudHMgb24gdGhlIHRlcm0gImJpbmRp bmciIG9mIHJlc3BvbnNlIHRvIHJlcXVlc3QgcmVxdWlyZWQNCmZ1cnRoZXIgY2xhcmlmaWNhdGlv bnMgb24gdGhlIGFzc3VtcHRpb25zIG9mIHRoZSBzZXJ2ZXIuDQoNCi0gUmVuYW1lZCB0aGUgb3B0 aW9uIGFuZCBoZWFkZXIgZmllbGQgIk9TQ09SRSIgYXMgYWdyZWVkIGluIHRoZSBGMkYNCm1lZXRp bmcuDQoNCi0gUmVzdHJ1Y3R1cmluZzogY29sbGVjdGluZyB0ZXh0IG9mIHJlbGF0ZWQgY29udGVu dCBpbiBvbmUgcGxhY2U7DQpyZW9yZGVyaW5nIG9mIHNlY3Rpb25zIGFuZCBjaGFuZ2luZyBuYW1l cyBvZiBzZWN0aW9uIGhlYWRpbmdzDQoNCi0gTm90aWZpY2F0aW9uIHJlcGxheSBwcm90ZWN0aW9u IHdhcyBvdmVybHkgcmVzdHJpY3RpdmUgY29tcGFyZSB0byBSRkMNCjc2NDEsIHdoaWNoIGRvZXMg bm90IHJlcXVpcmUgZHJvcHBpbmcgYWxsIGJ1dCB0aGUgZnJlc2hlc3QuIE90aGVyIE9ic2VydmUN CmludGVybWVkaWFyeSBwcm9jZXNzaW5nLg0KDQotIFJlbW92ZWQgdGhlICIqIiBmcm9tIEZpZ3Vy ZSA1OiB0aGlzIGluZm9ybWF0aW9uIGlzIHJlZHVuZGFudCBzaW5jZSB0aGVyZQ0KaXMgYSBzZWN0 aW9uIGRlc2NyaWJpbmcgdGhlIHNwZWNpYWwgb3B0aW9ucy4NCg0KLSBUaGUgcmVzcG9uc2UgY29k ZSB0byB0aGUgZHVtbXkgRkVUQ0ggd2FzIGNoYW5nZWQgZnJvbSAyLjA0IHRvIDIuMDUsDQp3aGlj aCBjb3VsZCBvdGhlcndpc2UgY29uZnVzZSBpbnRlcm1lZGlhcmllcy4NCg0KLSBTaW1wbGlmeWlu ZyBwcm9jZXNzaW5nIHdoZW4gc3RvcmluZyBzZXF1ZW5jZSBudW1iZXIgdG8gcGVyc2lzdGFudA0K c3RvcmFnZS4NCg0KLSBBbiBleGFtcGxlIG9mIHdlYiBsaW5raW5nIChyZXF1ZXN0ZWQgYnkgTWFy dGluIFRob21zb24pLg0KDQotIFNwbGl0IG9mIHNlY3Rpb24gIjEwLiBQcm94eSBhbmQgSFRUUCBP cGVyYXRpb25zIiBpbnRvICIxMC4gQ29BUC10by1Db0FQDQpGb3J3YXJkaW5nIFByb3h5IiBhbmQg IjExLiBIVFRQIE9wZXJhdGlvbnPigJ0uIFRoZSBsYXR0ZXIgd2FzIHJlc3RydWN0dXJlZA0KdG8g YXZvaWQgcmVwZXRpdGlvbiBvZiBwcm9jZXNzaW5nIHN0ZXBzLg0KDQotIENvcnJlY3Rpb24gb2Yg dGhlIGFwcGxpY2FiaWxpdHkgb2YgSFRUUCBWYXJ5OiB0aGlzIGlzIG5vdCByZWxldmFudCB3aGVu DQpPU0NPUkUgbWVzc2FnZXMgYXJlIHRyYW5zcG9ydGVkIHdpdGggSFRUUCBzaW5jZSBhIGNhY2hl ZCBtZXNzYWdlIGlzIG5vdA0KdXNlZnVsIGZvciBhbnkgb3RoZXIgY2xpZW50Lg0KDQotIERlZmlu aW5nIHRoZSBDb250ZW50LUZvcm1hdCB2YWx1ZSBmb3IgdGhlIE9TQ09SRSBNZWRpYS1UeXBlIGFz IGFncmVlZCBpbg0KdGhlIGYyZiBtZWV0aW5nLg0KDQotIEV4cGFuZGVkIG9uIHNlY3VyaXR5IGNv bnRleHQgZXN0YWJsaXNobWVudCAocmVxdWVzdGVkIGJ5IEthdGhsZWVuDQpNb3JpYXJ0eSkNCg0K LSBOZXcgc2VjdGlvbiBvbiBNYXN0ZXIgU2VjcmV0LiBSZXF1aXJlbWVudHMgb24gTWFzdGVyIFNl Y3JldCB3YXMgb3Zlcmx5DQpyZXN0cmljdGl2ZSwgZG9lcyBub3QgaGF2ZSB0byBiZSB1bmlmb3Jt bHkgZGlzdHJpYnV0ZWQuDQoNCi0gTW92ZWQgc2VjdGlvbiBvbiAiY2xpZW50IGFsaXZlbmVzcyIg ZnJvbSBhcHBlbmRpeCBpbnRvIHNlY3VyaXR5DQpjb25zaWRlcmF0aW9ucw0KDQotIFJlcGxhY2Vk IGRldGFpbGVkIHF1YW50aWZpY2F0aW9uIG9mIHNlY3VyaXR5IGxldmVsIHZhbGlkIHVuZGVyIGNl cnRhaW4NCmFzc3VtcHRpb25zIHdpdGggcHJvcGVydHkgb2YgdGhlIG5vbmNlIGNvbnN0cnVjdGlv bi4NCg0KLSBDYXZlYXQgb24gbWFzdGVyIHNhbHQgcmV1c2UNCg0KLSBNb3JlIGRldGFpbGVkIGNv bnNpZGVyYXRpb25zIG9uIHVucHJvdGVjdGVkIGhlYWRlcnMuDQoNCg0KUmVnYXJkcywNCkfDtnJh bg0KDQoNCg0KDQpPbiAyMDE4LTAzLTMwLCAxMjozOSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyINCjxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTIudHh0DQo+aGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHw7ZyYW4gU2VsYW5kZXIgYW5kIHBvc3RlZCB0 byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHkNCj5SZXZpc2lvbjoJMTINCj5UaXRsZToJCU9iamVjdCBTZWN1cml0eSBmb3Ig Q29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMgKE9TQ09SRSkNCj5Eb2N1bWVudCBkYXRl OgkyMDE4LTAzLTMwDQo+R3JvdXA6CQljb3JlDQo+UGFnZXM6CQk3Mg0KPlVSTDogICAgICAgICAg ICANCj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jb3Jl LW9iamVjdC1zZWN1cml0eS0xMi50eA0KPnQNCj5TdGF0dXM6ICAgICAgICAgDQo+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS8N Cj5IdG1saXplZDogICAgICAgDQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTINCj5IdG1saXplZDogICAgICAgDQo+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3Vy aXR5DQo+RGlmZjogICAgICAgICAgIA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTEyDQo+DQo+QWJzdHJhY3Q6DQo+ICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIE9iamVjdCBTZWN1cml0eSBmb3IgQ29uc3RyYWluZWQgUkVT VGZ1bA0KPiAgIEVudmlyb25tZW50cyAoT1NDT1JFKSwgYSBtZXRob2QgZm9yIGFwcGxpY2F0aW9u LWxheWVyIHByb3RlY3Rpb24gb2YNCj4gICB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJv dG9jb2wgKENvQVApLCB1c2luZyBDQk9SIE9iamVjdA0KPiAgIFNpZ25pbmcgYW5kIEVuY3J5cHRp b24gKENPU0UpLiAgT1NDT1JFIHByb3ZpZGVzIGVuZC10by1lbmQgcHJvdGVjdGlvbg0KPiAgIGJl dHdlZW4gZW5kcG9pbnRzIGNvbW11bmljYXRpbmcgdXNpbmcgQ29BUCBvciBDb0FQLW1hcHBhYmxl IEhUVFAuDQo+ICAgT1NDT1JFIGlzIGRlc2lnbmVkIGZvciBjb25zdHJhaW5lZCBub2RlcyBhbmQg bmV0d29ya3Mgc3VwcG9ydGluZyBhDQo+ICAgcmFuZ2Ugb2YgcHJveHkgb3BlcmF0aW9ucywgaW5j bHVkaW5nIHRyYW5zbGF0aW9uIGJldHdlZW4gZGlmZmVyZW50DQo+ICAgdHJhbnNwb3J0IHByb3Rv Y29scy4NCj4NCj4gICAgICAgICAgICAgICAgICANCj4gICAgICAgIA0KPg0KPg0KPlBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m DQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4N Cg0K From nobody Fri Mar 30 04:03:57 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189B61200A0 for ; Fri, 30 Mar 2018 04:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Hx9qj8JJl1Jm for ; Fri, 30 Mar 2018 04:03:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 8A0CB12D7E5 for ; Fri, 30 Mar 2018 04:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522407819; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6OWvuBXE4B1kiMcHLN3fF05rb9EpUNEBjJ/2Itzz6dw=; b=LP+jdQczfaZ2rPdthSwlMJVXDIeOTSTolYVDsI4BORWBr56nIEzk1x9LKud2l8LB JmqH1PUKRVf3OM/VCgYhOGA2xrYnXWMD+F46D7jZyhDmnVVYI3vZxfvVxAa5NoKt rBwqO4GVGygTAmHnXtlj7docZgxKsU7KmbLDJ+PiW8o=; X-AuditID: c1b4fb2d-e31ff700000073d9-40-5abe198a6666 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.38.29657.A891EBA5; Fri, 30 Mar 2018 13:03:39 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0382.000; Fri, 30 Mar 2018 13:03:38 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Roni Even CC: "gen-art@ietf.org" , "ietf@ietf.org" , "core@ietf.org" , "draft-ietf-core-senml.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-core-senml-13 Thread-Index: AQHTxlenmfCuQp7tKkSc1i2gojum5aPof0qA Date: Fri, 30 Mar 2018 11:03:38 +0000 Message-ID: <16FAE862-3F10-4325-AB87-5DF31FBADF09@ericsson.com> References: <152221578820.29905.10455247933119493699@ietfa.amsl.com> In-Reply-To: <152221578820.29905.10455247933119493699@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2J7iG635L4og98zeSz2vV3PbHHu4RYm i6uvPrNYPNs4n8XibzuzA6vHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUx75FOQRt3xeuJ O9kaGF9wdDFyckgImEh8u3WJpYuRi0NI4AijxIG/V9khnCWMEvM+TWMGqWITsJeYvOYjI4gt IqAm8XrtZzYQm1lgF6PErz/VILawgIPE6q4JLBA1jhLTe89D1RtJNJw/BDSHg4NFQFVi+uZQ kDAv0MjF2xvBSoQEXCTm31wDNpJTwFVi3o+NrCA2o4CYxPdTa5ggVolL3HoynwniaAGJJXvO M0PYohIvH/9jhbDlJWacvQVVrydxY+oUqDOtJR70n4aytSWWLXzNDHGDoMTJmU9YJjCKzUKy YhaS9llI2mchaZ+FpH0BI+sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMCIO7jlt+4OxtWv HQ8xCnAwKvHwhkrsixJiTSwrrsw9xCjBwawkwmt1cm+UEG9KYmVValF+fFFpTmrxIUZpDhYl cV69VXuihATSE0tSs1NTC1KLYLJMHJxSDYzqmwW2PbL8xLT10qRZjnl7JhuemP9k56uFQg0B hYwRd++qOYrF+5vFTZgue7/OwmVn65rSywzbgrpuFHnO18gPYT86M29WttM8tWjDZsYFnRO5 uxRkEg3PppWHaU9I8fSsjTpYdf9vydVzPMkmJSsEa075aTBkhp5lFi498OecvGrQ9YIt/5VY ijMSDbWYi4oTAQs+Tde0AgAA Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-senml-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 30 Mar 2018 11:03:50 -0000 Thank you for the review Roni! Good catches.=20 Seems we forgot to update the EXI example offsets when regenerated the exam= ples. I made a PR to include these fixes in the next revision: https://gith= ub.com/core-wg/senml-spec/pull/102/files Cheers, Ari > On 28 Mar 2018, at 8.43, Roni Even wrote: >=20 > Reviewer: Roni Even > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-senml-?? > Reviewer: Roni Even > Review Date: 2018-03-27 > IETF LC End Date: 2018-03-30 > IESG Telechat date: 2018-04-19 >=20 > Summary: > The document is ready for publication as a standard track RFC with nits >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 > 1. in section 5.1.6 "another devices" should be "other devices" or "anoth= er > device" 2. in section 8 "It can simply hard code the output replacing th= e > 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's d= evice > ID". I think that the offset ix 0x10 to 0x1f >=20 >=20 From nobody Fri Mar 30 04:04:29 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ACE12E88E for ; Fri, 30 Mar 2018 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 woz7beQHfkiR for ; Fri, 30 Mar 2018 04:04:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D696A12E882 for ; Fri, 30 Mar 2018 04:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522407835; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Sl0PDkqbf5IAmGqEMYWvu5Fk38SfrNii1nzGLFdf+3o=; b=V/24JHXySTxP7Awog6etIULKvbFEVKQWafhEuhBtDVAo9J0tVxV4nwzeacf+2Rr4 CAyvaGWL8I1hS1Z2TZq1wPG4Fq6Okmn3K6/u2/36rwVu5r2X5NpLGmBLKCV34eeg 8JElfLvS3UpQgdRvcGwgjfSYVo5Mk6FMhWcIP8Uh+mU=; X-AuditID: c1b4fb25-1dfff7000000522b-9b-5abe199beb15 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.F0.21035.B991EBA5; Fri, 30 Mar 2018 13:03:55 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.243]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0382.000; Fri, 30 Mar 2018 13:03:54 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eric Rescorla , The IESG CC: "draft-ietf-core-object-security@ietf.org" , Carsten Bormann , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) Thread-Index: AQHTtolfO1SWXHzYR0WCPxFNrQ+jVKPamoaAgA4l+gA= Date: Fri, 30 Mar 2018 11:03:53 +0000 Message-ID: References: <152047792293.21279.6463990470584540244.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.252.126.178] Content-Type: text/plain; charset="utf-8" Content-ID: <90E1356FFACBB24AAC41CBB42EB95D29@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7h+5syX1RBj9eClscmXKX1WLbxgts Fvverme2mPbvDIvFitfn2C1m/JnI7MDmsWTJTyaPyY/bmD2mLcoMYI7isklJzcksSy3St0vg ytj1tJu5YEYTY8XWDXfZGhjf1HUxcnBICJhIvN/t3cXIxSEkcIRR4v7MFYwQzhJGibOfOlm6 GDk52ARcJB40PGICsUUErCRe/b7GAlLELDCBSeLHhVXsIAlhgQyJ9jevGCGKMiWe7l3PCtPw aQdEnEVAVWLZ0i9gNq+AhcTnA4fAbCGBGon9l6+BzeEUsJRY9foiWJxRQEzi+6k1YIuZBcQl bj2ZD2ZLCAhILNlznhnCFpV4+fgf2C5RAT2JvT3tbBBxJYnbmxvYQb5kFtCUWL9LH8K0luj4 Fw0xUVFiSvdDdohrBCVOznzCMoFRfBaSZbMQmmchNM9C0jwLSfMCRtZVjKLFqcVJuelGxnqp RZnJxcX5eXp5qSWbGIGxeXDLb9UdjJffOB5iFOBgVOLhnf5+b5QQa2JZcWXuIUYJDmYlEV6r k0Ah3pTEyqrUovz4otKc1OJDjNIcLErivA/NN0cJCaQnlqRmp6YWpBbBZJk4OKUaGKV7M/RO Fha9mcRTFm3rXrAhlovhxssCaf7rm39sVfnYUTGtVdHVofubCP/VeQZndjHVzXwW+DRwg/KF RTJ7T4pqPtqSebNx2/RFJ0L22hS8X/JgVum8BbLaLAF6mQ+DN15I3Rrb4NPStG3dhr37dse1 hj0+NG3j4S0KFvL7v2Qou2geSun9b6TEUpyRaKjFXFScCAC0HjSFyQIAAA== Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 30 Mar 2018 11:04:21 -0000 DQo+DQo+SGkgRXJpYywNCg0KVGhhbmtzIGZvciBnb29kIGNvbW1lbnRzLiBWZXJzaW9uIC0xMiBz dWJtaXR0ZWQuIFJlcGxpZXMgaW5saW5lIGxhYmVsbGVkDQpbR1NdLg0KDQoNCj4NCj5FcmljIFJl c2NvcmxhIDxla3JAcnRmbS5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4NCj5kcmFm dC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnDQo+PGRyYWZ0LWlldGYtY29yZS1v YmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc+OyBDYXJzdGVuIEJvcm1hbm4NCj48Y2Fib0B0emkub3Jn PjsgSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPjsNCj5jb3JlLWNo YWlyc0BpZXRmLm9yZyA8Y29yZS1jaGFpcnNAaWV0Zi5vcmc+OyBjb3JlQGlldGYub3JnIDxjb3Jl QGlldGYub3JnPg0KPg0KPk9uIDIwMTgtMDMtMDggMDM6NTgsICJFcmljIFJlc2NvcmxhIiA8ZWty QHJ0Zm0uY29tPiB3cm90ZToNCj4NCj4+RXJpYyBSZXNjb3JsYSBoYXMgZW50ZXJlZCB0aGUgZm9s bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4+ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1 cml0eS0wOTogRGlzY3Vzcw0KPj4NCj4+V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+PmVtYWlsIGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+ PmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4NCj4+DQo+PlBsZWFzZSByZWZl ciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWwNCj4+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01N RU5UIHBvc2l0aW9ucy4NCj4+DQo+Pg0KPj5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIg YmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+Pmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkvDQo+Pg0KPj4N Cj4+DQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+RElTQ1VTUzoNCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+ aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDMwNzUNCj4+DQo+PkRJ U0NVU1MNCj4+TXkgb3ZlcmFsbCBjb25jZXJuIHdpdGggdGhpcyBkb2N1bWVudCBpcyB0aGF0IEkg YW0gdW5hYmxlIHRvIGV2YWx1YXRlDQo+PnRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRoZSBz eXN0ZW0uIEkgaGF2ZSBkZXNjcmliZWQgYSBudW1iZXIgb2YNCj4+aXNzdWVzIGJlbG93LCBidXQg dGhlIGJhc2ljIHByb2JsZW0gaXMgdGhhdCB0aGlzIHNvcnQgb2YgcGFydGlhbA0KPj5wcm90ZWN0 aW9uIGlzIGV4dHJlbWVseSBoYXJkIHRvIHJlYXNvbiBhYm91dCBhbmQgdGhlIHNlY3VyaXR5DQo+ PmNvbnNpZGVyYXRpb25zIGRvIG5vdCBkbyBhbiBhZGVxdWF0ZSBqb2Igb2YgZXZhbHVhdGluZyB0 aGUgaW1wYWN0IG9mDQo+PnByb3hpZXMgbW9kaWZ5aW5nIHRoZXNlIHZhbHVlcy4NCg0KW0dTXSBB IG5ldyBhcHBlbmRpeCAoRCkgaXMgd3JpdHRlbiB3aGljaCBob3BlZnVsbHkgYWRkcmVzc2VzIHRo aXMgY29uY2Vybi4NCj4NCj4+SSBhbSBzaW1pbGFybHkgY29uY2VybmVkIGFib3V0IHRoZQ0KPj5I VFRQIG1hcHBpbmcgYW5kIGxpbmsgc2VjdGlvbiB3aGljaCBzZWVtcyBleHRyZW1lbHkgc2tldGNo eSBhbmQgaGFzDQo+PmVzc2VudGlhbGx5IG5vIHNlY3VyaXR5IGFuYWx5c2lzLCBhbmQgeWV0IHBv dGVudGlhbGx5IGhhdmUgYSBsb3QNCj4+b2YgbGFuZG1pbmVzLg0KDQpbR1NdIFBsZWFzZSBzZWUg b3VyIHJlc3BvbnNlIHRvIE1hcnRpbiBUaG9tc29u4oCZcyByZXZpZXcuDQoNCg0KPj4NCj4+QXQg bWluaW11bSwgdGhpcyBkb2N1bWVudCBuZWVkcyB0byB3YWxrIHRocm91Z2ggdGhlIGltcGxpY2F0 aW9ucw0KPj5vZiBtb2RpZmljYXRpb25zIGJ5IHRoZSBwcm94eSB0byBldmVyeSB1bnByb3RlY3Rl ZCBmaWVsZCBpbg0KPj50aGUgcHVyZSBDb0FQIGNvbnRleHQgYXMgd2VsbCBhcyB0aGUgSFRUUCBj b250ZXh0IChpZiB5b3Ugd2FudA0KPj50byByZXRhaW4gdGhhdCBiaW5kaW5nKS4NCg0KW0dTXSBU aGUgbmV3IGFwcGVuZGl4IEQgd2Fsa3MgdGhyb3VnaCB0aGUgdW5wcm90ZWN0ZWQgQ29BUCBoZWFk ZXJzIGFuZCB0aGUNCnJvbGUgb2YgdGhlIEhUVFAgaGVhZGVycy4gUGxlYXNlIGNoZWNrIGlmIHlv dSBhcmUgaGFwcHkgd2l0aCB0aGlzLg0KDQo+Pg0KPj4gICBhcmUgZ2l2ZW4gaW4gQXBwZW5kaXgg QS4gIE9TQ09SRSBkb2VzIG5vdCBkZXBlbmQgb24gdW5kZXJseWluZw0KPj4gICBsYXllcnMsIGFu ZCBjYW4gYmUgdXNlZCBhbnl3aGVyZSB3aGVyZSBDb0FQIG9yIEhUVFAgY2FuIGJlIHVzZWQsDQo+ PiAgIGluY2x1ZGluZyBub24tSVAgdHJhbnNwb3J0cyAoZS5nLiwgW0ktRC5ib3JtYW5uLTZsby1j b2FwLTgwMi0xNS1pZV0pLg0KPj4NCj4+SU1QT1JUQU5UOiBUaGlzIGRvY3VtZW50IGNsYWltcyB0 byBiZSBhcHBsaWNhYmxlIHRvIHByb3RvY29scyBvdGhlcg0KPj50aGFuIENPQVAsIGluIHBhcnRp Y3VsYXIgSFRUUC4gSGFzIHRoaXMgYmVlbiByZXZpZXdlZCBieSB0aGUgSFRUUA0KPj53b3JraW5n IGdyb3VwPyBNYXJ0aW4gVGhvbXNvbidzIHJldmlldyBzdWdnZXN0cyB0aGF0IHRoaXMgaXMgb3V0 IG9mDQo+PnN0ZXAgd2l0aCBIVFRQIHByYWN0aWNlLg0KPg0KW0dTXSBObywgcHJpb3IgdG8gTWFy dGlu4oCZcyByZXZpZXcgd2UgZGlkIG5vdCBoYXZlIGFuIEhUVFAgZXhwZXJ0IHJldmlldyBzbw0K d2UgYXJlIGdyYXRlZnVsIGZvciBoaXMgcmV2aWV3Lg0KPg0KPj4NCj4+ICAgSURzIE1VU1QgYmUg bG9uZyB1bmlmb3JtbHkgcmFuZG9tIGRpc3RyaWJ1dGVkIGJ5dGUgc3RyaW5ncyBzdWNoIHRoYXQN Cj4+ICAgdGhlIHByb2JhYmlsaXR5IG9mIGNvbGxpc2lvbnMgaXMgbmVnbGlnaWJsZS4NCj4+DQo+ PklNUE9SVEFOVDogSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGlzIHBhcmFncmFwaCBhbmQgdGhl IHByZXZpb3VzDQo+PnBhcmFncmFwaCBpbnRlcmFjdC4gWW91IHNheSB0aGF0IHRoZSBtYXhpbXVt IGxlbmd0aCBpcyA3IG9jdGV0cyBpbiB0aGUNCj4+cHJldmlvdXMgcGFyYWdyYXBoLCB3aGljaCBJ IGRvbid0IHRoaW5rIHF1YWxpZmllcyBhcyAibG9uZyIuDQoNCltHU10gVGhlIFdHIGRpZCBub3Qg Y29uZmlybSBpbnRlcmVzdCBpbiByYW5kb20gSURzIHNvIHdlIGRyb3BwZWQgdGhhdCBhbmQNCnJl d3JvdGUgdGhpcyB0ZXh0IGFjY29yZGluZ2x5Lg0KPg0KPj4NCj4+ICAgICAgICAgICAgICAgICAg ICAgfCAgIDEgfCBJZi1NYXRjaCAgICAgICAgfCB4IHwgICB8DQo+PiAgICAgICAgICAgICAgICAg ICAgIHwgICAzIHwgVXJpLUhvc3QgICAgICAgIHwgICB8IHggfA0KPj4gICAgICAgICAgICAgICAg ICAgICB8ICAgNCB8IEVUYWcgICAgICAgICAgICB8IHggfCAgIHwNCj4+SU1QT1JUQU5UOiBXaHkg ZG8geW91IHRoaW5rIHRoYXQgaXQncyBub3QgaW1wb3J0YW50IHRvIGhhdmUgaW50ZWdyaXR5DQo+ PnByb3RlY3Rpb24gZm9yIFVyaS1Ib3N0IGFuZCBVcmktcG9ydD8NCg0KW0dTXSBUaGUgVXJpLUhv c3QgYW5kIFVyaS1Qb3J0IG1heSBiZSBjaGFuZ2VkIGJ5IGEgQ29BUCBwcm94eSBzbyBjYW5ub3Qg YmUNCmludGVncml0eSBwcm90ZWN0ZWQgZW5kLXRvLWVuZC4gVGhpcyBpcyBkaXNjdXNzZWQgaW4g dGhlIG5ldyBELjQuDQo+DQo+Pg0KPj4gICBPdXRlciBvcHRpb24gbWVzc2FnZSBmaWVsZHMgKENs YXNzIFUgb3IgSSkgYXJlIHVzZWQgdG8gc3VwcG9ydCBwcm94eQ0KPj4gICBvcGVyYXRpb25zLg0K Pj5JTVBPUlRBTlQ6IFRoaXMgc2VlbXMgcHJvYmxlbWF0aWMgYmVjYXVzZSB0aGUgcHJveHkgY2Fu bm90IHZlcmlmeSBjbGFzcyBJDQo+PmZpZWxkcy4NCj4NCg0KW0dTXSDigJxzdXBwb3J0IHByb3h5 IG9wZXJhdGlvbnPigJ0gbWVhbnMgYWxsb3dpbmcgYSBwcm94eSBwZXJmb3JtIGl0cw0KaW50ZW5k ZWQgb3BlcmF0aW9uLiBXZSBoYXZlIHRyaWVkIHRvIGNsYXJpZnkgdGhpcyBpbiBhcHBlbmRpeCBE LjEuDQo+DQo+Pg0KPj4gICBsYXllciBvbmx5LCBhbmQgbm90IHRoZSBNZXNzYWdpbmcgTGF5ZXIg KFNlY3Rpb24gMiBvZiBbUkZDNzI1Ml0pLCBzbw0KPj4gICBmaWVsZHMgc3VjaCBhcyBUeXBlIGFu ZCBNZXNzYWdlIElEIGFyZSBub3QgcHJvdGVjdGVkIHdpdGggT1NDT1JFLg0KPj4NCj4+SU1QT1JU QU5UOiBUaGlzIHNlZW1zIGV4dHJlbWVseSBoYXJkIHRvIHJlYXNvbiBhYm91dC4gV2hhdCBhcmUg dGhlDQo+PmltcGxpY2F0aW9ucyBvZiB0aGUgcHJveHkgYmVpbmcgYWJsZSB0byBjaGFuZ2UgdGhl c2U/DQoNCltHU10gVGhlc2UgYXJlIFVEUCBiaW5kaW5nIHBhcmFtZXRlcnMgd2hpY2ggYSBwcm94 eSBpcyBlbnRpdGxlZCB0byBjaGFuZ2UNCnNvIGNhbm5vdCBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVk IGVuZC10by1lbmQuIERpc2N1c3NlZCBpbiB0aGUgbmV3IGFwcGVuZGl4DQpELjQNCj4NCj4+DQo+ PiAgIG8gIHJlcXVlc3RfcGl2OiBjb250YWlucyB0aGUgdmFsdWUgb2YgdGhlICdQYXJ0aWFsIElW JyBpbiB0aGUgQ09TRQ0KPj4gICAgICBvYmplY3Qgb2YgdGhlIHJlcXVlc3QgKHNlZSBTZWN0aW9u IDUpLg0KPj4NCj4+SU1QT1JUQU5UOiBJIHRoaW5rIHdoYXQgSSBhbSBnZXR0aW5nIGhlcmUgaXMg dGhhdCB0aGUgcmVxdWVzdF9waXYgaXMNCj4+dXNlZCB0byB2ZXJpZnkgdGhhdCB0aGUgcmVxdWVz dCBhbmQgcmVzcG9uc2UgbWF0Y2guIEhvd2V2ZXIsIEkgZG8gbm90DQo+PnNlZSB0aGlzIGV4cGxp Y2l0bHkgc3RhdGVkIGFueXdoZXJlLCBhbmQgaXQncyBub3QgY2xlYXIgdG8gbWUgaG93IHRoZQ0K Pj5jbGllbnQgaXMgc3VwcG9zZWQgdG8gcmVjb3ZlciB0aGUgcmVxdWVzdF9waXYgYW5kIHRoZSB0 ZXh0IGlzIHByZXR0eQ0KPj51bmNsZWFyIGhlcmU/IElzIHRoZSBleHRlcm5hbF9hYWQgY2Fycmll ZCBzb21ld2hlcmUgaW4gdGhlIG1lc3NhZ2U/IEFtDQo+Pkkgc3VwcG9zZWQgdG8gcmVjb25zdHJ1 Y3QgaXQgZnJvbSB0aGUgbWVzc2FnZSBpZD8NCj4NCltHU10gVGhlIHJlcXVlc3RfcGl2IGlzIGlu dGVuZGVkIHRvIGJlIGNhY2hlZCBieSB0aGUgY2xpZW50LCB0aGF0IHdhc27igJl0DQpzdWZmaWNp ZW50bHkgY2xlYXIuIFNlZSBuZXcgdGV4dCBpbiBzdGVwIDYgb2Ygc2VjdGlvbiA4LjENCg0KPj4N Cj4+ICAgRm9yIHJlc3BvbnNlcywgdGhlIG1lc3NhZ2UgYmluZGluZyBndWFyYW50ZWVzIHRoYXQg YSByZXNwb25zZSBpcyBub3QNCj4+ICAgb2xkZXIgdGhhbiBpdHMgcmVxdWVzdC4gIEZvciByZXNw b25zZXMgd2l0aG91dCBPYnNlcnZlLCB0aGlzIGdpdmVzDQo+Pg0KPj5JTVBPUlRBTlQ6IEkgYW0g bm90IHN1cmUgdGhhdCB0aGlzIGlzIHRydWUuIFdoYXQgaGFwcGVucyBvZiB0aGUNCj4+Y291bnRl cnBhcnR5IGxpZXM/IFdoYXQgaXMgeW91ciB0aHJlYXQgbW9kZWw/DQoNCj4NCltHU10gVGhlIGNs aWVudCBhbmQgc2VydmVyIGFyZSBhc3N1bWVkIHRvIGJlIGhvbmVzdC4gVGhpcyBtZWNoYW5pc20g aXMNCmludGVuZGVkIHRvIGFkZHJlc3MgYXR0YWNrcyBmcm9tIG90aGVyIHBhcnRpZXMuIFdlIGhh dmUgdHJpZWQgdG8gY2xhcmlmeQ0KdGhpcyBpbiBELjEuDQoNCg0KPj4NCj4+ICAgQW4gZXh0ZW5z aW9uIG9mIE9TQ09SRSBtYXkgYWxzbyBiZSB1c2VkIHRvIHByb3RlY3QgZ3JvdXANCj4+ICAgY29t bXVuaWNhdGlvbiBmb3IgQ29BUCBbSS1ELnRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXBdLiAg VGhlIHVzZQ0KPj4gICBvZiBPU0NPUkUgZG9lcyBub3QgYWZmZWN0IHRoZSBVUkkgc2NoZW1lIGFu ZCBPU0NPUkUgY2FuIHRoZXJlZm9yZSBiZQ0KPj4gICB1c2VkIHdpdGggYW55IFVSSSBzY2hlbWUg ZGVmaW5lZCBmb3IgQ29BUCBvciBIVFRQLiAgVGhlIGFwcGxpY2F0aW9uDQo+PiAgIGRlY2lkZXMg dGhlIGNvbmRpdGlvbnMgZm9yIHdoaWNoIE9TQ09SRSBpcyByZXF1aXJlZC4NCj4+DQo+PlRoaXMg aXMgcHJldHR5IHN1cnByaXNpbmcgdG8ganVzdCBkcm9wIGluIGhlcmUuIE11bHRpY2FzdCBoYXMg dG90YWxseQ0KPj5kaWZmZXJlbnQNCj4+c2VjdXJpdHkgcHJvcGVydGllcyBmcm9tIG5vbi1tdWx0 aWNhc3QuDQo+Pg0KDQpbR1NdIFRoaXMgdGV4dCBpcyB0YWtlbiBvdXQuDQo+DQo+Pg0KPj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+PkNPTU1FTlQ6DQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+Pg0KPj4NCj4+ICAg YnV0IGlzIGFsc28gYWJsZSB0byBlYXZlc2Ryb3Agb24sIG9yIG1hbmlwdWxhdGUgYW55IHBhcnQg b2YgdGhlDQo+PiAgIG1lc3NhZ2UgcGF5bG9hZCBhbmQgbWV0YWRhdGEsIGluIHRyYW5zaXQgYmV0 d2VlbiB0aGUgZW5kcG9pbnRzLiAgVGhlDQo+PiAgIHByb3h5IGNhbiBhbHNvIGluamVjdCwgZGVs ZXRlLCBvciByZW9yZGVyIHBhY2tldHMgc2luY2UgdGhleSBhcmUgbm8NCj4+Tml0OiB5b3Ugd2Fu dA0KPj4iZWF2ZXNkcm9wIG9uLCBvciBtYW5pcHVsYXRlIGFueSBwYXJ0IG9mLCB0aGUgbWVzc2Fn ZSBwYXlsb2FkIGFuZA0KPj5tZXRhZGF0YSBpbg0KPj50cmFuc2l0Ig0KPj4NCj4+SS5lLiwgbW92 ZSB0aGUgc2Vjb25kIGNvbW1hDQoNCltHU10gRG9uZS4NCg0KPg0KPj4gICB0aGUgZW5kcG9pbnRz LCBhbmQgdGhvc2UgYXJlIHRoZXJlZm9yZSBwcm9jZXNzZWQgYXMgZGVmaW5lZCBpbg0KPj4gICBb UkZDNzI1Ml0uICBBZGRpdGlvbmFsbHksIHNpbmNlIHRoZSBtZXNzYWdlIGZvcm1hdHMgZm9yIENv QVAgb3Zlcg0KPj4gICB1bnJlbGlhYmxlIHRyYW5zcG9ydCBbUkZDNzI1Ml0gYW5kIGZvciBDb0FQ IG92ZXIgcmVsaWFibGUgdHJhbnNwb3J0DQo+Pk5pdDogIk9TQ09SRSBwcm90ZWN0cyBuZWl0aGVy IC4uLi4gbm9yLi4uLiINCg0KW0dTXSBEb25lLg0KDQo+DQo+Pg0KPj4gICAgICBTYWx0LiAgTGVu Z3RoIGlzIGRldGVybWluZWQgYnkgdGhlIEFFQUQgQWxnb3JpdGhtLiAgSXRzIHZhbHVlIGlzDQo+ Pj4gICAgICBpbW11dGFibGUgb25jZSB0aGUgc2VjdXJpdHkgY29udGV4dCBpcyBlc3RhYmxpc2hl ZC4NCj4+Tml0OiB5b3UgbWlnaHQganVzdCBzYXkgYWJvdmUgb3IgYmVsb3cgdGhpcyBsaXN0IHRo YXQgYWxsIHRoZSB2YWx1ZXMgYXJlDQo+PmltbXV0YWJsZSwNCg0KW0dTXSBEb25lLg0KDQo+DQo+ PiAgIGRpZmZlcmVudCBvcGVyYXRpb25zLiAgT25lIG1lY2hhbmlzbSBlbmFibGluZyB0aGlzIGlz IHNwZWNpZmllZCBpbg0KPj4gICBbSS1ELmlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnXS4NCj4+ SXMgdGhpcyBhIHNlY3VyaXR5IGNvbmRpdGlvbj8NCj4NCltHU10gVGhpcyBpbmZvcm1hdGlvbiBp cyByZWR1bmRhbnQgYW5kIHJlbW92ZWQsIHNpbmNlIHRoYXQgZHJhZnQgdXBkYXRlcw0KUkZDNzk1 OSwgd2hpY2ggaXMgcmVmZXJlbmNlZCBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBoLg0KDQo+DQo+ Pg0KPj4gICAgICBvZiBbUkZDNzI1Ml0sIHdoZXJlIHRoZSBkZWx0YSBpcyB0aGUgZGlmZmVyZW5j ZSB0byB0aGUgcHJldmlvdXNseQ0KPj4gICAgICBpbmNsdWRlZCBjbGFzcyBJIG9wdGlvbi4NCj4+ SXMgdGhlIGRlbHRhIGhlcmUgdGhlIHByZXZpb3VzbHkgaW5jbHVkZWQgQ2xhc3MgSSBvcHRpb24g b3IgdGhlDQo+PnByZXZpb3VzbHkNCj4+aW5jbHVkZWQgaW5zdGFuY2Ugb2YgdGhlIHNhbWUgb3B0 aW9uLCBhcyBpdCBhcHBlYXJzIHRvIHNheSBpbiBTIDMuMS4NCg0KW0dTXSBJbnN0YW5jZSwgZml4 ZWQuDQoNCj4NCj4+DQo+PiAgICAgICAgIGNvbXByZXNzZWQgQ09TRSBvYmplY3QuICBUaGUgdmFs dWVzIG4gPSA2IGFuZCBuID0gNyBhcmUNCj4+ICAgICAgICAgcmVzZXJ2ZWQuDQo+PkhvdyBjYW4g UGFydGlhbCBJViBub3QgYmUgcHJlc2VudD8gaXQncyB0aGUgc2VxdWVuY2UgbnVtYmVyLiBJcyB0 aGUNCj4+YW5zd2VyIHRoYXQNCj4+aXQgaXMgdGhlIDAgdmFsdWU/DQo+DQpbR1NdIFBhcnRpYWwt SVYgaXMgdHlwaWNhbGx5IG5vdCBpbmNsdWRlZCB0byByZWR1Y2UgbWVzc2FnZQ0Kb3ZlcmhlYWQs IHNlZSBuZXcgdGV4dCBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gNS4yLg0KPg0KPj4NCj4+ICAgcmVz cG9uc2UuICBUaGUgc2VydmVyIHRoZXJlZm9yZSBuZWVkcyB0byBzdG9yZSB0aGUga2lkIGFuZCBQ YXJ0aWFsIElWDQo+PiAgIG9mIHRoZSByZXF1ZXN0IHVudGlsIGFsbCByZXNwb25zZXMgaGF2ZSBi ZWVuIHNlbnQuDQo+Pkl0IHdhcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGtpZCB3YXMgbmVl ZGVkIHRvIGxvb2sgdXAgdGhlIGtleS4gV2h5DQo+PmFyZSBraWQNCj4+c3Vic3RpdHV0aW9uIGF0 dGFja3MgYW4gaXNzdWU/DQoNCltHU10gVGhlIGtpZCBoYXMgbXVsdGlwbGUgdXNlcy4gSXQgaXMg dXNlZCB0byBsb29rIHVwIHRoZSBrZXksIGJ1dCBpbiB0aGlzDQpjYXNlDQoNCj50aGlzIGlzIGFi b3V0IHRoZSBiaW5kaW5nIG9mIHJlc3BvbnNlIHRvIHJlcXVlc3QgYXMgdGhlIHByZXZpb3VzIHNl bnRlbmNlDQo+ZXhwbGFpbnMuDQo+DQo+Pg0KPj4gICBUaGUgbWF4aW11bSBTZW5kZXIgU2VxdWVu Y2UgTnVtYmVyIGlzIGFsZ29yaXRobSBkZXBlbmRlbnQgKHNlZQ0KPj4gICBTZWN0aW9uIDExKSwg YW5kIG5vIGdyZWF0ZXIgdGhhbiAyXjQwIC0gMS4gIElmIHRoZSBTZW5kZXIgU2VxdWVuY2UNCj4+ ICAgTnVtYmVyIGV4Y2VlZHMgdGhlIG1heGltdW0sIHRoZSBlbmRwb2ludCBNVVNUIE5PVCBwcm9j ZXNzIGFueSBtb3JlDQo+PklmIHlvdSB0YWtlIG15IHN1Z2dlc3Rpb24gYWJvdXQgcmVtb3Zpbmcg c2VuZGVySUQgZnJvbSB0aGUgbm9uY2UgeW91IHdpbGwNCj4+YmUNCj4+YWJsZSB0byByZWxheCB0 aGlzLg0KDQpbR1NdIFllcywgdGhhdCB3b3VsZCBoYXZlIGJlZW4gYW4gYWx0ZXJuYXRpdmUsIGJ1 dCB0aGVyZSBzZWVtcyB0byBiZSBubw0KbmVlZA0KPmZvciBtb3JlIG1lc3NhZ2VzLg0KPg0KPj4N Cj4+ICAgQWZ0ZXIgYm9vdCwgYW4gZW5kcG9pbnQgTUFZIHJlamVjdCB0byB1c2UgZXhpc3Rpbmcg c2VjdXJpdHkgY29udGV4dHMNCj4+ICAgZnJvbSBiZWZvcmUgaXQgYm9vdGVkIGFuZCBNQVkgZXN0 YWJsaXNoIGEgbmV3IHNlY3VyaXR5IGNvbnRleHQgd2l0aA0KPj5OaXQ6IHRoaXMgaXMgdW5ncmFt bWF0aWNhbA0KDQpbR1NdIERvbmUuDQo+DQo+Pg0KPj4gICAgICAgaW5jbHVkZWQgaW4gdGhlIG1l c3NhZ2UuICBJZiB0aGUgQUVBRCBub25jZSBmcm9tIHRoZSByZXF1ZXN0IHdhcw0KPj4gICAgICAg dXNlZCwgdGhlIFBhcnRpYWwgSVYgTVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4gdGhlIG1lc3NhZ2Uu DQo+PklNUE9SVEFOVDogWW91IGFyZSBub3cgdmlvbGF0aW5nIHRoZSBpbnZhcmlhbnQgb2YgdXNp bmcgdGhlIHNhbWUgbm9uY2UNCj4+dHdpY2UuDQo+PlRoYXQncyBmaW5lIGluIHRoaXMgY2FzZSwg YmVjYXVzZSB5b3UgaGF2ZSBwZXItc2VuZGVyIGtleXMgYnV0IGl0DQo+PmRlbW9uc3RyYXRlcw0K Pj50aGF0IGl0IGlzIHVubmVjZXNzYXJ5IHRvIGVuY29kZSB0aGUgc2VuZGVyX2lkIGluIHRoZSBu b25jZSBmaWVsZC4NCg0KW0dTXSBUaGUgdXNlIG9mIHNlbmRlcl9pZCBpbiB0aGUgbm9uY2UgaXMg dG8gaGFuZGxlIG5vdGlmaWNhdGlvbnMgYW5kDQo+Y2xpZW50LXNlcnZlciByb2xlIGNoYW5nZSB3 aXRoIHRoZSBzYW1lIGNvbnN0cnVjdGlvbiBhcyBpcyBhbmFseXNlZCBpbg0KPnRoZSBuZXcNCj5h cHBlbmRpeCBELjMNCj4NCj4+DQo+PiAgIFNlY3VyaXR5IGxldmVsIGhlcmUgbWVhbnMgdGhhdCBh biBhdHRhY2tlciBjYW4gcmVjb3ZlciBvbmUgb2YgdGhlIG0NCj4+ICAga2V5cyB3aXRoIGNvbXBs ZXhpdHkgMl4oayArIG4pIC8gbS4gIFByb3RlY3Rpb24gYWdhaW5zdCBzdWNoIGF0dGFja3MNCj4+ ICAgY2FuIGJlIHByb3ZpZGVkIGJ5IGluY3JlYXNpbmcgdGhlIHNpemUgb2YgdGhlIGtleXMgb3Ig dGhlIGVudHJvcHkgb2YNCj4+VGhpcyBwYXJhZ3JhcGggaXMgZXh0cmVtZWx5IGhhcmQgdG8gZm9s bG93IGJ1dCBJIGFtIG5vdCBwZXJzdWFkZWQgdGhhdCBpdA0KPj5pcw0KPj5jb3JyZWN0LiBEbyB5 b3UgaGF2ZSBhIGNpdGF0aW9uIGZvciB0aGUgY2xhaW0gdGhhdCB5b3UgY2FuIGFkZCB0aGUga2V5 DQo+PmVudHJvcHkNCj4+YW5kIHRoZSBub25jZSBlbnRyb3B5IGxpa2UgdGhpcy4NCg0KW0dTXSBU aGUgcmVmZXJlbmNlIGlzOiBNY0dyZXcsIEQuIGFuZCBTLiBGbHVocmVyLCAiQXR0YWNrcyBvbiBF bmNyeXB0aW9uIG9mDQo+UmVkdW5kYW50IFBsYWludGV4dCBhbmQgSW1wbGljYXRpb25zIG9uIElu dGVybmV0IFNlY3VyaXR5IiwgMjAxMC4gQnV0IG9uDQo+c2Vjb25kIHRob3VnaHQsIHdlIHJlbW92 ZWQgdGhpcyBkYXRhIHBvaW50IHNpbmNlIHRoYXQgaXMganVzdCBvbmUgYXR0YWNrDQo+YW5kIGl0 IGNhbiBnaXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIGlzIGEgZ3VhcmFudGVlZCBzZWN1cml0 eSBsZXZlbC4NCj4NCj4+DQo+PiAgIHN0eWxlIG9mIHBhZGRpbmcgbWVhbnMgdGhhdCBhbGwgdmFs dWVzIG5lZWQgdG8gYmUgcGFkZGVkLiAgU2ltaWxhcg0KPj4gICBhcmd1bWVudHMgYXBwbHkgdG8g b3RoZXIgbWVzc2FnZSBmaWVsZHMgc3VjaCBhcyByZXNvdXJjZSBuYW1lcy4NCj4+VGhlIFBLQ1Mj NyBwYWRkaW5nIHNjaGVtZSBhdCBtaW5pbXVtIGhhcyBwb3RlbnRpYWwgdGltaW5nIGNoYW5uZWxz DQoNCltHU10gQWdyZWVkLCB3ZSByZXBsYWNlZCB0aGlzIHRleHQgd2l0aCBhIG1vcmUgZ2VuZXJh bCB0ZXh0Lg0KPg0KPj4NCj4+ICAgVGhlIHNlcnZlciB2ZXJpZmllcyB0aGF0IHRoZSBQYXJ0aWFs IElWIGhhcyBub3QgYmVlbiByZWNlaXZlZCBiZWZvcmUuDQo+PiAgIFRoZSBjbGllbnQgdmVyaWZp ZXMgdGhhdCB0aGUgcmVzcG9uc2UgaXMgYm91bmQgdG8gdGhlIHJlcXVlc3QuDQo+PkhvdyBkb2Vz IHRoZSBjbGllbnQgdmVyaWZ5IHRoaXMNCg0KW0dTXSBJZiBjaXBoZXJ0ZXh0IGRlY3J5cHRzLCB0 aGUgcmVxdWVzdCBQSVYgaGFzIGJlZW4gdXNlZCBpbiB0aGUNCmV4dGVybmFsX2FhZCBieSB0aGUg c2VydmVyLiBBZ2FpbiwgYmluZGluZyBoZXJlIG1lYW5zIHByb3RlY3RpbmcgYWdhaW5zdA0Kb3Ro ZXIgcGFydGllcyBiZXNpZGVzIGNsaWVudCBhbmQgc2VydmVyLg0KDQo+Pg0KPj4gICAgICAgUGFy dGlhbCBJViAoaW4gbmV0d29yayBieXRlIG9yZGVyKSB3aXRoIHplcm9lcyB0byBleGFjdGx5IG5v bmNlDQo+PiAgICAgICBsZW5ndGggLSA2IGJ5dGVzLA0KPj4NCj4+SU1QT1JUQU5UOiBJIGRvbid0 IHVuZGVyc3RhbmQgdGhlIHJlYXNvbiBmb3IgdGhpcyBjb25zdHJ1Y3Rpb24uIFlvdQ0KPj5hbHJl YWR5IHJlcXVpcmUgdGhhdCB0aGUga2V5IGJlIGRlcml2ZWQgdmlhIEhLREYgZnJvbSB0aGUgfG1h c3RlciBrZXl8DQo+PmFuZCB8c2VuZGVyIElEfCB0aGVyZWZvcmUsIGl0IGlzIG5vdCBuZWNlc3Nh cmlseSB0byBzZXBhcmF0ZWx5IGVuY29kZQ0KPj50aGUgc2VuZGVyIElEIGluIHRoZSBub25jZS4g VGhpcyB3b3VsZCBvcmRpbmFyaWx5IG5vdCBiZSBhIGxhcmdlDQo+Pmlzc3VlLCBidXQgYXMgaXQg cmVxdWlyZXMgdmVyeSBleHRyZW1lIHJlc3RyaWN0aW9ucyBvbiB0aGUgc2VuZGVyIElEDQo+Pihh bmQgZXNzZW50aWFsbHkgcHJlY2x1ZGVzIHJhbmRvbSBzZW5kZXIgSURzKSBJIGJlbGlldmUgaXQg aXMgd29ydGgNCj4+Y29uc2lkZXJpbmcgY2hhbmdpbmcsIGJ1dCBpdCdzIHVsdGltYXRlbHkgYSBX RyBkZWNpc2lvbiwgaGVuY2Ugbm90DQo+PmluIG15IGRpc2N1c3MuDQoNCltHU10gVGhlIGNvbnN0 cnVjdGlvbiBpcyB0byBhZGRyZXNzIHRoZSBhZGRpdGlvbmFsIGNhc2Ugb2YgY2xpZW50IGFuZA0K c2VydmVyIGNoYW5naW5nIHJvbGVzIGFzIHdlbGwgYXMgb21pdHRpbmcgbm9uY2UgaW4gc2ltcGxl IHJlc3BvbnNlcywgYXMgaXMNCmFuYWx5c2VkIGluIGFwcGVuZGl4IEQuMy4NCg0KDQpUaGFua3Mg Zm9yIGEgZ29vZCByZXZpZXcuDQoNCkfDtnJhbg0KPg0KDQo= From nobody Fri Mar 30 06:51:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF0912D7EF for ; Fri, 30 Mar 2018 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 4BLz9D4GAhFq for ; Fri, 30 Mar 2018 06:51:42 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 C6C74126DCA for ; Fri, 30 Mar 2018 06:51:41 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id o34so5445486uae.9 for ; Fri, 30 Mar 2018 06:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TjlBXupHVOv7WltbhPZ2aB9SwOcgbdzc9jvIJXz4+W4=; b=c9VzAcscnIwP0wAegGHdcVIBRiNKjN+IroeADQJhk49By3AeT/qDinyvcec7UFPv8J +ga9mGKCxYf3nyceY7ucSMODXV79YdTEwlC7zh6mx/KI9a3Gg80LjEVccSNijjJPFm6e TRX2My+Ek+7LfIgNLcWV7hse9nnEci3lKegU72pF0iIinX8PyobOQixe3uH5PS2X38Md uj0jQLNjC38kAgi48RHfDaQeXmUWBk3S1/IL9RNtEIwD00InYPs5zMu6kt8lRH32af+6 yeuZInFFpgVFsi5upreLkKbn8TPFFq/pSdSSpzJUMv/9gN1kU5fXJQiThaZV7AmVLcNo 5P9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TjlBXupHVOv7WltbhPZ2aB9SwOcgbdzc9jvIJXz4+W4=; b=Z6gbRjE/236SAMdcFJX5RgO5iH0eLGm0V9tYi/4mhi9xpQ+R4XKmFBSGU1pPGVsG4r OC1DAusLBkHP9o9JGNsI6zo+bcDw2t5KZmpE5b9dTwphniGH5VRrVygefEnGCHbKzLkT Jn4tqeulqaQifkysbPL0kefs/iNSFHy/1OtNzs6A/HbXZU55Wak+SlFYsdWR22UNX4ZB Agrk+HISBcG7V/8x9BXYQJpiOAen/mbPFSJH9SmEJZOdZl/fxkJoL6YFCvZCvig6FZVW ForAUrLKCVT7w59/LnobK/mQZh9oalk84n7xd/ei5bzB6oqCOVup4rGh1MBUM1xMZrIH DSIw== X-Gm-Message-State: AElRT7GO41pEA7qu6qPy5AcWIAySuHRyYvXqh3RskAJO9CURRhTQKitR AZTulyzUUkOWV4fBw45i6uVSRZMUnTCANWP9r0zLsQ== X-Google-Smtp-Source: AIpwx4/ncLnA6ciSZrRcnBNBuIxTpg0DNwRXXbN6E9adgAlYU3KKGhOiOcjsHJ5cK9SCA5u78ocEQf585b+heVJ81X4= X-Received: by 10.176.25.108 with SMTP id u44mr7654329uag.190.1522417900759; Fri, 30 Mar 2018 06:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.213 with HTTP; Fri, 30 Mar 2018 06:51:40 -0700 (PDT) In-Reply-To: References: From: Tanguy Ropitault Date: Fri, 30 Mar 2018 09:51:40 -0400 Message-ID: To: Carsten Bormann Cc: core@ietf.org Content-Type: multipart/alternative; boundary="f403043ecc202cae6f0568a18aa5" Archived-At: Subject: Re: [core] draft-ietf-core-comi-02: SID and Delta SID usage inconsistencies ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 30 Mar 2018 13:51:45 -0000 --f403043ecc202cae6f0568a18aa5 Content-Type: text/plain; charset="UTF-8" Thanks Carsten! I think that my message just shows how confused I am. You're totally right that Delta SID term should never be used as Delta is the correct term (and both drafts never use the term Delta SID). However, let's see that from an implementer perspective as it may help to clarify: Section 2.3 of draft-ietf-core-comi-02 states that: "When part of a payload, instance identifiers are encoded in CBOR based on the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" Section 5.13.1 of draft-ietf-core-yang-cbor-05 states that: "Single instance data nodes MUST be encoded using a CBOR unsigned integer data item (major type 0) and set to the targeted data node SID." So as an implementer, I'm expecting to declare an uint64 for instance identifiers that are part of a payload. However, CoMI may need to use signed int because of Delta (e.g. FETCH request). And that is what is confusing IMO i.e., the "MUST" requirement is not always satisfied. Tanguy On Thu, Mar 29, 2018 at 11:51 PM, Carsten Bormann wrote: > Hi Tanguy, > > SIDs are unsigned, indeed. They are sometimes encoded as deltas. We need > to stop calling those deltas SIDs. They aren't. If you find any place in > the document where that is the case, please identify them. SID deltas are > not confusing if they are not deliberately mixed up with SIDs. > > Sent from mobile > > On 30. Mar 2018, at 09:16, Tanguy Ropitault > wrote: > > Hi, > I'm wondering if there may be some inconsistencies between SID definition > in draft-ietf-core-yang-cbor-05 and its usage in draft-ietf-core-comi-02. > The short version of the story is: > - draft-ietf-core-yang-cbor-05 defines SID as an unsigned integer "YANG > Schema Item iDentifier (SID): Unsigned integer used to identify different > YANG items." > - draft-ietf-core-comi-02 uses in some sections and examples SID with a > negative value (or to be sharp, use delta SID where SID should be normally > used) > > Let's use an example for the long version of the story: > > Section 2.3 of draft-ietf-core-comi-02 states that: > "When part of a payload, instance identifiers are encoded in CBOR based on > the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" > > Section 5.13.1 of draft-ietf-core-yang-cbor-05 states that: > > "Single instance data nodes MUST be encoded using a CBOR unsigned integer > data item (major type 0) and set to the targeted data node SID." > > *** Please note that I'm using the single instance identifier case for a > matter of clarity but the same applies for list instance identifier. > > So according to the sentences above, a single instance identifier that is > a part of a payload can only be an unsigned int. > > draft-ietf-core-comi-02 also states that FETCH request format must be: > "The FETCH request payload contains a list of instance-identifier encoded > based on the rules defined by Content-Format application/yang-selectors+cbor > in Section 2.5" > > application/yang-selectors+cbor is defined in Section 2.5 as: > > "represents a CBOR YANG document containing a list of data node selectors > (i.e. instance identifier)." > > Moreover, Section 2.5 clearly recall this: > "YANG instance identifier, encoded based on the rules defined in [ > I-D.ietf-core-yang-cbor > ] > section 5.13.1 > ." > > So the FETCH request payload can only be made of instance identifier which > are de-facto unsigned int (in the single instance identifier case) based on > Section 2.3 and 5.13.1. However, due to the usage of delta SID for > application/yang-selectors+cbor format, some instance identifier of a > FETCH request can be negative (as shown in FETCH example > in draft-ietf-core-comi-02). In fact, it seems that the sentence "When > part of a payload, instance identifiers are encoded in CBOR based on the > rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" is most of the > time superseded by DeltaSID usage. > > So IMO, it's a little bit confusing and something may need to be added. > > Tanguy Ropitault (Acklio) > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --f403043ecc202cae6f0568a18aa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Carsten!

    I think that= my message just shows how confused I am. You're totally right that Del= ta SID term should never be used as Delta is the correct term (and both dra= fts never use the term Delta SID).

    However, let's s= ee that from an implementer perspective as it may help to clarify:

    Section 2.3 =C2=A0of= draft-ietf-core-comi-02 states that:
    "When part of a payload, inst= ance identifiers are encoded in CBOR based on the rules defined in [I-D.iet= f-core-yang-cbor] section 5.13.1"

    Section 5.13.1 of draft-ietf-= core-yang-cbor-05 states that:

    "Single instance data nodes MUST= be encoded using a CBOR unsigned integer data item (major type 0) and set = to the targeted data node SID."

    =
    So as an implementer, I'm expec= ting to declare an uint64 for instance identifiers that are part of a paylo= ad. However, CoMI may need to use signed int because of Delta (e.g. FETCH r= equest). And that is what is confusing IMO i.e., the "MUST" requi= rement is not always satisfied.=C2=A0

    Tanguy


    On Thu,= Mar 29, 2018 at 11:51 PM, Carsten Bormann <cabo@tzi.org> wrote:<= br>
    Hi Tanguy,

    SIDs are unsigned, indeed. They are sometimes encoded as deltas. We = need to stop calling those deltas SIDs. They aren't. If you find any pl= ace in the document where that is the case, please identify them. SID delta= s are not confusing if they are not deliberately mixed up with SIDs.=C2=A0<= br>
    Sent from=C2=A0<= span style=3D"font-size:13pt">mobile

    On 30. Mar 2018, at 09:16, Tanguy Ropitault <tanguy.ropitault@gmail.com&g= t; wrote:

    Hi,<= br>I'm wondering if there may be some inconsistencies between SID defin= ition in draft-ietf-core-yang-cbor-05 and its usage in draft-ietf-core-comi= -02.=C2=A0
    The short version of the story is:
    - draft-ietf-core-yang-= cbor-05 defines SID as an unsigned integer "YANG Schema Item iDentifie= r (SID): Unsigned integer used to identify different YANG items."
    -= draft-ietf-core-comi-02=C2=A0uses in some sections and examples SID with a= negative value (or to be sharp, use delta SID where SID should be=C2=A0normally used)

    Let's use an example for the long version of the story:
    Section 2.3 =C2=A0of draft-ietf-core-comi-02 states that:
    "Wh= en part of a payload, instance identifiers are encoded in CBOR based on the= rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1"

    Sec= tion 5.13.1 of draft-ietf-core-yang-cbor-05 states that:

    "Singl= e instance data nodes MUST be encoded using a CBOR unsigned integer data it= em (major type 0) and set to the targeted data node SID."

    *** P= lease note that I'm using the single instance identifier case for a mat= ter of clarity but the same applies for list instance identifier.

    S= o according to the sentences above, a single instance identifier that is a = part of a payload can only be an unsigned int.

    draft-ietf-core-comi-= 02 also states that FETCH request format must be:
    "The FETCH reques= t payload contains a list of instance-identifier encoded based on the rules= defined by Content-Format application/yang-selectors+cbor in Section = 2.5"

    application/yang-selectors+cbor is defined in Section= 2.5 as:

    "represents a CBOR YANG document containing a list of = data node selectors (i.e. instance identifier)."

    Mo= reover, Section 2.5 clearly recall this:
    "YANG instance identifier, encoded based = on the rules defined in=C2=A0[I-D.ietf-core-yang-cbor] section 5.13.1.= "

    So the FETCH request payload can only be made of instance identifier = which are de-facto unsigned int (in the single instance identifier case) ba= sed on Section 2.3 and 5.13.1. However, due to the usage of delta SID for= =20 application/yang-selectors+cbor=C2=A0= format, some instance identifier of a FETCH request can be negative (as sho= wn in FETCH example in=C2=A0draft-ietf-core-comi-02). In fact, it seems tha= t the sentence "When part of a payload, inst= ance identifiers are encoded in CBOR based on the rules defined in [I-D.iet= f-core-yang-cbor] section 5.13.1"=C2=A0is most of the time supe= rseded by DeltaSID usage.=C2=A0

    So IMO, it's a little bit confus= ing and something may need to be added.

    Tangu= y Ropitault (Acklio)

    _______= ________________________________________
    core mailing = list
    cor= e@ietf.org
    https://www.ietf.org/mailman/listinfo/cor= e

    --f403043ecc202cae6f0568a18aa5--