From nobody Fri Sep 1 06:24:55 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C9A120727 for ; Fri, 1 Sep 2017 06:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, 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 cGIxfl5mzEJy for ; Fri, 1 Sep 2017 06:24:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 49523134170 for ; Fri, 1 Sep 2017 06:24:51 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.205]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MCggg-1dfYSg2cRG-009SfK for ; Fri, 01 Sep 2017 15:24:48 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 1 Sep 2017 15:24:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CQFz2V12N1NhbQf4+oKWJASl5AXPsFVaiYsZ3G1t3aRmzKsO561 vtbO9CJ6LOaZP7pX5CLybCxz7cW6taYDgtfLYxPOGWmiayy3VK/oUXXMHwhAtDN5nLtVo14 /D9QfLvop+fWlQdUz+/aMvY0oqSt16cpj4W5DiYoD+stNH4EIsRrs1UKa397/x4rf0TkPGk sh+Tzilx6HfqY1qC/6AzA== X-UI-Out-Filterresults: notjunk:1;V01:K0:J8qNFA+Xqeg=:Fy5CO/tS5LPlxbTB0Dgd8G 7eBS/GoVvHzKzIrP9Q1CQNU84g8F8ecykKEN/1ZHhz8iyzb9lg1tRfxBxBh9WszDBJQ7xpSmd Qay90b2TB4pYcWpa9mAjyan2L9Xmbmc2pOF0rK3lApvlku5fdoy6Di6qrrhLARzTvGwh6J/F8 dQs0JuZF9vtX+zECqcCFFrTwOKN9cd4v6MpQ9Lv7NGNE6y5Qn9h3aCS7pjsha9CwEXHIBuIR4 C9vGDrc+Rxp+v5kBnOPImFP/4jt2GcThq5OsCtUR4pe4wz0GP/3TOYzz2/WQqdTfKdSXOY415 Ff7ejNo5OYjGeo2X0ZV5B2oF5QRVCMUCjJjV02Dlun2unos46kEvcMq625HWfxsNIe7Fqn/CX os3hbYh+8Y6++k4Cph2Jmv8oCq3wzlnWoPJvzSgzUYQDmCbjJ2fFw+adv5zNw3cxYAYL+qwz5 C//yRHEXrfBol33sQGECFy936dwyp3BkkmdO5yqA9LVn5J3s0hx+H9bStEX3k1UagJWIwsnb2 ieakuvvCLDq69c6wjj8jNWC3qg7jO5dL9FW36hT9mQwFXraiV9j04U9hYT1L/s0hLBwH8iVMv wCWHYERl+tJyI+sZOXwTQl0LVnTxL6JpsrzUmocJ+gAjRN+ewQQ+jagm56Uy+g177VhcEvbzZ bIfneqSqcn9gMHF4ncUIMOfbghhiFdA5fJ21Q4juFtOrBCToN1Rw1r0aoEdJ2cZdimZY3L0Sw h6Nrw+msSTtjXfKkTKlhzv2kW+Fupel18Am85JJUjjX0ADZKOvhF7o8qxgXLwZ3k+Kibv8fFK qA5OjD9jE3G/QG+NqseWa9rKXDVlf/rUIRtwGIWWfSkgPyC0Ck= Archived-At: Subject: [core] draft-ietf-core-resource-directory-11 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, 01 Sep 2017 13:24:53 -0000 Hi RD draft authors, Hi all, I read through some parts of the RD document that appear to be relevant for LwM2M and I have a few comments and questions. Section 3.3. This sentence reads broken: "In a typical scenario, during a boot-up procedure (and periodically afterwards), the machines (endpoints) register with a Resource Directory (for example EPs installed on vehicles enabling tracking of their position for fleet management purposes and monitoring environment parameters) hosted by the mobile operator or somewhere else in the network, periodically a description of its own capabilities." Maybe you want to shorted it a bit and split it into two sentences, such as "Imagine a scenario where endpoints installed on vehicles enabling tracking of the position for fleet management purposes and allow monitoring of environment parameters. During the boot-up process endpoints register with a Resource Directory, which is hosted by the mobile operator or somewhere in the cloud. Periodically, these endpoints update their registration and may modify resources they offer." I would also suggest to change this text from "Due to the usual network configuration of mobile networks, the EPs attached to the mobile network may not always be efficiently reachable. Therefore, a remote server is usually used to provide proxy access to the EPs." To: "When endpoints are not always connected, for example because they enter a sleep mode, a remote server is usually used to provide proxy access to the endpoints." From: "The users, for example mobile applications for environment monitoring, contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database." To: "Mobile apps or web applications for environment monitoring contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database." The beginning of Section 5.2. "URI Discovery" does not seem to be inline with the text in Section 4. It appears that two different persons have written the two sections or that the sections got reordered some time ago. Section 5.3.1. "Simple Registration" I am not sure I understand the motivation for introducing simple registration. The text says "Not all endpoints hosting resources are expected to know how to upload links to a RD". Under what condition is an endpoint unable to know how to upload links to the RD? Section 5.3.3. "Third-party registration" Are people using the third party registration given that it may be an operational challenge? Section 5.4.1. "Registration Update" " An update MAY update the lifetime or context registration parameters "lt", "con" as in Section 5.3 ) if the previous settings are to be retained. Parameters that are not being ***changed changed*** SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in Section 5.3. " " An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. A link is replaced only if all of the target URI and relation type (if present) and anchor value (if present) match. " How are links deleted? It is not unlikely that resources get removed during the lifetime of a registration. " In addition to the use of POST, as described in this section, there is an alternate way to add, replace, and delete links using PATCH as described in Section 5.4.4. " Do you think it is a good idea to provide two ways to accomplish the same effect? Why not only use PATCH? 5.4.4. Update Endpoint Links " In particular, a select-merge patch document format could combine the function of link selection query and link attribute replacement values. " Is this referring to an existing format or is this a more theoretical thought? If it is the latter then I suggest to delete this sentence to avoid confusion. If it isn't then add a reference. " If no links are selected by the query parameters, the PATCH operation SHOULD NOT update the state of any resource, and SHOULD return a reply of "Changed". " I believe the correct wording should be " If no links are selected by the query parameters, the PATCH operation MUST NOT update the state of any resource, and MUST return a reply of "Changed". " (There does not seem to be a better return code than changed even though nothing was changed.) 8. Security Considerations " Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. " Why is this only applicable to certificate-based authentication? I believe it is an equally valid concern for use with PSK and raw public key-based authentication. The threat, which could be detailed a bit, can be described as follows: --- Imagine you have a device from company A and another device from company B. Both are managed by a single server. Both devices have unique, per-device credentials for use with DTLS. Now, imagine that company A wants to sabotage the device used by company B. It uses its credentials during the TLS exchange. Then, it puts the endpoint name of the company B device. If the server does not check whether the identifier provided in the DTLS handshake matches the identifier used at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to that device. --- Section 10.2.2. "LWM2M Register Endpoint" FROM: " Endpoint Name is mandatory, all other registration parameters are optional. " TO: " Endpoint Name, Lifetime, and LWM2M Version are mandatory parameters for the register operation, all other registration parameters are optional. " In Table 5 you show some of the parameters used during the register operation. Why did you omit Lifetime and Endpoint Name? Use the term "Binding Mode" instead of "Protocol Binding". +------------+-------+-------------------------------+--------------+ | Name | Query | Validity | Description | +------------+-------+-------------------------------+--------------+ | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available | | Binding | | | Protocols | | | | | | | LWM2M | ver | 1.0 | Spec Version | | Version | | | | | | | | | | SMS Number | sms | | MSISDN | +------------+-------+-------------------------------+--------------+ Table 5: LWM2M Additional Registration Parameters Why does the RD not have any version indication? Would it make sense to introduce the 'ver' parameter as well since it is quite likely that there may be new versions of the protocol. Also the use of the protocol binding may not be too far fetched since devices may run coap over multiple different transports. Btw, I couldn't find a description of the "Endpoint Type" in the document. This is a parameter that is not used in LwM2M but it is also not clear what benefit it gives. 10.2.3. LWM2M Update Endpoint Registration The LwM2M update is really very similar to the registration update with the only difference that there are more parameters defined and available. All the parameters listed in that section are also available with the initial registration but are all optional. ciao Hannes From nobody Fri Sep 1 12:09:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C573A134588 for ; Fri, 1 Sep 2017 12:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 JSXx7FQJO_qj for ; Fri, 1 Sep 2017 12:09:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 272F313434E for ; Fri, 1 Sep 2017 12:09:15 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.205]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MAyVY-1dg85d3ZZs-009xMM for ; Fri, 01 Sep 2017 21:09:14 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 1 Sep 2017 21:09:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:SdXh9lVeoiMRgsY/R2XA4STVKGu+rt0nWXtekRC8kbx4/YamTo0 SLoRcYyV6tgbMtaKChD/1tHN1SbKQ6H5AB6jQmERcjDFUGY9HD9HEKAbWgG5piHnbmT1el+ xNG/RF3i9nNy8ZoJywey0iBw3huTrGF90m7ZtIqUDM4q870jsfIQmmFNVwlXTZcS58LstKo YkwjmpxL8sGMz5pUCijqg== X-UI-Out-Filterresults: notjunk:1;V01:K0:G+tci9No5jA=:hjsEBedk6sM5a+9Ca5jefp S/E2I2c7w2VdRCpjqztJPFVW1XOksYbDGTajBYcmmVmoFoXkQ6JpzngmdSgDMlemayQeZUaOv KUfWkwYnqltlT5UQTrwb1qYWkKkDgfsX+zvZsCJrEMsIXlZjsBv1AgqGO7JSP1qx74zcFAU9/ W4VV9vx8KmDGcKoA+aaCfLLx/M0x3UaYDfc4AMcwJjPPIa1Dh/IX+4xNnAsCdruU/cWJe8W1x teZS9W9gorl+J19WsSBo4oTwFPbiv7IGp0w33NdfQPeW87aRykjhyXCt/V2pTbAoO+MOgt49o kV0nhuoKLbP0CX3i4HpxFYWJUeYQOrzbxp7/ztH9VCKpkFBOI6/ccSwJHqHfQRNJpTwxan9oQ biPd3HM3989aNS8vhBw0YHtbpnw3tSvPn5m3J0B/4tINOkx7tePB0xfPGYQEEPkvjtJHYIqK1 q/pYKJSntcRKkgkKLKVBiST/b8Jz93CqfxjVY/SGdH78rJuo9vIE+bMHwparA+kcA7uQmg6+g 703rsKa4O8suoHpWfDig1Ir5I5MpnfMBflz13IF7k54auOXX6E9aofKFVRjf3xzq197cplpjg vuiXsOBzRTr7tuQGKA/LxO+LCHLeu/PeA2GwJYw7qfTQ8A0DlW1xPMH1W9AFl8JjeknScHTfm UfBdx+M8t9V1D0eGepIIw2G6EQyFhbC8GeMIh/pjjBlh9WkzUYjGjgafAiDFvbYBMCnmkp9Y/ RSziOS+bIeIp66W12fS3o1A1VflPgDFUAgNigxT+kHP0Dkkji5scFG625f3d6IsfgMa7QS2vI /NeKDVmXd3tPO7JecbaaDhBVbTG31ONeobi58RThZnZDoHv2tY= Archived-At: Subject: [core] Repeat And Request-Tag 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, 01 Sep 2017 19:09:18 -0000 Hi draft-amsuess-core-repeat-request-tag-00-authors. I have unfortunately missed the first session of the CORE meeting at the Prague IETF meeting where this draft was presented. From the recording I understand that there is a separate problem statement document. Could you point me to that document? Ciao Hannes From nobody Sat Sep 2 11:22:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC3113301A for ; Sat, 2 Sep 2017 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 fd1it8GRY4WE for ; Sat, 2 Sep 2017 11:22:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 8F6CA133008 for ; Sat, 2 Sep 2017 11:22:26 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.205]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MKHMk-1doklC1vk6-001g0d for ; Sat, 02 Sep 2017 20:22:24 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Sat, 2 Sep 2017 20:22:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hnQEHry0YiS22CiA7V5n/ZaTsCJWnHPmfVzG/WfhBuFd/X6t/42 Q1nxlai/x9BqILIQEerT2PHx+MY6WTjEC+hhNJwhu8uARLuGOdTFvHBRN2TpNGplgRCpZZ7 RNX80Yij4ioPADLf9/dJ6hPjnOVU55dbDrn7lcHTAdTnInnPQMQDKr/i3ZZ99UmtOsx+7wz B4H8lbIdeRCcQFEdh3Urg== X-UI-Out-Filterresults: notjunk:1;V01:K0:c08t5iqzAlk=:XB6NrbMG26IJt/mXVswopf CbPguQwYWgZwpkXJLMaXkA1ljoetsPis51Yg8TCb0v2ruEgUXwBcYbMsu5bdW2KgltQ6DDBsb luUnsqS0EJHJL9767Ns6ti8gRo12Rpyne/YzUMDhAw+cQRI4OjMB+3FWkQqe+2MMnJFcPGRaL cmb+sWKjIQSJRUkXNLZ3HVlwY3B4UxVK9j5AJhIEqbxfBYg7NC6giQ5K9g6SkQIPoYDuxLKMg +i2duUBzak5kr9Sb0U5Q1Wf23cqhCQJL0yzWcT3/QJjccZBQcQnETTyKuZrOLiAogef0Pw8PB GZyp3wASpCvoaygwLW8YJTG8Usdds52BinsQkf5mArUsfQ9lsw5kVWOBCxdaOqhF2FXg8350f dAHahSV98NdoOwymJrcNkZp1ZlhIf+IH6oJD+1Xr5zSelTIyTOLXUz6BUk3IqaCcvgZ/8shxl 5klZRue6QL9Ofosl8QYEGbgujEN4mN9YxRl5CYQfgnoUofrhP7XRh0ZgPoOB1qa23tEGFhueT lFvo+o6jEXWrUn2GiD/Ve8v8lyw7S/FpPb9EVg1xrQLT38CG7+feI52IiBEMpBqyC/fTb0d7U r3kI6l2dps7vIXUxhDw7n4zA/LsBj8f/2FxL/P2+Pm7+tZPvmryjyj1XiLwUvpP7h3VGxAXLB apJl2K9VdWnElql5nk9m7KSx3CnKQZwowydEHDYZbVdFB608Q3MXzpqGIjDWRMUM8kneA8ILC CSjgyfPJYBfKjwpm/U3FWDJgydsWtvEHtcz/jLDBKflEd7mTgnG4MWX8xZwCG8WOrRFsTkHv4 jNzwsb3aoAjdXzD+PjZ2z6UFWTTOvS5/Awv8ee/jYaPCWL6Feg= Archived-At: Subject: [core] draft-ietf-core-cocoa-01 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, 02 Sep 2017 18:22:28 -0000 Hi draft-ietf-core-cocoa-01-authors, Hi all, I have started to read the CoAP congestion control document and I have a few comments. One of the most important sections of a document, the introduction section, is empty. As a reader I would find it useful * to learn what the perceived problem is, and * to have enough information to decide whether I want to implement this specification. Are there answers to these questions? I know that there are these other referenced documents that **may** contain some of that necessary content but do you expect the reader to read them to understand this document? I think this document has to be self-contained. I also believe that many readers are worried that the enhancements to CoAP over UDP quickly turn into CoAP over TCP. Are there suggestions on when a deployment should switch to CoAP over TCP rather than using CoAP over UDP with this advanced congestion control algorithm? Ciao Hannes From nobody Sat Sep 2 12:11:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BEB133072 for ; Sat, 2 Sep 2017 12:11:32 -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 lIzwPoZA3rNj for ; Sat, 2 Sep 2017 12:11:30 -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 16DA7132D92 for ; Sat, 2 Sep 2017 12:11:29 -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 v82JBQ4W022502; Sat, 2 Sep 2017 21:11:26 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xl5Lk10K9zDLTc; Sat, 2 Sep 2017 21:11:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sat, 2 Sep 2017 21:11:25 +0200 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 526072285.238587-fadc723dec638cae39e96297ca831219 Content-Transfer-Encoding: quoted-printable Message-Id: <0B85FE69-4036-4FDF-BDB4-37E208440E53@tzi.org> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-cocoa-01 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, 02 Sep 2017 19:11:33 -0000 Hi Hannes, > On Sep 2, 2017, at 20:22, Hannes Tschofenig = wrote: >=20 > Hi draft-ietf-core-cocoa-01-authors, Hi all, >=20 > I have started to read the CoAP congestion control document and I have = a > few comments. Thank you; this is very useful input. > One of the most important sections of a document, the introduction > section, is empty. Indeed, that is one editorial item that we need to do: extract material = from the two referenced I-Ds and putting it here. But let me try to = provide concise answers to your questions here as well; we can work this = into an introduction later. > As a reader I would find it useful > * to learn what the perceived problem is, and The problem is that the basic congestion control (CC) provided by RFC = 7252 is adaptive only in a very crude way (counting the number of = retransmissions of a single message, starting fresh for every new = message). It therefore also has to be very conservative, with a basic = time constant of 2 to 3 seconds (dithered). CoCoA provides a more advanced CC, keeping some state at a message = initiator about the path to the peer. It is still very conservative, = but can be less so if the path is consistently good. What you get is a faster reaction to packet losses in cases where the = actual round trip time is lower than the basic CC=E2=80=99s time = constant. You also get somewhat more (!) conservative behavior in a = truly deteriorated situation. > * to have enough information to decide whether I want to implement = this > specification. If you have the memory at the message initiator (per peer storage, about = 4 bytes needed per peer plus the space needed to identify that peer) and = the space for a few additional lines of code, you want to implement this = specification. (Note that you always can fall back to basic CC if the per-peer storage = space runs out.) > Are there answers to these questions? There are, but we haven=E2=80=99t spent time on creating WG consensus = about these answers. > I know that there are these other referenced documents that **may** > contain some of that necessary content but do you expect the reader to > read them to understand this document? I think this document has to be > self-contained. I agree that we shouldn=E2=80=99t be relying on expired I-Ds. > I also believe that many readers are worried that the enhancements to > CoAP over UDP quickly turn into CoAP over TCP. Moving to TCP is a completely different class of complexity (several = orders of magnitude more than just adding CoCoA). > Are there suggestions on > when a deployment should switch to CoAP over TCP rather than using = CoAP > over UDP with this advanced congestion control algorithm? The intro to CoAP over TCP gives some reasons for switching to CoAP over = TCP that are unrelated to CC; these are the actual motivations that led = to developing the spec. But indeed, switching to a much more powerful = transport protocol also has side benefits. The CC benefits of CoAP over TCP as compared to CoAP over UDP are that = TCP CC is much more aggressive. (This can be a bug as well as a feature!) If your application is an elephant and not an ant =E2=80=94 it relies on = filling up the bitrate of a path, or on getting a fair share of the = total bitrate when competing with aggressive TCP flows on a congested = path =E2=80=94 you probably need TCP. If your application needs = somewhat consistent behavior in the presence of significant packet = losses, then TCP doesn=E2=80=99t help at all (or you need a TCP = implementation that is specifically tweaked beyond the standard = algorithms in order to deal with this situation). I hope this quick reaction helps you in getting your questions answered; = now let=E2=80=99s put that information into the document as well. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Sep 3 05:55:40 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D35013219A for ; Sun, 3 Sep 2017 05:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTaEZCXZEHpp for ; Sun, 3 Sep 2017 05:55:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3CE351321A0 for ; Sun, 3 Sep 2017 05:55:36 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.205]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LvzF3-1dQqvQ4BvZ-017kQj for ; Sun, 03 Sep 2017 14:55:34 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Sun, 3 Sep 2017 14:55:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kzjLw4tHHTojfZXQGYsVDMZ2TX3Oyx1cd6lCNd9BWv9Bbia2WfW uhcrxMCJMu81M+Mhpu0qRNE/RaG9ZHNS0khi5W0kWnySrMQu47FkYj23esEfn2vplUC05ew zZUWeG2M8v9R3jnlTa4iKgLQmySZDkAMtwX5oBta99/w2KwL7TfNcK/cSEvpB7zAIUTzAKs sGwn1ZnYD8A8kXhA7TeZg== X-UI-Out-Filterresults: notjunk:1;V01:K0:MUq38n8Me0A=:QC545SJxEhuX49nO+dQ7py BNtRQIR1k0uShnHJ1hGlnlPwustv+WdxnsmD72CKmvoHoRHwlEpFgaBP7fVCXk3kOq5X1hlxq MKCMv7hTRUbRJXOHqzz1u6GadvVRRjI9a4JCnYaXIYRBgvsKo3NRqZakarI4xgApyww9hadTl bWZuAFpo5AIMi9AGcyfuoe3kx0Q7eOSnYLVjqLBwaGnZHeGG3G0ffbA9tfdWKqF5JNc0qwW+G q4NS/LIOnB5h6Xvxft1v//5wrOrdkqX+KLZYUX2cLjSnInwjlZwyZhWC/bWzECdR+s4qpS7r0 fvxlgA3f46U+5jv0OPOWfZAxzy8Uj3RPlcmM4maMvsabOytTui/3nsrWdWqcEdF9zpPH0TfhD WeWwk4YPl+YiF+cdMzrkj2cu0YeoPf/SZfjVRL2o8jXB9kao4M8t13bj9tOyql6PaX4Q+md2M L9T3T0COOEi2462Eje528R5wU0OMLCllLEOMYCGHAh883qOCnmGfQgNUR46eLGuYHMvyqN856 cUYka3+ebW0MZpo4nZO1dRW6bECT5KtGoyZfnHtXNqnYZnCOAwy5qS+BDx+UZ6UtWRPpF3yac oD8U54amyfA313sYOqSfDJDDdbSrwklGJ1Aj41Ma38fv3FfysUuXMSGeoDd4btPzrWtJj0gUb PQyrubiNErUCk/5knPPoTwZHanJj/KG5gJm7uJBDfkjCuwF0kSjiRa0WixdeZmb365sPZ33/O oyB8IuOUrn/f9Tpc68J5iygBw5FxxtFBVBGpQk2ekdLQbDTPtvzZmv18WCSRZWlVlHy8pOhbp WYGl+XtW5nFXZHEiRV53/9t5LPsmpxuivUTYJBFcZdcPJAPky4= Archived-At: Subject: [core] CoCoA / Editorial Issues 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, 03 Sep 2017 12:55:39 -0000 Below are a few basic / editorial review remarks. Shouldn't the title be changed into something else than "CoAP Simple Congestion Control/Advanced"? Currently, the title makes no sense. Either it is simple congestion control (which it cannot be since that's what is currently in the CORE specification) or it is advanced. I would prefer something "An Advanced Congestion Control Scheme for CoAP" Also I prefer if the following paragraph gets changed " This specification defines some simple advanced CoRE Congestion Control mechanisms, Simple CoCoA. It is making use of input from simulations and experiments in real networks. " Maybe something like "This specification defines an advanced congestion control for CoAP."; again simple + advanced makes no sense. It is also not necessary to state that you this work was done with input from simulations and experiments. Without those you wouldn't be able to standardize a congestion control mechanism in the IETF anyway. Terminology: Delete the following note since it is irrelevant for the specification whether it is informational, experimental or something else with regards to the use of RFC 2119 language. (Note that this document is itself informational, but it is discussing normative statements.) RFC 2119 boilerplate text: Normally the following language is used: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. I don't know where you got this text from: 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] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. Section 2 "Context" Historical stories are less useful for IETF document. I would suggest to delete this paragraph In the Vancouver IETF 84 CoRE meeting, a path forward was defined that includes a very simple basic scheme (lock-step with a number of parallel exchanges of 1) in the base specification together with performance-enhancing advanced mechanisms. I would move the core messages of the following two paragraphs to the introduction: The present specification is based on the approved text in the [RFC7252] base specification. It is making use of the text that permits advanced congestion control mechanisms and allows them to change protocol parameters, including NSTART and the binary exponential backoff mechanism. Note that Section 4.8 of [RFC7252] limits the leeway that implementations have in changing the CoRE protocol parameters. >From the paragraph above you want to explain the purpose of the NSTART and the binary exponential backoff mechanism and why it is relevant to this work. Ignore the rest. The present specification also assumes that, outside of exchanges, non-confirmable messages can only be used at a limited rate without an advanced congestion control mechanism (this is mainly relevant for [RFC7641]). It is also intended to address the [RFC8085] guideline about combining congestion control state for a destination; and to clarify its meaning for CoAP using the definition of an endpoint. The first sentence is a bit hard to parse. You are saying the following, I believe: It is difficult to send non-confirmable messages at a high rate since the sender has no information about potential congestion situation of the network (and also flow control information at the receiver side) since non-confirmable messages do not provide any response. The present specification does not address multicast or dithering beyond basic retransmission dithering. It is useful to say upfront that you are not addressing multicast. I don't understand what the second part of the sentence means. Btw, you can also move the statement about multicast to Section 3. "Area of Applicability". The security section is empty but I don't expect it to say a lot. Ciao Hannes From nobody Sun Sep 3 06:00:10 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4109B13214D for ; Sun, 3 Sep 2017 06:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTN1WR-Cv5DE for ; Sun, 3 Sep 2017 06:00:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 36DF9126B7E for ; Sun, 3 Sep 2017 06:00:06 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.205]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MVIva-1dzuQV0L8w-00Yhsy; Sun, 03 Sep 2017 14:59:57 +0200 To: Carsten Bormann Cc: "core@ietf.org WG" References: <0B85FE69-4036-4FDF-BDB4-37E208440E53@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5f416836-0aa0-bf6d-c1b5-3fce578fc663@gmx.net> Date: Sun, 3 Sep 2017 14:59:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0B85FE69-4036-4FDF-BDB4-37E208440E53@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hcplU7gIKhhm5F24iO4brWhMzvzvoHeFE8O61x8ovv0K50pIfem cxxNMyCliKMs7KsVciYXytVurJxYjF5fEWpTf33p9r+KpS6YTooG3bxsMla7WmwJPC2j2hP DPDe1jWhSZczKS1l02zya7tcsyT/QAc4U4rKjBMH2njF4MITQAu0yTjqMc1+d4w8gd3pMiZ Ho4wImqYCNoRPfuqAgQxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:jn81Khx9670=:YlLYQlkzMATg77uFcLlgl0 E40ApqOGrxebPqwwbp9/DzeGSdsC7rSCOhyCN6uYLYnXOXd9W25CD+w6713YCniKKdcKGUd4P KgMSlf1vEj2tREWh2Ke9clpHQ3G2BM9ND7LgeOykBNfeWtBXFzUZjb9Kpl/exRgGQzFovjmkd cd2KCAyBUoFCfIwTP5y0RyKaC3YG1Z/DXkYdIKPqX3sq1+u7k/TOwbde8bgEGtoE/DM+Px1QM m9Fupx/tSnnojtMWE+h7vxndoyzhNfrkqaWVkeoPJ1u9eHOQmx8QTjH1V7xeJdI0coQoQ2v7k K/gd4kfpw9zDRCvI+9z6A+Tdz5HkXuFz1UT3kbZSiqCDe7u7hTm+W121u+nRmG82uEML/kgtR dh8y/DcCPAkw/cWEWRs+i3mP5h6/n7iZENX4Wi8nwrQbbdU+x2eVby5y8yH6yxAP3KfAxeWMp OU6hA45GyG0v+CLwH2FbeSVDMByjpPfw5CLsGA4Duu0mZwWlhZnWFFyhqm/qGsIL+P+2YU47F nNfvwgi0GttuYnhDCqOsn4UrVd6TKIN74mT0dEuWAv5dS38w/1oD2risvga8EGhWd/PUtcrHt Zb39U4ZzFwAsDeJzqhGwi17hjN86XcdTrQho5F0kRHEL6Jplw52tmeYb6K59hmenpBEhNwboO t0ky3ySAdTjKM8csxAcBca7hai6gVNOZFSuXgHEWZVJXvqQYALV/yl8JuLNY4V/BjqMLwLF/t 4VPMauXxU+mHtq4z1ddRI/pCmW01xXJ5gxPH6UJHiFCEpz4mjfBB4ZWbf57EiFXmDvFqm95+1 4Bku9siMZz+RxBw1MG2LZ9Cy+gr9hJDtsbhN7KeeYyJH6pKFng= Archived-At: Subject: Re: [core] draft-ietf-core-cocoa-01 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, 03 Sep 2017 13:00:09 -0000 Hi Carsten, thanks for the quick response. > The problem is that the basic congestion control (CC) provided by RFC > 7252 is adaptive only in a very crude way (counting the number of > retransmissions of a single message, starting fresh for every new > message). It therefore also has to be very conservative, with a > basic time constant of 2 to 3 seconds (dithered). > > CoCoA provides a more advanced CC, keeping some state at a message > initiator about the path to the peer. It is still very conservative, > but can be less so if the path is consistently good. > > What you get is a faster reaction to packet losses in cases where the > actual round trip time is lower than the basic CC’s time constant. > You also get somewhat more (!) conservative behavior in a truly > deteriorated situation. The last paragraph provides the information I had been looking for. You may want to add this to the introduction/abstract of the draft. The question is, however, whether the slower reaction to packet loss has been an issue in real-world deployments. Another related question is whether you can use typical IoT data communication patterns for reliable RTT computations given that many devices communicate at a regular interval but with a fair amount of delay between the individual transmissions. Do the authors have any traffic data from IoT deployments? Finally, I was expecting (before reading this document) that a practical problem is that CoAP limits the number of outstanding responses to a given client to NSTART (1 by default). This specification does, however, not aim to target this issue, if I understand the document correctly. > >> * to have enough information to decide whether I want to implement >> this specification. > > If you have the memory at the message initiator (per peer storage, > about 4 bytes needed per peer plus the space needed to identify that > peer) and the space for a few additional lines of code, you want to > implement this specification. (Note that you always can fall back to > basic CC if the per-peer storage space runs out.) I think it would be point this out in the specification in the form of "here is the cost of the mechanism". > >> Are there answers to these questions? > > There are, but we haven’t spent time on creating WG consensus about > these answers. > The document hasn't seen a lot of input from the working group at all. I would say that this is not surprising since the necessary expertise is certainly not in CORE. Do you see this as a problem? > >> I also believe that many readers are worried that the enhancements >> to CoAP over UDP quickly turn into CoAP over TCP. > > Moving to TCP is a completely different class of complexity (several > orders of magnitude more than just adding CoCoA). Is that really the case? When I read https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-00 then I get a different impression. In my review of that document I have asked the authors of th draft-ietf-lwig-tcp-constrained-node-networks-00 to provide some of that data. Ciao Hannes PS: The draft should discuss the difference between the weak and the strong estimator early in the draft (rather than using the terms and only in Section 4.2.2 mentioning the motivation). I would also feel better if this idea of weak and strong estimator is reviewed and agreed by the transport area directorate since it is in contradiction to what is said in RFC 8085. The text in Section 5 "Advanced CoAP Congestion Control: Non-Confirmables" essentially comes without motivation. The same is true for the algorithm in Appendix A. Are you expecting that the algorithm in Appendix A will stay in the draft given that "The mechanism defined in this appendix has received less research" as the authors correctly point out? There are also two reference sections, which is unusual. From nobody Sun Sep 3 21:46:45 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3611C1329C7 for ; Sun, 3 Sep 2017 21:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QHaMyhR4JqBR for ; Sun, 3 Sep 2017 21:46:40 -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 87EE113438A for ; Sun, 3 Sep 2017 21:25:49 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-d4-59acd5cb1735 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.88.21299.BC5DCA95; Mon, 4 Sep 2017 06:25:47 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.26]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Mon, 4 Sep 2017 06:25:47 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig CC: "core@ietf.org WG" Thread-Topic: [core] Repeat And Request-Tag Thread-Index: AQHTI1XSZhEglLTcPUewuVgmxmKCuKKkA4wA Date: Mon, 4 Sep 2017 04:25:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-286873A2-0C81-4BFE-BEDE-7DC6839E896D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUyM2K7k+7pq2siDf5M0rPY93Y9s8XSnfdY HZg8Fm/az+axZMlPpgCmKC6blNSczLLUIn27BK6Mf4vnsRWsSarYMLuZsYFxR3wXIweHhICJ xJNXhV2MXBxCAkcYJWY+bGaHcBYxSpye2sPYxcjJwSbgIvGg4RETiC0iYChxfeZ0VhCbWUBN 4tHScywgtrCAlsS9vrMsEDXaElt27mWHsI0klv06AGazCKhITL99GczmFbCXWPvnCzPIEUIC VhKP5umChDkFrCX+njsFNoZRQEzi+6k1TBCrxCVuPZkPZksIiEg8vHiaDcIWlXj5+B8ryM3M ApMZJQ592QI1X1Di5MwnLBMYhWch6Z+FrG4WkjqIoniJHe2PmCFseYntb+dA2ZoS+7uXQ9Uo SkzpfsgOYWtIdH6byIopbi0x49dBNgjbVOL10Y+MyGoWMPKsYhQtTi1Oyk03MtZLLcpMLi7O z9PLSy3ZxAiM3INbfqvuYLz8xvEQowAHoxIP74W9ayKFWBPLiitzDzGqAM15tGH1BUYplrz8 vFQlEd7FV4DSvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1 MDp//H1U5MuGmijbift2FR9/oV+rxtQt9PX/u++BiuLlrlUhzr/cN829oz7/0XWuoELeOeGp 8d8jqoTnfi3r//5CePWp2il7rnR+ucF2z2XeBsY/NW4ut5esynEWdH57h8nkR/QZ4/C6f1ka O6wu2hvmqbO41S+MWJbME8pibn5f6Iulp8rzPUosxRmJhlrMRcWJAHD+9QnkAgAA Archived-At: Subject: Re: [core] Repeat And Request-Tag 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, 04 Sep 2017 04:46:42 -0000 --Apple-Mail-286873A2-0C81-4BFE-BEDE-7DC6839E896D Content-Type: multipart/alternative; boundary=Apple-Mail-779B0C3A-7994-4FA6-AD5B-B6373E94ABA2 Content-Transfer-Encoding: 7bit --Apple-Mail-779B0C3A-7994-4FA6-AD5B-B6373E94ABA2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpJZiB5b3UgZ2xhbmNlIGF0IHRoZSBmaXJzdCBwYXJhZ3JhcGggb2Ygc2Vj dGlvbiAxLjENCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbXN1ZXNzLWNvcmUt cmVwZWF0LXJlcXVlc3QtdGFnLTAwI3NlY3Rpb24tMS4xDQp5b3UgZmluZCBvbmUgb2YgdGhlIG1h aW4gcmVmZXJlbmNlcy4NCg0KSWYgeW91IGdsYW5jZSBhdCB0aGUgc2Vjb25kIHBhcmFncmFwaCBv ZiAxLjINCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbXN1ZXNzLWNvcmUtcmVw ZWF0LXJlcXVlc3QtdGFnLTAwI3NlY3Rpb24tMS4yDQp5b3UgZmluZCB0aGUgb3RoZXIuDQoNCihU aGUgbGF0dGVyIGlzIGFsc28gbGlua2VkIGZyb20gdGhlIHRvcCBvZiB0aGUgcGFnZSBvZiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYW1zdWVzcy1jb3JlLXJlcGVhdC1yZXF1ZXN0 LXRhZy0wMA0KYWZ0ZXIgIlZlcnNpb25zOiIsIGJlZm9yZSAiMDAiLikNCg0KOi0pDQoNCkfDtnJh bg0KDQoNCj4gT24gMSBTZXAgMjAxNywgYXQgMjE6MDksIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCj4gDQo+IEhpIGRyYWZ0LWFtc3Vlc3MtY29y ZS1yZXBlYXQtcmVxdWVzdC10YWctMDAtYXV0aG9ycy4NCj4gDQo+IEkgaGF2ZSB1bmZvcnR1bmF0 ZWx5IG1pc3NlZCB0aGUgZmlyc3Qgc2Vzc2lvbiBvZiB0aGUgQ09SRSBtZWV0aW5nIGF0IHRoZQ0K PiBQcmFndWUgSUVURiBtZWV0aW5nIHdoZXJlIHRoaXMgZHJhZnQgd2FzIHByZXNlbnRlZC4gRnJv bSB0aGUgcmVjb3JkaW5nIEkNCj4gdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGEgc2VwYXJhdGUg cHJvYmxlbSBzdGF0ZW1lbnQgZG9jdW1lbnQuDQo+IA0KPiBDb3VsZCB5b3UgcG9pbnQgbWUgdG8g dGhhdCBkb2N1bWVudD8NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0K PiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZQ0K --Apple-Mail-779B0C3A-7994-4FA6-AD5B-B6373E94ABA2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PHNwYW4+ PC9zcGFuPjwvZGl2PjxkaXY+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxkaXY+PC9kaXY+PGRpdj5IaSBIYW5uZXMsPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JZiB5b3UgZ2xhbmNlIGF0IHRoZSBmaXJzdCBwYXJhZ3Jh cGggb2Ygc2VjdGlvbiAxLjE8L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1hbXN1ZXNzLWNvcmUtcmVwZWF0LXJlcXVlc3QtdGFnLTAwI3NlY3Rpb24t MS4xIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYW1zdWVzcy1jb3JlLXJlcGVh dC1yZXF1ZXN0LXRhZy0wMCNzZWN0aW9uLTEuMTwvYT48L2Rpdj48ZGl2PnlvdSBmaW5kIG9uZSBv ZiB0aGUgbWFpbiByZWZlcmVuY2VzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SWYgeW91IGds YW5jZSBhdCB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiAxLjI8L2Rpdj48ZGl2PjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbXN1ZXNzLWNvcmUtcmVwZWF0LXJlcXVl c3QtdGFnLTAwI3NlY3Rpb24tMS4yIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YW1zdWVzcy1jb3JlLXJlcGVhdC1yZXF1ZXN0LXRhZy0wMCNzZWN0aW9uLTEuMjwvYT48L2Rpdj48 ZGl2PnlvdSBmaW5kIHRoZSBvdGhlci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PihUaGUgbGF0 dGVyIGlzIGFsc28gbGlua2VkIGZyb20gdGhlIHRvcCBvZiB0aGUgcGFnZSBvZiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbXN1ZXNzLWNvcmUtcmVwZWF0 LXJlcXVlc3QtdGFnLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYW1zdWVz cy1jb3JlLXJlcGVhdC1yZXF1ZXN0LXRhZy0wMDwvYT48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+YWZ0ZXIgIlZlcnNpb25z OiIsIGJlZm9yZSAiMDAiLik8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj46LSk8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkfDtnJhbjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJy Pk9uIDEgU2VwIDIwMTcsIGF0IDIxOjA5LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXY+PHNwYW4+SGkgZHJhZnQtYW1zdWVzcy1jb3JlLXJlcGVhdC1yZXF1ZXN0LXRhZy0wMC1hdXRo b3JzLjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5JIGhhdmUgdW5mb3J0dW5hdGVs eSBtaXNzZWQgdGhlIGZpcnN0IHNlc3Npb24gb2YgdGhlIENPUkUgbWVldGluZyBhdCB0aGU8L3Nw YW4+PGJyPjxzcGFuPlByYWd1ZSBJRVRGIG1lZXRpbmcgd2hlcmUgdGhpcyBkcmFmdCB3YXMgcHJl c2VudGVkLiBGcm9tIHRoZSByZWNvcmRpbmcgSTwvc3Bhbj48YnI+PHNwYW4+dW5kZXJzdGFuZCB0 aGF0IHRoZXJlIGlzIGEgc2VwYXJhdGUgcHJvYmxlbSBzdGF0ZW1lbnQgZG9jdW1lbnQuPC9zcGFu Pjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkNvdWxkIHlvdSBwb2ludCBtZSB0byB0aGF0IGRv Y3VtZW50Pzwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5DaWFvPC9zcGFuPjxicj48 c3Bhbj5IYW5uZXM8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPmNvcmUg bWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2 PjwvYm9keT48L2h0bWw+ --Apple-Mail-779B0C3A-7994-4FA6-AD5B-B6373E94ABA2-- --Apple-Mail-286873A2-0C81-4BFE-BEDE-7DC6839E896D Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR7DCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF8jCCA9qgAwIBAgIQPmPdJI0I/Fh4Z0IWiX4FyTAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMjIwOTI2MTRaFw0xNzEyMjIwOTI2MTNaMGsxETAPBgNV BAoMCEVyaWNzc29uMRgwFgYDVQQDDA9Hw7ZyYW4gU2VsYW5kZXIxKjAoBgkqhkiG9w0BCQEWG2dv cmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXJhZ29zZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJJTmaZN/AJeYDz6jrMPRAFTMd1Ijw2eHX8gmp1QI0yxcaHKHXdU HR9v92W8bE24UrsQrMoCZXngRVqMv4VG5yDF6f2VwLtunh/Wp3dq72SA5dgrMe7D1u1HXG6pYb5+ /OtkZpIC3Zt7Bl6dpmfJlbGhf2juJrZm+JaS2vR+sGVdyKinIiUyciBngPh6J/jvCVxf9k8BNi+b 4CR0gfr8+qRj/wKrcUwgti+tG87lfWmvPK4sf52y64RNR4ZtsdCtT4LYMomcTrFWbgr2dcG+lx+R 0pVC6qqDs7vVJ3VBEPK3oEJeOtJnimtHL+fboNToUxwifYOR5d1aebxKnHGgT/MCAwEAAaOCAcEw ggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDov L29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlh c29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY2VyMCYGA1UdEQQfMB2BG2dvcmFu LnNlbGFuZGVyQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsG AQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFIHidNufe3WwHbOEvGidlbceG/3/ MB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG 9w0BAQUFAAOCAgEA1JVNvEJtJx5cKn+1f5QKWgHmrlQjvjdDm8pX6H5MHzpxoaccG4G0dq1UlMP+ T6bK3z4H4i7rQzZStfeAGbBJNbpjwxmG1diKM4w4+8pXKoeR/2KRUxYMEob5vo71QH4Sia1x9ntw SVcK78CNdbhDsJlZXA+sk5Et5zqZ8RH26xgRrQ7H6Z5ZbmxEMpUdMWBWCy5vf7ii7OA5CmyoatDJ 1iGi8im009qVYZJJMxilb6vqu6RJD+xSOXnikIBJmPnOz2ZC71+FG2bgj70dwE1J7X7KroQJbRm9 zzbKdhMXHfDQCu3WGaad3t64zXsnOk5GuHfLTsN7LTBzdGg/jPghI19+wL7P6NUyXngfU9hiIO4e I9/5wyiuUxcU+zutMWBlL+ZjUHa/6pk/072TiL+Dgc9CWwmCdbELlNaW4yw4fNBLfkVH6h6L/flo PA1i90+LF5Y2FSaRHi+1/J2Oktb7d4rLFx/Qd/9JUm7MxiueywEV76Ng0Ylga904WMkV9+ooJxGh wnSXbkAtNUO2/eSllqnphldoEB5hOdwZZXK/215uG0gtV2qU7uwu0/fMAZnjps9Nb/ngXtM7Bn6R 8jS+m0WAk3mIADwbA6+EFq2s3D2gD10zaKgCUFuIPeBDwXPszGr/kCSlJ23cbPF3sc3CGLkYiS7I +2rVTsH+jX0pYLswgga2MIIEnqADAgECAhEAoAzLzJuZmOziOnD0fMHAWTANBgkqhkiG9w0BAQUF ADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2 MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZKFzoDkgTIVuhcxlbeUUeyj7/q47d mKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCTu7CiMnfi0cuJf/JCiuIj5vkNfF8h hdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+25Uc2H9Yd4+W u6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicngZrxLowTbCBIFEOiXEBRuZ8tBGsy8 sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo0+rn/IdpLjyMKw4EBTRMiEGeKudm aURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechwx0gQXkG1QF5vMEkwwX10MHa6PwF6 hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr8IZF2ncYemSDF84G+lqY4ry50dBh Cja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6mwOe+vaJvZ5/7 ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0dyE+0G86tqH9xNbNfMaPAzPQ/dQmp NDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5SJ6CYC9QYdz4k YnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2cghIj5mPfLAd m52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN06XqaUNslpMgQZqB1FyYfe7nuvmy dn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3X87MVPAIrzBh uGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs5orjYfaJ87oREdsmISv+iHgrOB0B 6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB47tDJA84joZvgVcD2Sjewe8A+zj4 +r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY4if7vQX6q8qmabnZ1nxvsMQt9u66 TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT81iyPPcMuFnP j4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzOxnkkvyxRnvOCpiY0w370/HNqyvJx Mmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKWMIICkgIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+Y90kjQj8WHhnQhaJfgXJ MAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE3MDkwNDA0MjU0NFowIwYJKoZIhvcNAQkEMRYEFEAwTV35MBw1aANwDkawJiiHbgoTMF0GCSsG AQQBgjcQBDFQME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICED5j3SSNCPxYeGdCFol+BckwXwYLKoZIhvcNAQkQAgsxUKBOMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+ Y90kjQj8WHhnQhaJfgXJMA0GCSqGSIb3DQEBAQUABIIBABjLPekRvTgCZIYCCb2Qy5O9auyVDkWt GSdcwnsp02pshRuD0X9NLrbGFfqfifBWC0L8fM72GWhqpM6s5yvJVV4aw3d2FBk/lCoYuJhxxhpF dYP72Dn6vhc4kFhr39OBZsFAwgnkhef/AWsZnt+UiU3oHkqWkDgIYtgml6dr+upiw30I1JzzP6ZF T+9AqdEXvjcipazppSPNMFVICIikzeJWeY1Sqkl98J6MVSadZC6sxTLjsW3Si71DOIm2k464uzaS SkUuN27IS5Go8qRPSFUEyeylh4PWQij2BDdcweamKBMVVhpR1xB17AL74BE73G3gz9Rb+PbppSR7 uKoOGMEAAAAAAAA= --Apple-Mail-286873A2-0C81-4BFE-BEDE-7DC6839E896D-- From nobody Mon Sep 4 00:41:43 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018D11252BA; Mon, 4 Sep 2017 00:41:42 -0700 (PDT) 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 mQtwsR18yETE; Mon, 4 Sep 2017 00:41:40 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 922A51200F3; Mon, 4 Sep 2017 00:41:39 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:209]) by smtp-cloud8.xs4all.net with ESMTPA id om0ndM7jKcQyLom0ndJ7T8; Mon, 04 Sep 2017 09:41:38 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 04 Sep 2017 09:41:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 04 Sep 2017 09:41:14 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <016d01d32215$5bb82a10$13287e30$@augustcellars.com> References: <016d01d32215$5bb82a10$13287e30$@augustcellars.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJyVMuoy9dJ8SB9Qfnf5UO9cWQaWE1BHBlmGzAUbiCrf8AHwTnj3BudxZtiTdHnboZuSg1pP6JeE1VUVEsQlvIv4zhYWgq9eWfpXnF7bTmd9F93UGpqj E+Nl9cL8wawMgojNpITOAS33WK4AaWsPCKKCm7bU61VOgIrqW0sqhZq1BpbpxYOM/Ci7oq3dvUrogoeXlNHYBOnwdAUhJIstLuipPv74eCdFhejx1lql8qq/ TdJ0Qw1vvizTXGdD7ykI1Q== Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory - More headaches w/ context 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, 04 Sep 2017 07:41:42 -0000 Hi Jim, Indeed, the text 5.3.4 can confuse people. We have added an entity-relationship model to he draft that shows that context is an attribute of the registration. Currently, all links of the registration resource share the same context. Citing the context when comparing links in the same registration resource is superfluous. I think that 5.3.1 should read about all links over all registration resources within an RD. Text will be modified. Thanks for pointing this out. Peter Jim Schaad schreef op 2017-08-31 06:55: > In reading through and working on implementing this draft, I have found > what > appears to me to be conflicting language on the context parameter. > > Section 5.3.4 indicates that context + target could have collisions and > that > this is likely to occur if there are multiple configuration tools. > This > text appears to me to indicate that the context can be different for > each > link in a registration resource. Each update could provide a different > context. (I will note that the text probably needs to discuss dealing > with > both normalization of the context and building the full URI from the > context > and target when doing the comparison. The pairs > and /bar> should probably compare as identical. > > Section 5.4.1 in the third paragraph talks about updating the lifetime > and > context in the same paragraph Since I know that the lifetime is a > parameter > of the registration resource, it is reasonable from the context to > assume > that the context would also be a parameter of the registration resource > rather than of a link. > > In my opinion, these are conflicting concepts of what the meaning of > context > is. Would it be possible to figure out which is supposed to be correct > and > both let me know and update the document? > > Jim > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Sep 4 01:46:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF13F13248B; Mon, 4 Sep 2017 01:46:03 -0700 (PDT) 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 g-hs3LXo5oXU; Mon, 4 Sep 2017 01:46:02 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1C9132392; Mon, 4 Sep 2017 01:46:01 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:209]) by smtp-cloud8.xs4all.net with ESMTPA id on15dMkjLcQyLon15dJVSY; Mon, 04 Sep 2017 10:45:59 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 04 Sep 2017 10:45:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 04 Sep 2017 10:45:35 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <016801d321fc$d2820d50$778627f0$@augustcellars.com> References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfDsyz/oqpyfmPRWJOx4exjhnCLXGUbhKTvSVVn1ci7wIa+e5NGrQMVzgWYRWF0HFAIHn2aQTOyl5i4b4tUGR35e3SnwF2DVCSpZOE6FRtjWy6yyyQyzQ V7EjkBMHoFSWPeyQg27jty9CRdQDwe1y6plqfpcxjQMu6cbmWIWkQLuPPMlOkQa3kUNM9XoMocwrJjrIQKgfFMfaDQMXMcMn/iRNpmjyf6r9b6Lnk3gVXWuZ YHIgd0Bj62JBTRGZCo8bpA== Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 04 Sep 2017 08:46:04 -0000 Hi Jim, Personally, I like the idea. That would mean that all registration resources are returned. In the next version of the RD, location or endpoint identifies the registration. Uniqueness of links is specified in section 5.3.4, already commented on by you. Your request means returning all locations with the ep, lt, d, and et attributes and the associated scheme://authority:port value. Correct? Peter Jim Schaad schreef op 2017-08-31 03:59: > I am wondering if there should be a GET action defined against the > resource > directory object. Currently, if an entity does a registration for an > endpoint it gets back a location for that registration. If a second > entity > modifies the endpoint and wants to update the registration, it > currently has > no method to get the location associated with the endpoint and cannot > make a > second new registration since the pair is required > to be > unique. > > Thus > > Interaction: EP -> RD > Method: GET > URI Template: {+rd}{?ep,d} > > Content-Format: application/link-format (or variants) > > ;ep=endpoint1,;ep=endpoint1;domain=beta, ... > > Jim From nobody Mon Sep 4 02:23:13 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557951321AA for ; Mon, 4 Sep 2017 02:23:12 -0700 (PDT) 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 91XqB7vVqrCW for ; Mon, 4 Sep 2017 02:23:09 -0700 (PDT) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 3FFBE126DFE for ; Mon, 4 Sep 2017 02:23:09 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:209]) by smtp-cloud8.xs4all.net with ESMTPA id onb1dNBdDcQyLonb1dJmPg; Mon, 04 Sep 2017 11:23:07 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 04 Sep 2017 11:22:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 04 Sep 2017 11:22:43 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: "core@ietf.org WG" Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <667da3a73d8ca6cb68c9b61e2e5de5c2@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfCkSg3n0WuP/QBUyethgeBiWn6DxBd1wWoJ03qqFxhMAQZsPWPyQFchfK4+LK/hLxWi6uZS9tSDOwdYhXwu1ewWiCQcgiGoKHS8wlmAdAVUZPuMNhB74 KHBmSMTouAdRCKRQkPNp+agEWPKb7J2UinMkzizTPAtZBPhTApBVBmv+gvm+U/DQ+5gYbCFyu8RJL08EzV5F+4kAMSahUlev5d0Z3MnpoXdQXRK78h8Nhrcn Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory-11 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, 04 Sep 2017 09:23:12 -0000 Hi Hannes, thanks for sharing your thoughts with us. See below for detailed comments. Hannes Tschofenig schreef op 2017-09-01 15:24: > Hi RD draft authors, Hi all, > > I read through some parts of the RD document that appear to be relevant > for LwM2M and I have a few comments and questions. > > Section 3.3. section 3.1 in my version > > This sentence reads broken: > > "In a typical scenario, during a boot-up procedure (and periodically > afterwards), the machines (endpoints) register with a Resource > Directory (for example EPs installed on vehicles enabling tracking > of > their position for fleet management purposes and monitoring > environment parameters) hosted by the mobile operator or somewhere > else in the network, periodically a description of its own > capabilities." > > Maybe you want to shorted it a bit and split it into two sentences, > such as > > "Imagine a scenario where endpoints installed on vehicles enabling > tracking of the position for fleet management purposes and allow > monitoring of environment parameters. During the boot-up process > endpoints register with a Resource Directory, which is hosted by the > mobile operator or somewhere in the cloud. Periodically, these > endpoints > update their registration and may modify resources they offer." With slight changes to your text, this helps the readability. > > I would also suggest to change this text from > > "Due to the usual network configuration of mobile > networks, the EPs attached to the mobile network may not always be > efficiently reachable. Therefore, a remote server is usually used to > provide proxy access to the EPs." > > To: > > "When endpoints are not always connected, for example because they > enter > a sleep mode, a remote server is usually used to provide proxy access > to > the endpoints." Yep, definitely clearer. > > > From: > > "The users, for example mobile applications for > environment monitoring, contact the RD, look up the endpoints > capable > of providing information about the environment using appropriate set > of link parameters, obtain information on how to contact them (URLs > of the proxy server) and then initiate interaction to obtain > information that is finally processed, displayed on the screen and > usually stored in a database." > > To: > > "Mobile apps or web applications for > environment monitoring contact the RD, look up the endpoints capable > of providing information about the environment using appropriate set > of link parameters, obtain information on how to contact them (URLs > of the proxy server) and then initiate interaction to obtain > information that is finally processed, displayed on the screen and > usually stored in a database." OK > > The beginning of Section 5.2. "URI Discovery" does not seem to be > inline > with the text in Section 4. It appears that two different persons have > written the two sections or that the sections got reordered some time > ago. Section 4 is rewritten, based on the discussion during the Prague Core meeting Overlap with section 5.2 is removed form 5.2 > > Section 5.3.1. "Simple Registration" > > I am not sure I understand the motivation for introducing simple > registration. The text says "Not all endpoints hosting resources are > expected to know how to upload links to a RD". Under what condition is > an endpoint unable to know how to upload links to the RD? There has been a request to add this functionality. > > Section 5.3.3. "Third-party registration" > > Are people using the third party registration given that it may be an > operational challenge? Yes, I only know people who want to use third party registration. > > Section 5.4.1. "Registration Update" > > " > An update MAY update the lifetime or context registration parameters > "lt", "con" as in Section 5.3 ) if the previous settings are to be > retained. Parameters that are not being ***changed changed*** > SHOULD NOT well spotted, thanks. > ^^^^^^^^^^^^^^^^^^^^^^ > be included in an update. Adding parameters that have not changed > increases the size of the message but does not have any other > implications. Parameters MUST be included as query parameters in an > update operation as in Section 5.3. > " > > " > An update MAY optionally add or replace links for the endpoint by > including those links in the payload of the update as a CoRE Link > Format document. A link is replaced only if all of the target URI > and relation type (if present) and anchor value (if present) match. > " > > How are links deleted? It is not unlikely that resources get removed > during the lifetime of a registration. section 5.4.4 states: A PATCH update adds, removes,... > > " > In addition to the use of POST, as described in this section, there > is an alternate way to add, replace, and delete links using PATCH as > described in Section 5.4.4. > " > > Do you think it is a good idea to provide two ways to accomplish the > same effect? Why not only use PATCH? One is about registrations and the other about links. > > > 5.4.4. Update Endpoint Links > > " > In > particular, a select-merge patch document format could combine the > function of link selection query and link attribute replacement > values. > " > > Is this referring to an existing format or is this a more theoretical > thought? If it is the latter then I suggest to delete this sentence to > avoid confusion. If it isn't then add a reference. We have a discussion on the format of the file, also pointed out by Jim. > > > " > If no links are selected by the query parameters, the PATCH > operation > SHOULD NOT update the state of any resource, and SHOULD return a > reply of "Changed". > " > > I believe the correct wording should be > > " > If no links are selected by the query parameters, the PATCH > operation > MUST NOT update the state of any resource, and MUST return a > reply of "Changed". > " probably better; someone may protest though. > > (There does not seem to be a better return code than changed even > though > nothing was changed.) > > 8. Security Considerations > > " > Endpoints using a > Certificate MUST include the Endpoint identifier as the Subject of > the Certificate, and this identifier MUST be checked by a resource > directory to match the Endpoint identifier included in the > Registration message. > " > > Why is this only applicable to certificate-based authentication? I > believe it is an equally valid concern for use with PSK and raw public > key-based authentication. > > The threat, which could be detailed a bit, can be described as follows: > > --- > > Imagine you have a device from company A and another device from > company > B. Both are managed by a single server. Both devices have unique, > per-device credentials for use with DTLS. > > Now, imagine that company A wants to sabotage the device used by > company > B. It uses its credentials during the TLS exchange. Then, it puts the > endpoint name of the company B device. If the server does not check > whether the identifier provided in the DTLS handshake matches the > identifier used at the CoAP layer then it may be inclined to use the > endpoint name for looking up what information to provision to that > device. > > --- Thanks, but I will remove the suggestion that it is a "no rules respected" world out there. > > Section 10.2.2. "LWM2M Register Endpoint" > > FROM: > " > Endpoint Name is mandatory, all other registration parameters are > optional. > " > > TO: > > " > Endpoint Name, Lifetime, and LWM2M Version are mandatory parameters > for the register operation, all other registration parameters are > optional. > " Thanks, will do > > In Table 5 you show some of the parameters used during the register > operation. Why did you omit Lifetime and Endpoint Name? They are "additional" registration parameters. > > Use the term "Binding Mode" instead of "Protocol Binding". OK. > > > +------------+-------+-------------------------------+--------------+ > | Name | Query | Validity | Description > | > > +------------+-------+-------------------------------+--------------+ > | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available > | > | Binding | | | Protocols > | > | | | | > | > | LWM2M | ver | 1.0 | Spec Version > | > | Version | | | > | > | | | | > | > | SMS Number | sms | | MSISDN > | > > +------------+-------+-------------------------------+--------------+ > > Table 5: LWM2M Additional Registration Parameters > > Why does the RD not have any version indication? Would it make sense to > introduce the 'ver' parameter as well since it is quite likely that > there may be new versions of the protocol. Also the use of the protocol > binding may not be too far fetched since devices may run coap over > multiple different transports. Looks like a very sensible suggestion. > > Btw, I couldn't find a description of the "Endpoint Type" in the > document. This is a parameter that is not used in LwM2M but it is also > not clear what benefit it gives. et is discussed shortly in section 5.3 template. Its use is rather application dependent, but there is an interest to provide additional information to the rt value. > > 10.2.3. LWM2M Update Endpoint Registration > > The LwM2M update is really very similar to the registration update with > the only difference that there are more parameters defined and > available. All the parameters listed in that section are also available > with the initial registration but are all optional. Will use this text, thanks. > > > ciao > Hannes Thanks for your suggestions and interest. Cheerio, Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Sep 4 06:09:40 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D7613218F for ; Mon, 4 Sep 2017 06:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGb3Tfxy5mUH for ; Mon, 4 Sep 2017 06:09:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 A54B8126BFD for ; Mon, 4 Sep 2017 06:09:36 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.205]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPqtK-1dtn573eEc-00526B; Mon, 04 Sep 2017 15:09:33 +0200 To: =?UTF-8?Q?G=c3=b6ran_Selander?= Cc: "core@ietf.org WG" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <983bc98b-9646-748f-8055-a780db90d7df@gmx.net> Date: Mon, 4 Sep 2017 15:09:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:KZQ8zrVD2WsvKHjBNuZkkbIGdK/PREMz+09XilStZaEOKjgpTdx wWk0YkIIyvjJxsr6nqWFBPKlzvZWtfgcH8j0+OGYcJ+ylKFqW4RgyzUMXrHABr8ZOQjWYBv JLqg5cITkyJvqFKSfUUZ2YXYvLSzd9KudKqZxDA+w+qVVoGszb5c4jZrHgIDbkqhzqAit4n k/GOFbXpYUDwLcXtCsrJg== X-UI-Out-Filterresults: notjunk:1;V01:K0:roVjqVwNJaQ=:NHdiTT39bpxGfWrxZbBi6d Dt2yOdVaDhsls74oaSCycVUxh3fr5ITzXtzQDwEkRkwgRQ9/oGZi6xahMBnw7WMiKJhteLH44 j3oTji7EFLgveLCo1InTe0XRYzQgi8tTMj8AkiaoCIa07bsxK3qHeuwqrJodxi+lOmcr88MZD 8rttl8lzr4FyAVf4CNbKmVmubDw01AbGxIs+qmf7sB2hyDIX5UEs5MVs7iDosPIn4/z7ScSqC t48Fu0GVeylFs5ftMrH+s10J5dUv26QkZmscxYu4eHulby3ld+sywjYJeVd+GKSru5dHgOc7G /r6mHsaWRjmTqBdQb0tSXGcCFTKaDVESDtZydUYuO0rYsCAxu78yv2QlAn3zaXw+5x7SQXmwE 4HFxgyNrceltyXoVE3rwmipnESzGi+3ZlzUKjiRAgKV8Ve5NTW0I/9qbJ1UZOSCnzEFAhhlqX V3rbpsYwtFtXzJO1rUZWDTecGcA6LFuM7TRZvNwIuDWkpXhQ/65rwUAaNWs3IeWNH8LcwQ5HK OF9sU3zJjS6UyZ5K5YouCNh5mszDTbPzJIm1lJs+cUCv0T1AxK3+Gg6sy7vE4LAkJX+AcuxX7 5g3iTtD5ToKEMbKAOt/pjg1mO0gBnWrTISKWtkqzP4aMQ7auVVYnBN5SiEE8HoDyjagzLU6tZ qObBCJ1naZ3d2rit2mhVfR1q3MIb/r+eQqDJOhVFVwo6mbJmJ+YIve7mJwZ3go8fid/M8OiGi AoUdIDsh2OG/weGA+tdjiiw74uSs8Kh6yjMyjYa6ZalBZPuzoJF0zfYg4S8zewb1FL7kPXqGd S1XVhq/rz0yP6rGvnR47sCzmHd56OsbAcnTHT3LWUtcFOg4s60= Archived-At: Subject: Re: [core] Repeat And Request-Tag 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, 04 Sep 2017 13:09:39 -0000 Section 1.1 references the "Controlling Actuators with CoAP" and Section 1.2 references several documents, including "Request-Tag option". Since I have not followed the prior work I am just trying to figure out what document(s) I have to read in order to understand what problem is being solved here. I prefer to understand the problem first before seeing the solution(s). The referenced documents go into great deal describing the solution. Are you saying that I have to read the two solution documents - "Controlling Actuators with CoAP", and - "Request-Tag option" to get an idea what the problem is? Ciao Hannes On 09/04/2017 06:25 AM, Göran Selander wrote: > Hi Hannes, > > If you glance at the first paragraph of section 1.1 > https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00#section-1.1 > you find one of the main references. > > If you glance at the second paragraph of 1.2 > https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00#section-1.2 > you find the other. > > (The latter is also linked from the top of the page > of https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00 > after "Versions:", before "00".) > > :-) > > Göran > > > On 1 Sep 2017, at 21:09, Hannes Tschofenig > wrote: > >> Hi draft-amsuess-core-repeat-request-tag-00-authors. >> >> I have unfortunately missed the first session of the CORE meeting at the >> Prague IETF meeting where this draft was presented. From the recording I >> understand that there is a separate problem statement document. >> >> Could you point me to that document? >> >> Ciao >> Hannes >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Mon Sep 4 06:19:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FE21329C7 for ; Mon, 4 Sep 2017 06:19:43 -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 Yy36UFLnGFUW for ; Mon, 4 Sep 2017 06:19:41 -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 5491413218F for ; Mon, 4 Sep 2017 06:19:41 -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 v84DJarp018125; Mon, 4 Sep 2017 15:19:36 +0200 (CEST) Received: from [IPv6:2002:8666:da7b::5fc:f525:e450:cc23] (unknown [IPv6:2002:8666:da7b:0:5fc:f525:e450:cc23]) (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 3xm9Rr5J8kzDLsT; Mon, 4 Sep 2017 15:19:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 4 Sep 2017 15:19:34 +0200 Cc: Hannes Tschofenig , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 526223974.835192-ec6dcf60b98cfa27308a011b6f6a0daa Content-Transfer-Encoding: quoted-printable Message-Id: <032DDFEC-D8EF-430C-B794-512F714804F4@tzi.org> References: To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Repeat And Request-Tag 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, 04 Sep 2017 13:19:43 -0000 Hi G=C3=B6ran, how about copying over these paragraphs and submitting a new version? (And getting rid of =E2=80=9CRepeat=E2=80=9D in the process :-) Gr=C3=BC=C3=9Fe, Carsten > On Sep 4, 2017, at 06:25, G=C3=B6ran Selander = wrote: >=20 > Hi Hannes, >=20 > If you glance at the first paragraph of section 1.1 > = https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00#secti= on-1.1 > you find one of the main references. >=20 > If you glance at the second paragraph of 1.2 > = https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00#secti= on-1.2 > you find the other. >=20 > (The latter is also linked from the top of the page of = https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00 > after "Versions:", before "00".) >=20 > :-) >=20 > G=C3=B6ran >=20 >=20 > On 1 Sep 2017, at 21:09, Hannes Tschofenig = wrote: >=20 >> Hi draft-amsuess-core-repeat-request-tag-00-authors. >>=20 >> I have unfortunately missed the first session of the CORE meeting at = the >> Prague IETF meeting where this draft was presented. =46rom the = recording I >> understand that there is a separate problem statement document. >>=20 >> Could you point me to that document? >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Sep 4 07:17:47 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3CE13219F for ; Mon, 4 Sep 2017 07:17:46 -0700 (PDT) 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_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 kt8jTLbpKUSH for ; Mon, 4 Sep 2017 07:17:44 -0700 (PDT) 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 019B813219E for ; Mon, 4 Sep 2017 07:17:43 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 3D9E520263A for ; Mon, 4 Sep 2017 14:17:40 +0000 (UTC) Received: from [192.168.0.166] (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_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 4 Sep 2017 16:17:41 +0200 To: References: <983bc98b-9646-748f-8055-a780db90d7df@gmx.net> From: Ludwig Seitz Message-ID: Date: Mon, 4 Sep 2017 16:17:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <983bc98b-9646-748f-8055-a780db90d7df@gmx.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) 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=IkcTkHD0fZMA:10 a=2JCJgTwv5E4A:10 a=CSwXukaKuHJehhSRk7wA:9 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [core] Repeat And Request-Tag 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, 04 Sep 2017 14:17:46 -0000 On 2017-09-04 15:09, Hannes Tschofenig wrote: > Section 1.1 references the "Controlling Actuators with CoAP" and Section > 1.2 references several documents, including "Request-Tag option". > > Since I have not followed the prior work I am just trying to figure out > what document(s) I have to read in order to understand what problem is > being solved here. I prefer to understand the problem first before > seeing the solution(s). > > The referenced documents go into great deal describing the solution. Are > you saying that I have to read the two solution documents > - "Controlling Actuators with CoAP", and > - "Request-Tag option" > to get an idea what the problem is? > > Ciao > Hannes > Since the draft proposes two extensions to CoAP, you need indeed to read two texts on the backgrounds. Controlling actuators with CoAP is not a solution document really, it describes security problems when using CoAP to control actuators and suggests a solution, but in nowhere enough detail to call it a "solution document". This motivates the option presented in section 2. draft-amsuess-core-request-tag describes a security problem with blockwise, and presents a solution, if I'm not mistaken the solution was transplanted to the document we are discussing, while the motivation wasn't. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Sep 4 07:56:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F55A12426E for ; Mon, 4 Sep 2017 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsAD_6xn1UNf for ; Mon, 4 Sep 2017 07:56:01 -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 687051321AF for ; Mon, 4 Sep 2017 07:56:01 -0700 (PDT) X-AuditID: c1b4fb30-597ff70000005897-07-59ad697f4303 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 09.6C.22679.F796DA95; Mon, 4 Sep 2017 16:55:59 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.26]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Mon, 4 Sep 2017 16:55:59 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Ludwig Seitz , "core@ietf.org" , "Hannes Tschofenig" , Carsten Bormann Thread-Topic: [core] Repeat And Request-Tag Thread-Index: AQHTI1XSZhEglLTcPUewuVgmxmKCuKKkA4wAgACSVACAABMPAIAALF4A Date: Mon, 4 Sep 2017 14:55:58 +0000 Message-ID: References: <983bc98b-9646-748f-8055-a780db90d7df@gmx.net> 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.16] Content-Type: text/plain; charset="utf-8" Content-ID: <20F17EC00C8D6442BA8A0687175DD0B0@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7h2595tpIg8tH5C2OTLnLarHv7Xpm i6U777FavPo8ndWBxWPxpv1sHkuW/GTyWNq0mclj2qLMAJYoLpuU1JzMstQifbsEroxNp24x FnwRr3i2bypzA+MS8S5GTg4JAROJxzfXsHUxcnEICRxhlLjbc5kdwlnEKPHt3lo2kCo2AReJ Bw2PmEASIgKzGSV23mhhB0kIC2hJ3Os7ywJiiwhoS2zZuRcozgFku0nc67AHCbMIqEj82vGF CcTmFbCQmNZzBWrbBUaJT91rmEESnAKWEpMubQUrYhQQk/h+ag2YzSwgLnHryXwmiFMFJJbs Oc8MYYtKvHz8jxXEFhXQk9jb084GEVeU2Hm2nRnkBmYBTYn1u/QhxlhL7J70gAXCVpSY0v2Q HeIeQYmTM5+wTGAUm4Vk2yyE7llIumch6Z6FpHsBI+sqRtHi1OKk3HQjI73Uoszk4uL8PL28 1JJNjMDoO7jlt8EOxpfPHQ8xCnAwKvHwuoSvjRRiTSwrrsw9xCjBwawkwvssESjEm5JYWZVa lB9fVJqTWnyIUZqDRUmc13HfhQghgfTEktTs1NSC1CKYLBMHp1QDo4sMV4LP24vX5kXt9Dmw c86BGaqGRR+bk379iqs2Onq/pjq/P3fPH21Fdau8x5fvfm1dPL9x2STrK8uMuZ8uPya34GmF JRejhVtTsLnu2zqDt9mbb5Tk5/ZslrnH8FlD+KriEfu782sMzsqUzvl2dlVI/i5zv8iXbSKP /BZ901upEO6S3yzRrMRSnJFoqMVcVJwIAFvG8mC6AgAA Archived-At: Subject: Re: [core] Repeat And Request-Tag 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, 04 Sep 2017 14:56:04 -0000 DQoNCk9uIDIwMTctMDktMDQgMTY6MTcsICJjb3JlIG9uIGJlaGFsZiBvZiBMdWR3aWcgU2VpdHoi DQo8Y29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsdWR3aWcuc2VpdHpAcmkuc2U+ IHdyb3RlOg0KDQo+T24gMjAxNy0wOS0wNCAxNTowOSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6 DQo+PiBTZWN0aW9uIDEuMSByZWZlcmVuY2VzIHRoZSAiQ29udHJvbGxpbmcgQWN0dWF0b3JzIHdp dGggQ29BUCIgYW5kIFNlY3Rpb24NCj4+IDEuMiByZWZlcmVuY2VzIHNldmVyYWwgZG9jdW1lbnRz LCBpbmNsdWRpbmcgIlJlcXVlc3QtVGFnIG9wdGlvbiIuDQo+PiANCj4+IFNpbmNlIEkgaGF2ZSBu b3QgZm9sbG93ZWQgdGhlIHByaW9yIHdvcmsgSSBhbSBqdXN0IHRyeWluZyB0byBmaWd1cmUgb3V0 DQo+PiB3aGF0IGRvY3VtZW50KHMpIEkgaGF2ZSB0byByZWFkIGluIG9yZGVyIHRvIHVuZGVyc3Rh bmQgd2hhdCBwcm9ibGVtIGlzDQo+PiBiZWluZyBzb2x2ZWQgaGVyZS4gSSBwcmVmZXIgdG8gdW5k ZXJzdGFuZCB0aGUgcHJvYmxlbSBmaXJzdCBiZWZvcmUNCj4+IHNlZWluZyB0aGUgc29sdXRpb24o cykuDQo+PiANCj4+IFRoZSByZWZlcmVuY2VkIGRvY3VtZW50cyBnbyBpbnRvIGdyZWF0IGRlYWwg ZGVzY3JpYmluZyB0aGUgc29sdXRpb24uIEFyZQ0KPj4geW91IHNheWluZyB0aGF0IEkgaGF2ZSB0 byByZWFkIHRoZSB0d28gc29sdXRpb24gZG9jdW1lbnRzDQo+PiAtICJDb250cm9sbGluZyBBY3R1 YXRvcnMgd2l0aCBDb0FQIiwgYW5kDQo+PiAtICJSZXF1ZXN0LVRhZyBvcHRpb24iDQo+PiB0byBn ZXQgYW4gaWRlYSB3aGF0IHRoZSBwcm9ibGVtIGlzPw0KPj4gDQo+PiBDaWFvDQo+PiBIYW5uZXMN Cj4+IA0KPg0KPg0KPlNpbmNlIHRoZSBkcmFmdCBwcm9wb3NlcyB0d28gZXh0ZW5zaW9ucyB0byBD b0FQLCB5b3UgbmVlZCBpbmRlZWQgdG8gcmVhZA0KPnR3byB0ZXh0cyBvbiB0aGUgYmFja2dyb3Vu ZHMuDQo+DQo+Q29udHJvbGxpbmcgYWN0dWF0b3JzIHdpdGggQ29BUCBpcyBub3QgYSBzb2x1dGlv biBkb2N1bWVudCByZWFsbHksIGl0DQo+ZGVzY3JpYmVzIHNlY3VyaXR5IHByb2JsZW1zIHdoZW4g dXNpbmcgQ29BUCB0byBjb250cm9sIGFjdHVhdG9ycyBhbmQNCj5zdWdnZXN0cyBhIHNvbHV0aW9u LCBidXQgaW4gbm93aGVyZSBlbm91Z2ggZGV0YWlsIHRvIGNhbGwgaXQgYSAic29sdXRpb24NCj5k b2N1bWVudCIuIFRoaXMgbW90aXZhdGVzIHRoZSBvcHRpb24gcHJlc2VudGVkIGluIHNlY3Rpb24g Mi4NCj4NCj5kcmFmdC1hbXN1ZXNzLWNvcmUtcmVxdWVzdC10YWcgZGVzY3JpYmVzIGEgc2VjdXJp dHkgcHJvYmxlbSB3aXRoDQo+YmxvY2t3aXNlLCBhbmQgcHJlc2VudHMgYSBzb2x1dGlvbiwgaWYg SSdtIG5vdCBtaXN0YWtlbiB0aGUgc29sdXRpb24gd2FzDQo+dHJhbnNwbGFudGVkIHRvIHRoZSBk b2N1bWVudCB3ZSBhcmUgZGlzY3Vzc2luZywgd2hpbGUgdGhlIG1vdGl2YXRpb24NCj53YXNuJ3Qu DQo+DQoNClllcy4gVGhlcmUgYXJlIHR3byBwcm9ibGVtIHN0YXRlbWVudHMsIGRlc2NyaWJlZCBp biBzZWN0aW9uIDEuMSBhbmQNCnNlY3Rpb24gMS4yLCByZXNwZWN0aXZlbHkuIEl0IHdvdWxkIGJl IGdyZWF0IGlmIHNvbWVvbmUgd2hvIHJlYWQgdGhlc2UNCnNlY3Rpb25zIGNvdWxkIGxldCB1cyBr bm93IGlmIHRoZXJlIGlzIGFueXRoaW5nIHVuY2xlYXIuDQoNClRoZSByZWFzb24gd2h5IHRoaXMg ZHJhZnQgYXJlIHdvcmtpbmcgb24gdHdvIHByb2JsZW0gc3RhdGVtZW50cyBpcw0KZmVlZGJhY2sg ZnJvbSBJRVRGIzk4IHRoYXQgd2Ugc2hvdWxkIGNvbXBpbGUgYSBkcmFmdCBvbiAic2VjdXJpdHkg dXBkYXRlcw0KdG8gQ29BUOKAnSwgYW5kIGFsc28gdGhhdCBib3RoIGFyZSBkZWFsaW5nIHNlcnZl ci1vcmllbnRlZCBpc3N1ZXMuDQoNClRoZSBwcm9wb3NhbCBmb3IgaG93IHRvIHN0cnVjdHVyZSB0 aGUgY29udGVudCB3YXMgcHJlc2VudGVkIGF0IElFVEYjOTkgaW4NCnNsaWRlcyA5OCBhbmQgOTkg b2YgdGhlIOKAnGNvbnNvbGlkYXRlZCBzbGlkZXPigJ06DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy85OS9tYXRlcmlhbHMvc2xpZGVzLTk5LWNvcmUtY29uc29saWRhdA0K ZWQtc2xpZGVzDQoNCi0gc3BlY2lmaWNhbGx5IHRoYXQgYm90aCBwcm9ibGVtIHN0YXRlbWVudHMg c2hvdWxkIGdvIGludG8gYW4gdXBkYXRlIG9mDQpjb3JlLWNvYXAtYWN0dWF0b3JzLg0KDQoNCkfD tnJhbg0KDQoNCg== From nobody Mon Sep 4 08:27:22 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8C7132A1A; Mon, 4 Sep 2017 08:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 dWOSWWsEsZig; Mon, 4 Sep 2017 08:27:18 -0700 (PDT) Received: from mail4.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 BA9D11329B5; Mon, 4 Sep 2017 08:27:18 -0700 (PDT) Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504538792; h=from:subject:to:date:message-id; bh=vZNmNbBwjMn1hHDzUwSJvZqccQ3Z8XzIs/THbQMWrrg=; b=LwFXs7xKMU+gJIQBBqrUesqZZ0gpfilFshVrpugdl0haDgK7O3WnIkU0kUNh8yMunxkhkb2+gDO fdbu0TfRPC9NH0KHcnNr2EPdRJyysQvK0IagGPlqEzMHho5mFHXYfT2yTkUk2X7NJHp9QJgYZ56hC zIw3edWdUxBa4cXO2jrAi64mGhpwNoVFZFE9/bgCrBhKjTHuU856rHG3vxvLqwV0rkv8c6Gx36rq7 JJcPmTzQ1UZghJMA7wAiILiW2hfSQzf7Umsi2HXQhOl0kacwC2odtHUORMnMmG7Lvb2bGrBxVdFAM TnlaciE1VsCfD4J5CBzjrc+1FH3TZtgoL9rw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 4 Sep 2017 08:26:32 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 4 Sep 2017 08:26:28 -0700 From: Jim Schaad To: CC: , References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> In-Reply-To: Date: Mon, 4 Sep 2017 08:27:00 -0700 Message-ID: <000401d32592$4349a870$c9dcf950$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHzp22oYH48fdIyaCnjuMXhFqY5SQImotPEolKgV4A= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 04 Sep 2017 15:27:20 -0000 Yes that is what I had in mind. It would be useful to add a ttl attribute as well. Jim > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Monday, September 4, 2017 1:46 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > Subject: Re: draft-ietf-core-resource-directory = GET /rd > > Hi Jim, > > Personally, I like the idea. > That would mean that all registration resources are returned. > In the next version of the RD, location or endpoint identifies the registration. > Uniqueness of links is specified in section 5.3.4, already commented on by > you. > Your request means returning all locations with the ep, lt, d, and et attributes > and the associated scheme://authority:port value. > > Correct? > > Peter > > Jim Schaad schreef op 2017-08-31 03:59: > > I am wondering if there should be a GET action defined against the > > resource directory object. Currently, if an entity does a > > registration for an endpoint it gets back a location for that > > registration. If a second entity modifies the endpoint and wants to > > update the registration, it currently has no method to get the > > location associated with the endpoint and cannot make a second new > > registration since the pair is required to be > > unique. > > > > Thus > > > > Interaction: EP -> RD > > Method: GET > > URI Template: {+rd}{?ep,d} > > > > Content-Format: application/link-format (or variants) > > > > ;ep=endpoint1,;ep=endpoint1;domain=beta, ... > > > > Jim From nobody Mon Sep 4 14:30:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E231B1320DC for ; Mon, 4 Sep 2017 14:30:03 -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 zcaVCG2Q1xR2 for ; Mon, 4 Sep 2017 14:30:02 -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 A5EC51320B5 for ; Mon, 4 Sep 2017 14:30:01 -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 v84LTwuH000891 for ; Mon, 4 Sep 2017 23:29:58 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xmNKf10hyzDM02; Mon, 4 Sep 2017 23:29:58 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 526253397.074174-787d95931d1cdd6a0665ab7ffa38aed1 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 4 Sep 2017 23:29:57 +0200 Message-Id: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] core @ IETF99: minutes 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, 04 Sep 2017 21:30:04 -0000 I have submitted the minutes from IETF99; please see: https://datatracker.ietf.org/meeting/99/materials/minutes-99-core/ I need to apologize for being so late with this that you now have some = 150 minutes to send in comments to this list before corrections cut-off; = this is entirely the fault of this co-chair and not at all of the = esteemed other co-chair. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 4 23:28:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF17120727; Mon, 4 Sep 2017 23:28:00 -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 dfr15je9zfs3; Mon, 4 Sep 2017 23:27:58 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E5513237B; Mon, 4 Sep 2017 23:27:58 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id e199so5770419pfh.3; Mon, 04 Sep 2017 23:27:58 -0700 (PDT) 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=tR+FjsJnEMPB50DCQBShhfP1t/RslgvrKxFsQXgaPJs=; b=PpUeLqOXLFDdNjT8NjqUeTYNjGqVXSEVgq4d2N761jkUVX3NXj77nNYzmYP5J84qMl fMSLgkwN01RTCQmpAQ3ZjtZgDBKTG7dLW6bN5Eppu9yx27uZFuvktYCyaCEibZ/WUsSr 4CaG6UtjfeypPIFTRG73bzVN3iSOBs3AO62YCmyrGPT6SI6UTWyX3UG9N4eAJYuBThmt sBACL4E5WWIM1zHM/NapiFuZHgInhCJNYatvx1yWEuKLobCR/qNqyDTqbIrbfd3AN84+ 0u7Bz7jgkmHC5rT7Pgtc0OO2vDU6I2XY2P3MO2wtnmCBxh9B6McPmCaMieTsZQMTAyvx dnww== 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=tR+FjsJnEMPB50DCQBShhfP1t/RslgvrKxFsQXgaPJs=; b=Lnf1+cdcpdA8ARDth3PmwIQ9RAqyYiLO5uRma8EMKLkic/Usnnz8Jc/shBWEJ5Dep8 Oh24ZUNrx6PaPn0CwtXXjIBmy//uuf0/HMlwFqKlkl/1BFR9Wi1ATtxrQ93LXZV75Ih4 BWhtQtfZDGsN2abJsB3xBSbiz0FP7VzwbW02kpZpmTM3tGomf6520DcXcGoDa/+3Z9Xh soUkUpDg8hEvh4Sr+MHvIYBbLa0oi6syzX1AJNUySvAaok2WQUdr8nzoZRZHO6Pwu3dr tldVOmnx6gM82FLbCyicdqal2tQ7ok5IHl5YaQMDsEG9wGUq0UGcdvlamv6ZPfrEJ4S3 Nlhw== X-Gm-Message-State: AHPjjUj26W4vC3BPClmhrSvtv1GEOqtFRqpq9TAeCUiVFdDFt8DQt9j4 6XsN+JIAZfn1/jgiLHY= X-Google-Smtp-Source: ADKCNb4lrZOUzeDlq35g1p4XbhpObgbNmCcjn9PCUeJyG8gfiKdG31cleIFVbsfEaWFPqlxEj1hVGw== X-Received: by 10.84.129.226 with SMTP id b89mr3252763plb.17.1504592878157; Mon, 04 Sep 2017 23:27:58 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id k88sm13302298pfb.150.2017.09.04.23.27.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 23:27:56 -0700 (PDT) From: Michael Koster Message-Id: <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_2890A3AE-A783-4359-B51F-2C1D12AB8DBE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 4 Sep 2017 23:27:54 -0700 In-Reply-To: <000401d32592$4349a870$c9dcf950$@augustcellars.com> Cc: peter van der Stok , "draft-ietf-core-resource-directory@ietf.org" , core@ietf.org To: Jim Schaad References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 05 Sep 2017 06:28:01 -0000 --Apple-Mail=_2890A3AE-A783-4359-B51F-2C1D12AB8DBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would propose returning links for all registration resources in the RD = as shown in slide 4 of the attached deck (JSON format shown). This would = include the most recent setting of the "lt" or lifetime parameter as a = link target attribute as shown.=20 --Apple-Mail=_2890A3AE-A783-4359-B51F-2C1D12AB8DBE Content-Disposition: attachment; filename=rd-models.pptx Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; x-unix-mode=0644; name="rd-models.pptx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQB6XvVo/wEAAEkQAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM mFFv2jAQx98n7TtEfp2Iod26tiL0Yeuetq5Suw/gJgd4c2zLPlj59r0kjEaINQ2Jlb6AjHP3/91F +J/L9OoxV9EanJdGJ2wSj1kEOjWZ1IuE/br/NjpnkUehM6GMhoRtwLOr2ft30/uNBR9RtPYJWyLa S859uoRc+NhY0LQzNy4XSEu34Fakf8QC+Ml4fMZToxE0jrDIwWbTrzAXK4XR9SP9XJFQOIu+VNcV UgkT1iqZCiRQXuzyg3G/LSz2AmVeCJcbh2MepN4LqWutdbZX0MjM5zKFzKSrnMqIrQNP3yVarmgp qTx3B4jURf8fUAfKt1O1VQtjiiyl/FJa/2Hbip90D53MILoVDm9ETg3j1iKvs8UvN/WIQp/rjnMh dROMV0T4Q3jqjue1xaRvslruVzFtacJwtCE4CdKJNgSngxN8HJzg0+AEZ4MTfB6c4HwQguLAvHXG +r7Vd4mb/o1rCX+DEOwSNxEg2Tjw8rP7kVimaVQUDwrucKOg977jc+omitI2vouNWeHWEapF9ybU bZgeEWpCxzKFcYqq3mOZwnhHN6YwbtKNKYy/dGMK4zjdmMJ4UDemMK7Ujemib6/q4XyajN8i1FAn Oc2KpaXT6OugfWP+jX5F9MjS0wk4lPDi8LdTpFm2veDehAvFYJ5BdkCbly8CZk8AAAD//wMAUEsD BBQABgAIAAAAIQCj7IImDQEAAOICAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLBTsMwDIbvSLxD 5PuabiCE0NJdENJuCJUHMInbBtokSjy0vT1hh5VKo5oEx9jxn+/P7/VmP/Tik2Ky3ilYFiUIctob 61oFr/XT4h5EYnQGe+9IwYESbKrrq/UL9ch5KHU2JJFVXFLQMYcHKZPuaMBU+EAudxofB+R8jK0M qD+wJbkqyzsZf2pANdEUW6Mgbs0NiPoQ8st/0ZYDMRpklNpHWoSYySLb7EXUGFtiBcbr51xOxxtF pgZ5Huj2ciDfNFbTo9e7gRyf8Sxpz+QMmXkkDGGOaPmfRFPm8X9CYBkipWzkmPsc0OpyoN/3YcyM u93w5tD2I80prVOveA/UfmcmJ5tZfQEAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAA AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgie RD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgO zXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sG cZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsD BBQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJl bHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFi F7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/O ENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIa KWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2 bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9p wFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+ zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYA CAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzhI/B CsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3 wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE 88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nY yPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlNS54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9 e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8ii UDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2D eY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL 9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHOEj8EKwjAQRO+C /xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9O qx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2 Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZf c5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGU3LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd 5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457 pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrF g7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAA NwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOC54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2I SFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0O wZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF 2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD/ /wMAUEsDBBQABgAIAAAAIQC1asWaZQEAABoIAAAfAAgBcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54 bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALzVzW7CMAwA4PukvUOV +xrK/yYKl2kSh0nTYA8QWlOitUkUZ2y8/Tw0QUHMu0RcKsVtnU+xFU9mX02dbMGjtiYXWdoRCZjC ltpUuXhbPt2NRYJBmVLV1kAudoBiNr29mbxCrQL9hBvtMKEsBnOxCcE9SInFBhqFqXVg6M3a+kYF WvpKOlW8qwpkt9MZSt/OIaYnOZN5mQs/L7NMJMudo63/T27Xa13Aoy0+GjDhwh7SecAXbx1SUuUr CLk4hFKiCvmHohtTsdXweaY4hFhFL6YiUJHgeA77pdw/MxbRj4pQqxoWYVdTXx1KEo5BVhITgrUu 4VlhAH+EtIIoWwv2gKK2yn7TM9AvhUVE7RQG0eUKFLVTGESPQwyid8nlcvQ5xPBKiAGHGF0JMeQQ NE/iXedMT4w4xP2VEGMOkdGsjXcUzmtDd9cCQqDZ3bpMz17QCDz5MEtX2vyMPXky0affAAAA//8D AFBLAwQUAAYACAAAACEAu+N4yYUCAACODQAAFAAAAHBwdC9wcmVzZW50YXRpb24ueG1s7Jffbtsg FMbvJ+0dELdT69jxv1hxKq1TpUqdFDXtA1CbNFYxtoBkSZ9+5xCSsFiT+gC+A75zDvDLBybzu30r yI4r3XSypOHthBIuq65u5HtJX18ebnJKtGGyZqKTvKQHrund4vu3eV/0imsuDTOQSqCM1AUr6caY vggCXW14y/Rt13MJ2rpTLTPQVe9BrdgfKN+KIJpM0qBljaQuX30lv1uvm4r/6qptC9Mfiygu7Dr0 pun1qVr/lWr+Lv5dkmY7vtq+aW4eOmk00KGEbU1337WYpJdNZbbQKOmELoCHFvVvpg1Xj/WTNlcj pKlLGoVxFufTNAaoqsARiA1psJgH/0n3Sz3WxyJJ6mVHmG2TT3IaefJ0ICeZJ8dD2V9aMpRnXnY6 kFOwz3lj2VAGgmc5H8pTT56hfMTiQ1h9kmpf0lkYx5MJzFYdSprmSW475tCDRXWlOJfx3u1ddoZr l3aOxLRTDQuw5mu2FeaF783KHARfzFkBY8ulcq3npSKC4ang8uZ1ZVfnh4idCHuIaZl6QkcQJt7h RAlKoMwLe1t9ljROMrA8bNIIG8LZk/ypPqyz0L/SdSFkA1PBIVluZWVQ91ahoVIIG6bkgys8tFgT dd2Jpn5ohLAdPID8XiiyYzCb2R99dhVlZyXIbc0qYPejlTfC4OZYwdmVwNlRqPSVUOkLDuAEvxsr HA8sBM3oguYEYeSDUByf6YXP0Zajf3YCoTg+8YVPOM3CFN0/GgipOECJByiPcns9jICQigOUXgBF UQ4GGh0E9zJScYAyD1AWT+2HanQQUnGA8gsgpAPvj/EO2gmk4gDNPEBpko2XtH36IBX7kh0+MeF5 6//9WPwFAAD//wMAUEsDBBQABgAIAAAAIQBXy9PenwIAAE4GAAAVAAAAcHB0L3NsaWRlcy9zbGlk ZTEueG1stFTZbtswEHwv0H8g+FxHkq3EiWA5iO24aJsLcfIBNEVHRCmSIGnXRtF/75ISE+RwEBSo HnSQO6Od2eWOTreNQBtmLFeyxNlBihGTVFVcPpT4/m7eO8bIOiIrIpRkJd4xi0/Hnz+NdGFFhQAt bUFKXDuniySxtGYNsQdKMwl7K2Ua4uDTPCSVIb+AtRFJP02PkoZwiTu8+QherVacspmi64ZJ15IY JoiDzG3NtY1s+iNs2jALNAH9LKUxKKMLUfmn1XeGMf8mN1+NXugbE7avNjcG8Qr8wkiSBmzBSbfR hYVPCWHwkryAP0QmUmxXphmPSAHa0LbEYP7O3wFECrZ1iLaL9GmV1tdvxNL6/I3oJP4AMnj8qVfV Knotpx/l3HEnGMoeVbWhBKAXiv60SCrQ6eW38ujVJpJ5zZ5e18jtNDhDnQlsXWi7HyyJEAu2Br/c dqKqnde+hGdYJIWwbuF2ggVPIHNSAD/coAKC+CZlsne/8OykcOMZcQRdqooJi6D50FTdnqMRGOGg Dh10uY8AArq9d/5wy6xaG8rQjBtGnTK7Z/TAAUmCvigGXlvD99s+iLYv1ksXnO97PdCH0dd/ct6u l63z0KrQR7FY/7kCl5zWhAn0Q1nHzBveBIPer+L3tWQof4bdA0BLYpngfjINUrhiH7j6I+iuab6g fpoNXwCYrG6IIbev+2xfiUOl48CA03thoel0OMdrw0v8ezI5OepPjye9SZbPe/nsZNg7mx8d9uaH gzyfTo7PpoPzPxgwWV5Qw8Js+hZnLCy+mmsNp0ZZtXIHVDVJOyATrX4xoxUPMzJLu0G7IaLEh8N+ lg/zNLYCJBl6NSYLCuLoo8JcEn29CWcFJjrUchqWNMxw8M2HPoV46TAy/wIAAP//AwBQSwMEFAAG AAgAAAAhAIvizDOQAwAAUwgAABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWycVV1v0zoYvkfiP1i5 4YYubfqxNlo3rV2HkBhM6xDXruM0Fo5t2U5phc5/P4+dhnHYOIL2Ik3s9+t53q+Lq30tyY5bJ7Sa J4OzfkK4YroQajtPPj/e9qYJcZ6qgkqt+Dw5cJdcXb5+dWFyJwsCbeVyOk8q702epo5VvKbuTBuu cFdqW1OPT7tNC0u/wWot06zfn6Q1FSo56ts/0ddlKRi/0aypufKtEcsl9YjcVcK4zpr5E2vGcgcz Ufs/IV0CGVvLIvw782g5D29q986atbm38frj7t4SUYCvhChag5YkPV4cxeKnghhe0l/Ut50lmu9L W19e0BzYyH6egPxDeEKJ5nzvCWsP2dMpqz69IMuq1QvSaecAEfxwGlC1iJ7DyTo4j8JLTgY/ULWi FKofNPvqiNLAGeC38NjHXWcsYA7mTUX8wYAZH0wd5drLyEcn78BpJMvvF7o4BOAb/MdDmkvn1/4g eSQEYdMcxvEA/ZKGCuWq93kdrNPcX36pqH/jiK+EI3SjG391AQo8MhD18IQJeO9c4bXl4veMDDtG llp51Au5l5TxSsuCW5IFx6iWDv1f8iMKZLej8DfUBGC/FMlofI4GipUyGGfD8/NZi7+rl2mWzSZB IFTNaJyNZ5NhkPi5GgLrIfSOiY704E6hZ68br0vhSQnUa0Yl8jjLxsGoVGvDHnjRsNB3iL+P39F8 m7hg4+/ydqctJw+r9WPZSLLUDyvycPOWVCgfW/NCUMIQhtXSkRfyGZP6/3Vxo9UbTzaW06+EqgPq Q22JqI22GGz+NJt3dCsYMdSi/T3GJ+F7ox0vCHVECgVH3luxaTx3pzlYc1n2Cu6YFSZQHa2iuDVp DzeccMoqcCMlj8k4zc9qb6RgyDUGom4s47Fv4aQUSsTZiiqwWAqF0QINgFVAtlY3hggVFgPjp/mN SccIdmKDUQP20NBxGhNdtg5OJQ6ZhcUnADH+QoeFE7JD1U9guiS9Ja7SDRaaa0yoCwQknA910jhO GHUvpvH5LIkjpVsa6MgPDuPHxFneWDFPvi8Ws0m2nC56i8Hotje6mZ33rm8n497teDgaLRfT6+Vw 9U8CncEoZ6jYkIH33Z7F4bPdVgtmtdOlP2O6TtslmRr9jduYL+zJQf+4bHdUomGz/nAwnU4G09i1 MbY4FbtoAaHbf0zaO2o+7eLQxVpHoS/jkQEzYaRA9EkkYMfe/BcAAP//AwBQSwMEFAAGAAgAAAAh AE3XqcAODgAApbAAABUAAABwcHQvc2xpZGVzL3NsaWRlMy54bWzsXdtu2zoWfR9g/kHwe2pJpG5G 04PmdmaAnrZI2nlXZdkRjiwJkpI4GMy/zyKpq027iS03Tcw+pLYsUiK572tz8/0fy0Ws3Yd5EaXJ 6ch4p4+0MAnSaZTMT0ffv12duCOtKP1k6sdpEp6OHsNi9MeHf/7jfTYp4qmG1kkx8U9Ht2WZTcbj IrgNF37xLs3CBL/N0nzhl/iaz8fT3H9Ar4t4bOq6PV74UTKq2udPaZ/OZlEQXqTB3SJMStFJHsZ+ iTcvbqOsqHvLntJblocFuuGte6/0ASMLbuIp+7/IvuVhyD4l93/m2U32Nec/f77/mmvRFPM10hJ/ gWkZjasfqtv41wS34cN4pfm87smfLGf54sN7f4KxacvTESb/kf1FI38SLkstEBeD9mpw+0Vyb3B7 Kbl7XD8Ab9A8lI1KjGh9OGY9nG9RGYea0YxK3Oqj6ac0+LvQkhTjZMMXwws+39edsTGz7rNbrXzM MDMl66q6T/zI56O+v8Cc8skql2fp9JEN/Af+5xf9SVyUN+VjHPIJwWv7E3SOP5j+2GcUGiYn329Y 7/6k/HCeXl9q1xfahV/62l/pNIzfYwpKrABvh7/oAk+vH4WPYi42zwitZ+Q6DMAFc8wKYY8DjYgx 88/dhe4OjL3WyhK7pqEbIBusqOES3TKoePt6tV3LI5Y10tiSm5Zj28RmNzRLiTHkRflnmC409uF0 lOPFRuxB/v2nohS31rewy0l6FcUxrmM2E/a3SONoyq7xL4xfw/M41+79GIu1FEvauwvPZi35bInF LdiaiB6vwxk4AWRq8Jfg/N/25wcBmKzuM05wN2s2w9ObhuTnDav7WdNwNsOAm8bmzxs3LfiT06Rt vIiSNJd1EDevPBP3i9GLUbf0U5OqlpfxeYrpA//6SXCbQp4FZS4Wdp2EQfGaH88hbpubwmT61c/9 63W63oVoQT5CKrVEy6lsGKI1ddvhK9qKqC7REpNSl/OIotmK3BsKFJzyRmg2Z/y0KonZtV0EDPph TcsPRRjP9pbazjoDcCk6BAOYBrGIYW6W2kMwwLYpFDJVSM34bgE9J2Q31fGvkjl3C2YlcJFu15fB jo105gql9xClGyaVrBdM+tvrhl05rVU1nAiebRF567zlMqobhLeo5TmepXiLW2fK7oKxyKzOX253 vRRvGTAgVy03bzDmclzPtjmvHs5y6+mURt0ITaQUV88bOlan5sWYqwnWtG4RGG4g1UUMgxrWgf0i xV3COFMhA0hwecjgxbiriR12uIuzwxCGIaHEtcmWUJlyulRAjpG+iB0fLCD3YtxF1g1DEYMYhLsc yzVEzE5Zhiz4pMLdx+V2SVAeYzCYh+quads8/qi4S3EXQ8COi7skcJRAPYfQXQYl1La3WYa2RwgP 1++KR3WAzxo5bgyNh9wHDp4gNULgiNnHuxKAa4XDCmuEGQ3rKOBh4JMgzcN3+bSHoGz0FSqwmNNj PTI+WBbN3YyJG7bEGOFB250X1HY8opsgFAaLE1f3LC5+W3lpAFOkgMI5Lk5e05Jy5L38UC3MyTxP 77Le8oAsnx2EN5CVsxooNJy9YhmmY3serZbAcV3T3BIqNEzkMXh7cZXKTGhzGZiEeF3o066iQ4Ie gZb3icH16dZxiXtg/Egl1NQpOL8x2R5Guw6SnGBKQB5jP5SnywOmzlTpL3U38vmPJoPs6uLy48VH xtHQa714tcoweGUy/qWCXaYEqAHTDKUkTGo4ls4ZrrUvh85g61F+oRikm2TaTwptkuN+Y23ym2Et pgRrAdMMxiAOdYj7SzPcFIMoBqmT0mE3tPzGzYhnu8emJAFUmEQ7Ryi6JhahuumYKxGKrgZR7nFl AB5rjoswf59Pt5KwDmh5KMFOiGe67sr2oi7dDoGiK/dYucdcasMF3yW0aUpCRCIUOYzsdnTHEsaS sv7V5qy1/YVP35z1Uu4xkcSPwDRDKQmqE+zP3QaoDbDBS7nHfM/kG9kJ1prrvV25L8YgkvgRmGYw BiG24TrcKlMaRGmQ16hBJPEjMlz8yNIB5VPen5xBlHus3ONdXAMiyYIVqT2DuAbU80zb25L1oNxj Edd481Gd3xg9xiaItcwf8MVQxo1FdAdhItafXHYPwQPK+lfW/8ZSM60zsVv8iEjSTcXOoUGUhGUT A7lxikFOR30cVxX3QbgfqZxPLu7zYu6xJH0XTDOYBvFsw/61NRwUeqzQ4wHRYyJBj0UVtt01CDFR ewGBW57fjg0Jq3UYDMdFrTdAH6zu26vKb99VjDUVn+rMeCj+LI2SspccDyNUvs9ZeCLPRliJBGHF eu8j/BwdJaGY1cHWFjU2iLslNqhCH2yu4fy/eR9yYLqVoKKg5eHoFmWX6IFBH5UZoDID9skMoBLg U4QqdtbLXdmNxHlqHHrzSD/00S++KvwpOmIaVRX2O1oNsatB1Sqc3QInQGzWIotguaFUDNLu3d+g /JhiryM3wF6MvSSgqwBJh9FeDnW3gq7DB+6V9urVTu+HQ4/Vv3kx9pJgw5SH6XdmL0s3HGLXjj2r IrFlV6Vy7I9cr4iwxrMDUnC6162u/fDcPt2ibsahS3spx1459ns59hLIVgSjBpHdcOxdwzxwcKvv 2HcRqYuzy8sr/nSEPXu3qR3xakc8+KautbS54hKVQLYo1bOPa95VEiY1TVvfgloM7zsoBlGQ7YCQ LZVAtmCawRgEW8booTdO9lRDr2SE0iB931qVjHi+myHBvcE0QzEIsQxbFzi6PG1UucfKPd4l5Z9K cG+6H+7dtXyIpduGd2DXQLnHyj3exz22JLg3+GIw2e2auisSQOWye3jrX4YcWGu4N7Yhyw60c+vL zJ2ue+Lz27OglHOtnOsnOdc4tGctAguWG4q9qEFxXuSBd5X1KL9hiu6xW4q9jtwAeylgzpLg3uKc rEGCu5Q6luFt2WystJc6GYjR/hs9GQiF8te11364NzU9C6fZ1ZsVTJS7Y7KzNQ4RLfZwUOsr3KzA h7FSjD9KihKntoe9fQebfdVgmdwg/JJNkvtz9pEdXM0lGTZ+RdPTkd3Iu5sy96P5bal9zPP0QTtP kwRH16e5Zre1FpouYMuW+MK7wMzyDaJ1hcFkWv+COtHiJ94DkIPgc/ctkvuvOYaI672XK/hL+pPl LF9oszjK/oOdCtzcTnFK9BJfbFcnOKKGb2HwqG6LonPtihu661lOvT3Fsj1xA2aJ9cloI8uL8s8w XWjsw+moqMbeDFo8z7//VFRnY9QNWOM40R7wFp7OXJ1gkWEai2TO37Bv2XRhA+YGCP+AOQJpXIeT cYq4H8WXyVQrH7MQ2xTZ7FfK/wkHOz2hJo98q6Mu3rf2SLrGl1itbZsexPRILbe68Q5Rz3JZN65O FxAGsThPl1FPTcvNhx7dgLhqom4Q2s1EzaMofYoEAbW0iyJue9IuIxUJxZqWR3CCWV9G9SgWWxKJ OCNGUWwcX4czsRBvmWKdJmiymWLbGArkq5DkXTGMI8A2yWFWiYSL6J3l8AZaRoVOneIgnJ6+7dGy AX1sGfwORczHQsyNkbeRmJ3W5pMSMzvZp6XYnmBujApub+xsVPyLGRVS84LYJs6kAEOyHZJS84Kg LC3LtOS7Xw3PEdt6FH0fC303+S2b6btNd5HTN7po6Xs/Iu7I5i7pmpZLXRF471jGXdL1sJ/MEVyk LOMjsTMagHIz6bZ4pZR0mdPTkm5PNDc2868QzcSyLGO1tA1O42tFMzWxTViZHnBDqu0dYt3esh2N 3PEqvrSRvsVRIaueXxvOYABLS98HEc0UZcss1Nfom81d0nXZmSb8BmVVHIlVgTocPyXdNkdQKprZ lvOWdHuimW3c4D8dSjRbqAjjsMPihNVsOWtuoUGpDU+wspp1GB9VmEsF5Y4hxAHU62f07bU4tpy+ EazeRN91qHkA+u4Y1F2qNj1Dx4GdK1K7S9WO5djiKGAltd+I1N68y8FrvMBr4CR+Mo9DTRSS47YF C9BBvzNso0U5avylC3F0qK1b34OXbXd5wK5134Y+/aaHQ/SSuNXBmCqJuyllxtPVnp3EzSDX1VO/ wTScKYDV7MsglJjE+rWJgF0878K5pGcXlQXT4yOVyqdS+Z6Uyofi7esMst8uh64GsQwdoekX2yd3 fn5uqKOVk7LGtHcAxOOmsQQQzybl8iydPjL74Y1mC3lNtLJjYrXhyV00iG1RxwX6ztxUAigeRv2K Qc/OI8dpma+vtCmPJrXZQnGa/n2XneRh8cRUoc2mrsHQsDVV3uLRey+EZ+t0dUevgUiuQ9/OQoTZ AOvQ+NAtQ7DF2cem6nIEslMJRS4CJ6VwWWoBS7dCEF1nkZ1XV+xXzhHzfIiVaPLmuivBZcle7p+F E2KYbLKQXWZvK807RKJw5pflVRTHVRbcw/R7dhH5IpNtNj+PkSvY2bTSTRETaWfdso92nd7Gq0F+ QabevR+fjmh9GRGRJl+M+xPNA37UT2I5dnioaPhwG5VhZV5Xd6CL+o3Ziyk7W9nZT7KzDb1BhbrM 2qag7Ki/XB3oImdWi3oUErIvNhELdFnQ842IzemT1BfwsiL7lochC31BgyCBtvqk3eXR6ei/Z2ee bZ67ZydnBr06oReec/LxyrZOrqB56PmZ+/GcXP4PuamZQSdBHvpllCb/nmrLRZwUE1w8Hd2WZTYZ j7k08Yt3iyjI0yKdle+CdDFGwmUUhOMsfQhzXp99bOqGPl74UTISgoUF1ogDK5CvF94Xb8nJqH5b BvndxFP22kGc/+VnX+65IFz4RRnmEFC4lEXJHKvNbm1vYWNHu/8DAAD//wMAUEsDBBQABgAIAAAA IQAndRNMUAMAAHMHAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1snFXbbhs3EH0v0H8g9qkFKq0k S75sLQeWYhsBUtuoHOSZJkdawlySIClZQpB/zyFXa6OJG9h52Qs5MzznzIWn77aNZhvyQVkzLYb9 QcHICCuVWU2LT3eXveOChciN5NoamhY7CsW7s99/O3VV0JLB24SKT4s6RleVZRA1NTz0rSODvaX1 DY/49atSev6IqI0uR4PBYdlwZYq9v3+Nv10ulaD3VqwbMrEN4knzCOShVi500dxrojlPAWGy938g nYGZWGiZ3sHdeaL0ZTZX3i3crc/b15tbz5SEXgUzvIEsRbnf2JvlXwMzfJTfua+6SLzaLn1zdsor cGPbaQHxd+kJJ17RNjLRLornVVHfvGAr6osXrMvuACB4OjSxahn9SGfU0blTURMbPrFqTTlcP1rx EJix4Jnot/TE9aYLljin8K5mceegTEyh9nbtZtajsw/QNIsVtzMrd4n4Pd55kVc6xEXcacqCADav EBwPyK95qlAyvU+LFJ1X8ewm1uTZH8aaP9mHxnERwyk0iEhBdsQTMXB8dxY+WzH+X5KDTpK5NREF w241F1RbLXHUKJ2Mcunov1EgJZHeTsO3aJPoGrTW+TrapYpsCWwLwTXkPhlNBrmAQLYVMhm/Tcd/ aaVCJI9uZZytvF07Juwa7b4OxLjZMa3MA+MxenW/jhRYtGgHqKOWO4Yk7H3ISGeVieEvFmxeF2vv k4i05Y1DhanANlwr+TeLqdwRhrZOYzKkHUMkSb6QwZzGn5fCVQatrX0A9seM3VNce7OHlggExgPD UQnw98BAiz2qWLPGelB+YvpraK4tkzYNPLZH1FJj9yR4kjTVbRbDPBlGfg99MHf3mxwGz7sZ/q9h +QyyWQ9JAjlLmnMp2dXFHWso1lbmbArQ7nvJKIp+MoF4XtEmQ4V/bgXoB3iB9DLXw+t6LbdcN1WR 848B7enysFt7NS2+zGYnh6P58aw3G44ve+P3J0e988vDSe9ycjAez2fH5/ODi68FfIbjSnjKA/xD dxFh8Yfh3yjhbbDL2Be2KdtbpHT2kXwuTlwkw8H+NkItTouj4ehoMBlPusYEyDw0OrBg0N0PQvt/ uLvZ5KGEaw89M89LDq2D0ZBMn00Sddwr3wAAAP//AwBQSwMEFAAGAAgAAAAhAOW4S3y3AwAA8Q8A ABUAAABwcHQvc2xpZGVzL3NsaWRlNC54bWzMV1Fv2zYQfh+w/0DweYosS7JsIXYRu3UxoGsLJH0q +sBRVCyMIjmScewV+e+7oywnXRy0KAZYL7ZE3h2/++6Ourt8tWsl2QrrGq3mNLkYUSIU11Wjbuf0 0806mlLiPFMVk1qJOd0LR18tfv3l0pROVgS0lSvZnG68N2UcO74RLXMX2ggFe7W2LfPwam/jyrJ7 sNrKeDwaTeKWNYoe9O2P6Ou6brh4rfldK5TvjFghmQfkbtMY11szP2LNWOHATND+BtICPOPXssJ/ Z26sEPiktm+tuTYfbdh+v/1oSVMBX5Qo1gItND5sHMTCqwIxeIj/o37bW2Llrrbt4pKV4BvZzSmQ v8dfUGKl2HnCu0X+uMo3H07I8s2bE9JxfwAgOB6KXnUePXdn3Ltz03gpSHL0qhNloPpO878cURr8 RPc79/j7bW8MfUbzZkP83gAzHk0d5LrNwEcv7wKnPdAjE1leQJYEOpJims/CSY+cTMfj2QT3kZkk ydIRvCCW3hCc0Vk2pd8tdbVHRv+Ef0THSgV5eXXndd34TutxSzp/7fdShBgAU6wMGhYiLhkWhVDR p2s8jJV+wbUVF7YijSOMcC2l4JiPRNdQRpXRjfIOUfmADSzBMxgFeD2sgBQZezks2TEskBNLvSMp Hg9p2tFO0BQkyiFcT7PuOywn+ajI0klHc5YUk3TaOdbnXp5OgWcQQJ6zfJylyeQbnsEb6/xboVuC D3NqgQCK3LDtO3cgtxfpmF83UiLpL0eI3FsG2eX+vmNWUGK9XGmJdYEGnMHArX86cMT9A1Rh8qA1 vD5UyNSaccjWlb6zjbAdC9yd3oEYQjqgul98PhHdEOIX8uZ/Pp6Qr+cGQAjdWFHTktDYitvGeRtu 1Zj+NgBo8IVAZE7Iehh4PMI5XBuDQAT1WpJsdO5YPZw9W4ZbSXXKOcsLMYyS4lp1Ocyw4/tcV3VV lsn4S5kUo2JMz51IcB/Zp0UW9R/iIVXb2ZMdWBIGwyh2rDVSHFmKsKEdBFUiRFHzOqrEFlr/QYCS CAq6hyEEsML41VJrG6VnL7uH89b9lxPHP++yQ9PZz3TQ5EKLio00trvQ983p1+VyNhmvpstomWTr KHs9K6Kr9SSP1nmaZavl9GqVvnmAztEkWcmtCI3O7/0YDIvPRs+24VY7XfsLrtu4m2Fjo++FDcMB jLHJ6DALbxk0uXmRZ9NkNstCmx2ghV65Bwse9NMpl/YPZj5sQycKQ7cXdhWWDIzZXYf9RARdh6n2 XwAAAP//AwBQSwMEFAAGAAgAAAAhAARaOCuuAwAALxAAABUAAABwcHQvc2xpZGVzL3NsaWRlNi54 bWzsV01v2zgQvS+w/4HgubYsS/KHELuI3bpYoNsWcHpa7IGlqVgoRbIk7dgt+t93hrTSeONgW6BY +9AcYokcPs68eRRnrp7vGkm2wrpaqwlNuz1KhOJ6VavbCX1/s+iMKHGeqRWTWokJ3QtHn09//+3K lE6uCKxWrmQTuvbelEni+Fo0zHW1EQrmKm0b5uHV3iYry+4AtZFJv9cbJA2rFT2st9+zXldVzcUL zTeNUD6CWCGZB8/dujauRTPfg2ascAATVh+5NIXI+FKu8NeZGysEPqntK2uW5p0N02+27yypV8AX JYo1QAtNDhMHs/CqwAwekn8tv22RWLmrbDO9YiXERnYTCuTv8T8sYqXYecLjIP82ytdvT9jy9csT 1km7AXhwvylGFSN6HE6/Deem9lKQ9D6qaMpg6WvNPzqiNMSJ4cfw+JttC4YxI7xZE783wIxHqINd nAx8tPYucNo6es9EXgxBJYGOtJ+Nh9kxJ6N+fzzAeWQmTfOsBy/oSwsEe0RkU/rdTK/2yOgH+EXv WKlAl9cbr6vak0orv+RMgq9jgGlxvhlL55d+L0XICnDHyoBhQQOS4TERqvN+GR30U66t6NpV59bq jSG1I4xwLaXgqFOiK4JO+uBqgPnwFBiYHebClqd3C7vUCk8oF+4IGtaDs0BES0DgBHPztADyewGA +mZ6RwLvcCBigglCgSQPwnio7//IZ1r0R6NxERNaFKMsHx5ntMhGkNFBzGhe9PMsHRxlFKKxzr8S uiH4MKEWKKVIDdu+dj4mvzWJOV7UUkaBPqUFcmcZ6Nh92jArKLFezrXEE4gAzqBEFvUB+4cFQdxn oAplimj4oVLhTFSMg9bmemNrYSML3J2egRyCzHC5n/51IrshxU/o8SdvT8iXcztACF1bUdGS0CQI 3yX02QU4BbcQ+uSErC7DH4/uHH2ILsIvOK8lyXvnztjXs2vmEk9SllUZ48MhfUaOr6h4j/yvXxo4 6DZoWNe8a7tHl9wvJbcXAiFnV/LFCrnKfgnZiEeVxsN6gsAfvZRP8nnvhL9PbP+4cA71c9sQQn0M VSdW09inQSk3oV9ms/GgPx/NOrM0X3TyF+Nh53oxKDqLIsvz+Wx0Pc9efoVi0KR5ya0IvecfbQ8N g4/61qbmVjtd+S7XTRIb4MToO2GNrkMPnPYOjfSWQd2aZUVejPO8F8p28Bd8Cy1A6y0Mtb0tl/ZP Zt5uQ3UJLbsXdh6GDDTpsWp+YIKxQ0/8DwAAAP//AwBQSwMEFAAGAAgAAAAhAAW7I/jVAwAAIRAA ABUAAABwcHQvc2xpZGVzL3NsaWRlNy54bWzMV8GO2zYQvRfoPxA8VyvLkiVbWDtYO3FQIE0CeHMK cmApyhZKkSxJe+0G+++doaxN3PWiKVDAvtiSOBy+eW9Gmrl9tW8l2QnrGq2mNLkZUCIU11Wj1lP6 6X4ZjSlxnqmKSa3ElB6Eo69mP/90a0onKwK7lSvZlG68N2UcO74RLXM32ggFa7W2LfNwa9dxZdkD eG1lPBwM8rhljaLH/fZH9uu6brh4rfm2Fcp3TqyQzANyt2mM672ZH/FmrHDgJuw+gTSDyPhKVvjv zL0VAq/U7q01K/PRhuX3u4+WNBXwRYliLdBC4+PC0SzcKjCDi/gf29e9J1bua9vOblkJsZH9lAL5 B/yFTawUe09495B/e8o3H87Y8s2bM9ZxfwAgeDoUo+oieh7OsA/nvvFSkOQpqs6UwdZ3mv/hiNIQ J4bfhcff73pnGDO6NxviDwaY8ejqaNctBj56exc47YE+MZGNCsiSQMewyPMkO+VkPBxOclxHZpIk Swdwg1h6R3BG59mUfj/X1QEZ/R3+ER0rFeTl3dbruvGk1sqvOJOAdQJuej/fjKXzK3+QIqgC3LEy +LCQA5JhmQgVfVp1AP2MaytubBWtrd6aRmHtcEEaRxjhWkrBMV+JrqHMKqMb5R2i9gE7+IVrOALg 97BDJMjoy7JlT7JBzsz1nqQIBtK4k4WgK0iko5zfZ+W/qJCko3GSdjIkeT4a5MWpDqN0DDrknQ7Z aJilSX6iA0RjnX8rdEvwYkotEECRQ7Z753wnWW/SKbNspMTnLytIHiyD7HN/bpkVlFgvF1pi3aAD Z1DYZXP0/Z9lJO4voAqTC73h60WFTK4ZhwxZ6K1thO1Y4O78CmgIyYHb/ezzGXWDxC9k0f98PCFf Lw2AELqxoqYloXEoChenaZ0yXhT0lysAB98QxOaErK8Dj0c4Z18jV4EP6rck2eDSyj1ePHeuqrKs WDfO29DPxHXKORsVIr6OhNGqy2iGHeLnuqqrskyGX8qkGBRDeulEgveTPSm5/sN8HeR11XbxZAeW hEEZxZ61RoqoZynCBvgqqBJBRc3rqBI7GBWuApREUNBNXIOAFepXS61tlF687B4vW/dfzhz/vOsO TWg/A0JzDS0rNtY4mkEfOKVf5/NJPlyM59E8yZZR9npSRHfLfBQtR2mWLebju0X65hE6SZNkJbci vJ5/7cdmePhsVG0bbrXTtb/huo27mTc2+kHYMCzA2JsMjrPzjkHTO8mSIs/yyTC03QFa6J17sBBB P81yaX9j5sMudKYwpHthF+ERjCnrruP+zgRDhyn4bwAAAP//AwBQSwMEFAAGAAgAAAAhAN2GP3/5 AwAAVxEAABUAAABwcHQvc2xpZGVzL3NsaWRlNS54bWzMWE2P2zYQvRfofyB4jizLkvwhrB2snTgo kCYBvDkFObAUtRZKkSzJ9doN9r93hrKc3awXTYEC1sWW+DF8896InOHV630jyU5YV2s1p8lgSIlQ XJe1up3TzzfraEqJ80yVTGol5vQgHH29+PWXK1M4WRKYrVzB5nTrvSni2PGtaJgbaCMU9FXaNszD q72NS8vuwWoj49FwOI4bVit6nG9/Zr6uqpqLN5rfNUL51ogVknlA7ra1cZ018zPWjBUOzITZTyAt wDO+kSX+O3NjhcAntXtnzcZ8sqH7w+6TJXUJfFGiWAO00PjYcRwWXhUMg4f4h+m3nSVW7CvbLK5Y Ab6R/ZwC+Qf8hUmsEHtPeNvIv7fy7cczY/n27ZnRcbcAIDgtil61Hj13Z9S5c1N7KUhy8qodymDq e83/dERp8BPdb93jH3adMfQZzZst8QcDzHg0dRzXdgY+uvEucNoBPTGR5ROIkkDHKJ9Oxz9wMh2N ZmPsR2aSJEuH8IJYOkOwRmvZFH6/1OUBGf0D/hEdKxTE5fWd11XtSaWV33AmAesMzHR2vg+Wzm/8 QYqgCnDHimDDQgxIhp+JUNHnDS7PCr/g2oqBLSOhSqNr5UntCCNcSyk4hirRFYHY03eWC4eAfYAN JuEZrAPyDnFwAsl8WbHspBiEy1LvSYo4IIJbRQiaghg6Kvk4IP9FgGQ0y4YzCAgkOEuyPMtbD7uw zNMpSDBuJciHyXiSz55IAN5Y598J3RB8mFMLBFAkie3eO9+q1Q1pRVnXUmL7y+KRe8sg8Nxfd8wK SqyXKy3xk0EDzqCm6/po+z8rSNzf4CzGFVrDnUWFIK4Yh+BYgWS1sC0L3J3vAQ0hLnC6X3w5o26Q +IUA+p+XJ98uvD4hhG6tqGhBaGzFbe28DfttXKWcs3wiYvqqBxjhEEGITsiqF3i4VoiHa4Yn6peq rMqiSEZfi2QynIxoHxjzLcCnO10/yENo2bAPcSUMsiT2rDFSnM6DCBOGXlAlgoqaV1EpdpBa9QKU RFCwBfdBwBL1q6TWNkov/tk9XJyRPpwnTPGttqjLS9vjxWl6fOq1HxYcfm2+l9BXhPRm/9Y1H9iB F40RcC7fQT7VB+7qkC8gtroauF5AgrS1IAnWBpfW7uGyAL6eWf55vRLS965whnIBkn0sSbBwgAx6 Tr8tl7PxaDVdRsskW0fZm9kkul6P82idp1m2Wk6vV+nbB8jBTZIV3IqQM/7W3TVA47P6vqm51U5X fsB1E7cXBbHR98KGEgzuCpLh8cJhx6BcSNJ0Mk7SWdoWewFbKDs6tOBCdwfApf2dmY+7kNTD1YYX dhWaDFxmtMXKoyHoO9wd/AMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6 EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3 OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaL KU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxj Ip9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLx vgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHOE j8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LIC Qd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJT ryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7E sG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePs MG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPc KcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1Qo Hp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3 AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxzhI/BCsIw EETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8 r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2 pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H 1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L 83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA CAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3 LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1r GsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZ hki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3Km VLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzhI/BCsIwEETvgv8Q 9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62 IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277 AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRk o+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLB RRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn 6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5y ZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvg NdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1I E+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoa pJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEANM25zh8BAADHBwAALAAAAHBwdC9z bGlkZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzxNXdasMgGAbg88HuQb7zxZi2 6Q81PRmDwo5GdwESv/ywRIPasdz9pDBIYHMUAp4IGnx98h7o8fTVd+QTjW214sCSFAiqUstW1Rze Ly9POyDWCSVFpxVyGNHCqXh8OL5hJ5zfZJt2sMSnKMuhcW44UGrLBnthEz2g8l8qbXrh/NTUdBDl h6iRZmmaUzPNgGKWSc6SgzlLxoBcxsEf/X+4rqq2xGddXntU7pczqO1aia9i1FfnY4Wp0XFIkum6 nU4YS/wPAP3Dli1pc740nKluK/Q2hh1LMu6uKNTQogXdK8tCslXMzlYh2TqmbB2SbWLKNiFZHlOW h2TbmLJtSOZv9ngX6y4k28eU7UMy5t/HeKWx9MdGZ89v8Q0AAP//AwBQSwMEFAAGAAgAAAAhAKpQ 3lqUBAAAbxAAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzMWFlu40YQ/Q+Q OxDMN4f7IsLWwNqCAB7biDwHaJMti5jmkmZLIyUYYK6VHGdOkqoiW5Q9TmI4+tCPzKW6+OpVVfcr X7zflcLYctkWdXVpuu8c0+BVVudF9XhpfrxfWIlptIpVORN1xS/NPW/N9+Mff7ho0lbk12xfb5QB Pqo2ZZfmWqkmte02W/OSte/qhlfwblXLkim4lY92Ltln8F0K23OcyC5ZUZn9evma9fVqVWR8Vmeb kleqcyK5YArwt+uiabW35jXeGslbcEOrn0JS+waiVYUS3DTITG7hgWuOIfJsKXKjYiU8uEcLYymK nNOrtrmXnKNRtf1ZNsvmTtKKm+2dNIocPfQrTbt/0ZvRbQVmcGE/W/6oPbF0t5Ll+IKlQISxuzQh X3v8hUUs5TtlZN3DbHiarW9fsM3W8xesbf0BQHD4KKS66SL6PhxPh9MR4R6i6kwZLL2us0+tUdUQ J4bfhZfdbLUzjBndN2ujYz1Tkrz1pt17okQvaYlWjfVARpSEidMx4rm+E3jhU17iOPYCNEB23CB2 nM7iOOrOdZOq3aTO98jqA/ylrLBUtGqp9oIT28AJSwE5/EBuBcOO4ZX1cdl9VI2nosg+Gao2eF4o 4wNrFZeGooJp0csFfFdBsskL/IJDiFJ/GC472v+ZfF+Tv9w8dH49/DYUqGb3Tfy3m4eOfyhYqCad stfnwfVjN+oT4SdJBK3+NBERZIEyRYmIQw+tsTB0Sin4riw0Hy8mAtkXW+FCPRglk9fUEEWVQ1PT JROPsK1BQUFzgoPNDWxilLycr35F/0BQDc27KISgG9y5+FRIY8sE9P8OGx6yVFSqexKHzgEqbXNo TMCP/EAY2j9c9vjQD1x6A9QgjJEZ4/zwIsgerz/gHbkBdc/54UWQPd5gwHsow/MDjCh7wOER4MRL qC3ODzCi7AFHA2DPS6Bzz7KEEWUPOD4CHAf+mfYcouwBJwNgRHumTYcoe8CjI8BRGNPef341jChp q9bHOKJ/2ykOR+QpD/JAH+QzprhxJ1jG17XIQS74pzjQcwUi/ncQxEys4LihQ707b1FnEil4sSR+ UHaQ3BmkyItH76CBVqCGUdr+4Tqz+fwqcq0kdF0LBNjUSoLQsyI/mMTwIolj/4vZq7wcQlVFyRfF 40by240yMR1qHNmh7caDNgLv+IJX+R2TDA7t51LrLcop1IQv6hpV2THlwSkoX4HkIM5/2zAJX9C0 /4eYIvX2r4pnoP20jESaEZpljJtN+fCMFxLT/1tbihxcv0gNaVeS+aeryMl8Oouj+MoaubOJNVoE gTXyZ47lTL3ZZO7OEj+ODxXZ4hRXAbquEL99/fOnb1//OkElkprVcyEMadctyP6GxrWNLKBxJpNR 5E2TiTVxg4UVzEaxdbWIQmsR+kEwnSRXU3/+BWA1bpBmktO8+kvez83w8LtZtywyWbf1Sr3L6tLu hma7qT9z2dSgZWFudp1++Cah60GfJsEoCBKS4YSNphGNFkLAqZeGCyE/sOZ2C3spS2HMh+oGDQyP GhjsoTzRdDDB2PU/CsZ/AwAA//8DAFBLAwQUAAYACAAAACEAtKtbX9kHAAAHLgAAIQAAAHBwdC9z bGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxaXW7jNhB+L9A7COpjobX1LxnrFLEdtwtkd4Mm PQAt0bEaWlIpOk1aFNg79Aa9Rdu3HmVP0hn+yHJip0k3KeIiQOBQJDUk5/tmODP266+ulsy6pLwp qnJou6/6tkXLrMqL8nxof3c2dRLbagQpc8Kqkg7ta9rYXx18/tnretCw/C1pBOUWyCibARnaCyHq Qa/XZAu6JM2rqqYljM0rviQCHvl5L+fkR5C9ZD2v3496S1KUtn6f3+f9aj4vMjqpstWSlkIJ4ZQR AftvFkXdGGn1faTVnDYgRr69saUDOF92ynL8PztXn9/SuVXkV6Clft+1D16TgTwnHTNuXRI2tGfn rt07eN3DV2CybuHLTX3GKcVWefk1r0/rE44P2bvLEw4yQaRtlWQJ+kUBckBPk48lTFOCN14/N5LI 4GrOl7gjUI8FOwQUr/ETXiIDeiWsTHVm695s8X7L3GxxtGV2zywAR2sXxVOpE90+jmeOc1YIRq0T RjK6qFgOXJEqkidUr4EW6+Mqu2issoIzoyrUUUE5RjCeH5eqF5a4rkFLAsXqeWoQdla28xupX7Pp VitBGAPppGq8OIj8ZFM/ieelEY6jllw38PvwgHtZC6p5I76m1dLCxtDmNBOSCOTyuBFqqpki0Vcb qQfialTl1wjGDP4D5mBx8P6i4j/ZFntTNkM7dYMA1hbyQe7Utnh3ZLYxIti4AsrBG6TMQM7QzgSX eynB2g5XopoXekdqSVycNeJUXDMqaQHgkQGoFT5gQ4ygwdPS+e5UaUUcjFmRXViismheCEubutQ8 eASQgooRUj0gBdogEFAwR4Wm4sdulvgtS5CiXZJ4uIdPJQme29YWK3FEiiCRHsgVF0iBvJFaM8a0 QZYg9MI08uUiz5osiPaD+AGGZLFLSTR5/IfzBRUm6dJs4YskDXyYVaTt383KU5pVZW4xeknZPSRK Jt0t8WxR8PsLlCjfLXBarbhY3HuLgWLWXaqdFvM7BD7M6gJjdRMiNl2zPNqnWl0uIGD4CXwbYXNt fRIDaXT/wvoiP4S/G9bnub7fumo/Cl0vfP7Gt+GppTUZfyx98yVz0Q4IO4dAjNnYl9P5t9CF6nTR A2FfU7EinxaMyQcMtNYBiLhScYkoSqFCkjhcX2JttCK9dUcO+G61khwAc8eNqLa+MHAteV/MWS7j lZ/d/uTo6DBynSR0XcfvB2MnATfoRH4wimEgiWP/F7jO5HWdA9NEsaTT4nzF6fuVujTFQdQLe268 tmKQjivRMj8hnODRb1xL/+aWCQ3fp1WFwWr3npGm96mMn8PFKzH6YUU4rKBZr66Dh9w5vusFJkDZ TvskDf/XtDcxzPMj/uNyMjKcPAVjpta71XJ2g5nSn30qMyFDA9HbyCmJ/yCXHIWhfzc5/+8+WYXX z4+arU8eHY0ncRQfOqk7GTnpNAic1J/0nf7Ym4yO3Enix3HrkxtkXgnsQI8rDj5++P2Ljx/+eARf DKxap7sQ/UFmhLE8xoErXgztn0ejNPLGycgZucHUCSZp7BxOo9CZhn4QjEfJ4dg/+gW2VbvBIONU Judvcl0kgM5bif2yyHjVVHPxKquWPVUh6NXVj5TXFdyEUCRw+7rSIPP0ME3TGEJ6YwSwNZkUmM3C CUzunzH+ltQWZPZwJwvI0uGKHdr5BbRm5x72QaorrqCVX0CLZBmUE2CGbpgeGFc97Rzf9EASpIbg XLphekLTA1eYGopMDziQBSvKC9AF/rOtecW+UR2mhQERQMHyY3JdrcSbXAPR6ZFXuecGcZD4UZBC wjnAYgR/k+ssfddciMfWc3WytnMu6KqVq0PMnXNBP+1cfTnvnAuaa+dqd7lzLgS97dzolmY29BCC ttu58T/MBRzaubKcsKHxTblxZ276D3Kh6tbKdWXwe4fgDeBM+aSjCg28uJLJf4O0kGm8fETz1yGf jj3xErbAzZ2R2SlEnqZqwoWqN1ByXI44MA9wxbpbqR+BEgsoIkBx72RVZlDd0DWyOhthLQzrPNlJ puNSU1iBPj06W72DAqMMizsuFmoiIPeCcixO3jcEBiEQKHYCXDghblRGo3MoRQ3tL5ffO0wgCBBu khsDlKiBrLkxkDU4sCtc3tQqFAGh/nBLxUvCj4e2H3gpHqwowQeDqhzTYaL/p9Y/qFJVNFBRHQym FWQOGLQrNR3ygjCljNlqvCDcyuBjaH/88Jvq7UClooOngKrcBVXp7ICqdO6ESjLew2xLwREDHOjS Wji8JITMCbyuTsaePRy/3oLDS57Kch4RDsRAOyB/DYepvXbw8BKZ9+wNHrfNw3syT/aIeCAIGo+g g4cugO4xHlvsAx3gk9wsj4gHgqDxCNd4eP0wlmxa+6v9so+//rztrvYBDsRAwxF14AjdQHqnfYVj 222OAcKzNw8EQeMRd/BIY1defi943CcQfkR3hSBoPJI1Hiq23Qiv9std7a19IAgaj7SDR5JEspL3 Yh//sX0gCLDkRmpYDyqxoLxNFCGjOlGo6dzq9lcg6ykmcVdpzJMkLJ0MT3nVvczwTBHj8ROIfdPP 9pRL/vrkhT9gTztSID/Gn4E8RUVg3wi0PSdxEy+RQdeLhe3IEmTM88IgMLEdYXscqBLiC4N2xNEQ tMm0/0VBOwLbKIxfnLQsbreRZje4hMBz/R0Qfk1rfsB98DcAAAD//wMAUEsDBBQABgAIAAAAIQAM r3EuOAMAAEsIAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1srFbhbtowEP4/ ae9gZb/TEBJIiApVQ2Ca1JZqtA/gOqZEdWzPNgw2VeprbY/TJ9nZIW3XdlLV8SeE893nu+8+7jg8 2tQMranSleBDLzzoeIhyIsqKXw+9y4upn3pIG8xLzASnQ29LtXc0+vjhUGaalSd4K1YGAQbXGR56 S2NkFgSaLGmN9YGQlMPZQqgaG/iqroNS4e+AXbOg2+n0gxpX3NvFq7fEi8WiIrQQZFVTbhoQRRk2 kL9eVlK3aPItaFJRDTAu+u+UzFZCtaYyjM4423rIuao1GENvBNWTOSsRxzUYLqwXcm72RMsLRal9 4+vPSs7luXIBZ+tzharSAuwCvWB3sHNzXzm4wUvwLPy6RcLZZqHq0SHOgAu0GXrQsq19QhDO6MYg 0hjJo5UsZ6/4kuXkFe+gvQAyeLjUVtVU9LKcbltOw0P4UFXjiiH0RJAbjbiAOm35TXnkbN2C2Zot vFyiJ8Tv/JpDx0frr4FTR5bZ5KLc2sKv4NMZcca0mZsto44QSBtnAA4PoJ9hq2vK/cu5RceZGY1Z RW6QEYiWlUGnWBuqkGs8CB9QDoEQA/1wKPAEQMilvRheG2b+zU/U8lNgQ9E5w4QuBSvhlq7NAaTU EvEuqkoDv9AfoHbMFh7oC5ofOjE4xiyv/0XdAmRuRfsz7BSTyXE/9NNeGPpRJx77adzr+v0ozhM4 SJMkuvV2/SuhVFPVdFpdrxSdrYzXkN0PekGYPFIK6PaA8vIcK/z1ZYfeQ3jcEj4VwjbzKeXRPihf GNVw/m2FFdzQ0t4qew+K3S8jvZaROatKis5W9dUzXuJ98AIbAaBfpcZJfc+KzCfjIuknx/4gLHJ/ MI1jfxAVHb8z7hb5JCzSKEkeFKlt5Ryya4R4f/fr0/3d7z0o0U2AduLD+D3RMC2kG8QrVcEPJ88H /e44zf08jKd+XAwS/3ja7/nTXhTH4zw9HkeTW0hLhnFGFHXL6Eu5W4pgfLHI6oooocXCHBBRB81G DKT4TpUUlVuKYWe3WdeYwTgI4yRNorRnewzpQpLtp0sWTHabuVHE1CmWszVMDZzBCgdxj51JwtJu osmjiy29/RMw+gMAAP//AwBQSwMEFAAGAAgAAAAhAHHBPQ3DBQAA9hoAACEAAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0NS54bWzsWd1uo0YUvq/Ud0D0mpjh31acVWzHVaVsEjXeB5jAOKYL DB3GTrLVSvta7ePsk/ScgbGJ/9ZxIvWiuXEIfHycnzkfhzOnHx7zzFgwUaW86JvkxDYNVsQ8SYv7 vvlpMrYi06gkLRKa8YL1zSdWmR/Ofv7ptOxVWXJJn/hcGsBRVD3aN2dSlr1Op4pnLKfVCS9ZAdem XORUwr/ivpMI+gDcedZxbDvo5DQtzOZ+ccj9fDpNYzbi8TxnhaxJBMuoBPurWVpWmq08hK0UrAIa dfdzk+RTCd7KBz55nDzw67s/TEOBxQJOE/MM/I9vs8QoaA4nhjwvqUgrXqgrVTkRjCGmWPwqytvy RqgbrhY3wkgTJGhuNDvNhQam/i0ABgedtdvvNRPtPU5FfnZKexAN47FvQtKe8Bduoj32KI24Phmv zsaz6y3YeHaxBd3RDwALlg+FfJe1R5vuONqdSSozZpClVzWUwq2XPP5cGQUHP9H92r34aqHJ0Gek L2dGE3qkanD1RRUPja8gpipY8nHAkyd0/A7+qpO0l1XyVj5lkAI4XmREJYD2Ejb9vQ5t6zR424aD k7QHpsAPJCujWAessD7doi20J8+GWRp/NiQ3WJJK4yOtJBOGVI5X+MxTIJSQPcUCv0AIlmsz4bCO 4+5oustoYipvMhqzGc8SeIqDNsDC02E7KrAYJhNWISwRnYcd8UV/11aa54dQt2q5Ed/1CXHrsOhF 59meTSLQDFx6gdsNA2UzhKEmUu7XmdYR0YkzaBHPOIjAXU3ZTkqTQyOn4lIt97RIoG7xEI28m1+B OKn81Ck2qi990/HQ0jvtZivl6tCBRdEQaq8OYrU3WZEK7QAz3RVrl3jKgkNYSbTJilQNq7diJW5I AgQfRKuQz0OAXA2t36KNnEjZcCwtcjW0wYrWcSIw4RXWIldDG7ZoQ89V6/BYa5GroY1WtMh5eMq2 xBa5Gtpuizbww1elDLmUorRrQgkVPgRW3VL81dNfJFxYuUq3qlcLl6eFa8gLCeX5TLuUUByvXVjQ M5pNG+WqVQVfkCoyeNB+M2AOdiuXQ0IvCv09yuV2fQL1gIhDpEspTzs3G++clSDVlC0AHGr9aIsX Vs0SqwGA1arQwirxWGI1ALC61NtYXIhLrAYAVtfvTqwGAFYX5U6sBgBWV9pOrAYAVpfPTqwGALau Cf1OV/FVurj07T8rGvXKhx9dmuotu7+nuGUxLxIjYwuWbSnDdUa1+vczTmapOJyweYvvU48xnws5 O9hEr66uvYzpdA/hy3omX0vPZL1nUoYcrzt1M1r3TKhBf86pgIavkSEVN7D0BTIUeL7tgLnQH+3q oEgI4vTeQfXN9w4Kutj3Dqpvuv+TDirQMratg1INy/FKtqleShqPVq9dXdRKvd67KIz5867kvYta zUz2fnqs9zzvXdT2cdT4DbuoUMvPiEr27OstwHbueO2pu6hEwiz5+XccqT9GdnZQ6qnrkyI4uZrZ qX/Ut/AUxrE4XP2L2KOLi/OAWBEMqCzX9oZW5PmOFbjeIIQLURi6X81mzpiAqzLN2Ti9nwt2PZcm ssuzoON3SLhqxoEdL7AiuaGCwhhxfTZ4zKgPBmX1AHnMOY4R28O+8C1CPpXQqm4qP/nB5O8lYX/b iHR1RG6zNGHG1Ty/W4uL+ip/7VKEvQug3hqaH4wWXhKa5YocXAxHYRCeW10yGljdsedZXXdkW/bQ GQ0uyChyw3C5Iiv0vADr6oX4/dvfv3z/9s8brEQ1fNU7EyC+lxXMqUu1YTAXKRTOYNANnGE0sAbE G1veqBta5+PAt8a+63nDQXQ+dC++glkl8XqxYGrb5Lek2b6BkxtbLnkaC17xqTyJed6p9246JX9g ouSp2r4hdrMHtKAwxXLs0HU9GJbpDyuwUo3PtbXgAm67KC3KxEdaXi/UJybsNkH9DNWpEvaXIEsI XUHQd71fdfYvAAAA//8DAFBLAwQUAAYACAAAACEA7GAGSm0EAABBEQAAIQAAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQ0LnhtbOxY227jNhB9L9B/INRnRZJ1tRB7Ed+KAtkkqL0fwEhUrK4k qiTt2FsssL/Vfs5+SYeU6DiO48s2LwXyIsvk4eHM4XA05OWHVVmgJWE8p1XPcC5sA5EqoWlePfSM T7OJGRmIC1yluKAV6Rlrwo0P/Z9/uqxjXqTXeE0XAgFHxWPcM+ZC1LFl8WROSswvaE0q6MsoK7GA v+zBShl+BO6ysDq2HVglziujHc9OGU+zLE/IiCaLklSiIWGkwALs5/O85pqtPoWtZoQDjRr93CSx rsFb8Uhv7/8wkMKxJbQ4Rh9cT6ZFiipcQsPskaIhrQTQqC5ezxghElQtf2X1tL5jasTN8o6hPJUM 7UjDajtamPpbAQxerJ3hD5oJx6uMlf1LHIMSaNUzYMHW8gmDcExWAiVNY/LUmsxv92CT+XgP2tIT gAWbSWGt68ajl+50tDuzXBQEORuvGiiGodc0+cxRRcFP6X7jXnKz1GTSZ0lfz1Eru6RqcU2n0kPj OWiqxBKrAU3X0vF7+FWNOC64mIp1QZQgYDaOgRweIH+BZVSTyvw0lew4Fv1hkSefkaCIpLlAHzEX hCGhXOGS5RIEEbAeigWeQAi26InhtVHmdX1crU8bJOiuwAmZ0yKFiTrSDAgnrcWZavEvEOS4yAwI LFh1Le0rkkmHd4LH80PYhiqCnMC25bvSRceRZ7sRtBtIRpPnd/xu4ErEdpTI1ZBOaE32Loacu1gW jsLiOCXZ77Ae0v5O1EwKlFsAeO3swXrbWA0ArLsHa29jNQCw3kus88wGDQCsfwyrAYANjmE1ALDh MawGADY6htUAwHaPYRuA1LrdJXJh1CaBkQgYNqnk/E0jg0btGb5n0+zOomL18NackoRWKSrIkhQn MKq9dJhxNs/Z6YQq0g8TTuiCifnJJnrN7jok7STPDhCel3q8Q6lHefdmqUeJr5K0TAbqZapiUSZI 2fQy9QRe9J57IGm/5574Pffspsf/fe7xde4ZYUGe1TwqCf544mkqxFTAsWSn+lG1y+s5SFVaB4sU Vfqoj2EG5b2s1f9y7NF4fBU4ZuQ7juna3tCMoA4yA9cbhNARhaH71WjL1hRcFXlJJvnDgpHbhTwQ yOoxsHzLCZ8+YcAuO0iV3mGGZSG0U5j+SJ0ZaMEnlMoadrvM9P9bmdlIngnWaP7nAjOYQRedR6rO c2R/W0VCrci0yFOCbhbl/Y4uwVvoAsdgoN4rzZGv4jnSbCJyMB6OwiC8MrvOaGB2J55ndt2RbdrD zmgwdkaRG4abiOTS8wqsawLx+7e/f/n+7Z83iETYZk8HXSj8rjkckmp1/lywHDbOYNANOsNoYA4c b2J6o25oXk0C35z4rucNB9HV0B1/BbNqx4sTRtQJ/Le0vQmAxhen9zJPGOU0ExcJLa3mGsCq6SNh Nc3VTYBjt9cJSwxlrOM4nu9GfqDjE6xUlYm2FlyQx3h1/irYR1zfLlWdAhcXEN1D1VTDVQWskoQ+ QaTv+uqj/y8AAAD//wMAUEsDBBQABgAIAAAAIQBhXZiN2QQAAN8QAAAhAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDMueG1szFjbbuM2EH0v0H8Q1GdFV0uyEXsR23G7QDYJ6uwHMBIdC0td StFeu8UC+1vt5+yX9Awl2U42Rb1JEOTFlsjh8MyZIWdGp+82uTDWXNZZWQxN98QxDV4kZZoVd0Pz 483Mik2jVqxImSgLPjS3vDbfjX7+6bQa1CK9YNtypQzoKOoBG5pLpaqBbdfJkuesPikrXmBuUcqc KbzKOzuV7DN058L2HCe0c5YVZrteHrO+XCyyhE/LZJXzQjVKJBdMAX+9zKq601Ydo62SvIYavfo+ JLWtYG3Nk984S01DC8o1hlxzBNuTuUiNguUYmPOENjdIkEs9W1c3knOSK9a/ympeXUu96HJ9LY0s JSXtYtNuJ1ox/VpADA/2g+V3nSY22CxkPjplA7BhbIYmnLalXyxiA75RRtIMJvvRZHn1iGyyPH9E 2u42AILdpvB31Vj0vTleZ85NpgQ33J1VjSjD0osy+VQbRQk7yfzGvORy3Skjm0l9tTQa6hWpauWa Sc1HJ19rTjugOyYiz/NdX9MRBE7Ydx6QEkWRF2DQIGpcP/ScqKc36TRhk0Z1NVCbcZluidJb/MNz rEiWJaJU0Qo2ELWaq62An/G8Fi4QGUzc4RgJRAEbpHzxO4bqP4cmtsSet9rxCQMDTIh223Yl3H1f I8hmA1CCHygRjM4jL6yP82ZzNZqILPlkqNLgaaaMD6xWXBqaNRxYwCKFSquFFjxDIYzrjNJ2EuH/ 7VXQ2ET4DYXUtWAJX5YCMW54hAGHoHPfkxxMpJo4DQjVLh6e5Gev74QRfH4v+O/7uec4bhy1hDdn 5xg/3zY6H/NzzuSFPndZkeICoUdy1e3qErekRnLgfdx0zXRdiiydZUKQrL4k+URIY80EgmpDNwtc lhWqGYkAW4cvnLcT1q480IO5Zic9sQsmHZEeRWSDNOhFQAG6j4Drxq8IlzCS2UDu7+H2XZzeY+GG rwiXMLZwgz1c149cQnEcvWSZDoBXiAYC2eLtHeCNvZic/PbwEsgWb7jH63kx6H2LeAlkizc6wBsF /vHH7TXjgUC2eOM9XgJ7/Hl7TbwEssXbP8Ab9qK3ed4IZHMTHxQHOpUTelxyuzJNm/VDqZ2ysM7s 9bNTe9Cl9ilT/F5q13n0uak9VWgaUPYsmVh0Kb7JZFTSaoboYa7JagouXVB0xUlXcelE2qVf/aKp XKD2pir6L9eZnp+fha4V91zX8p1gYsVBz7NCPxhHmIijyP9itgVlClNVlvNZdreS/GqlTAosNQrt nu1Ge0qhnSZ4kV4zyaiCe1B8PaWW6nWEz8qS6rTDaip4iWpqoWTD+R8rJrFDR/v/lFY/QvvLMhJ2 jMxRE3HjcpXfPuBFF+bPDUU0qVD9KDW6ikUd+JIROT6fTKMwOrP67nRs9WdBYPX9qWM5E286Pnen sR9Fu4isyfIC6JpA/Pb171++ff3nBSJRF7ddC4pr46JGI1DpznAlMxyc8bgfepN4bI3dYGYF035k nc3CnjXr+UEwGcdnE//8C2BVbjBIJNf98fu07dMx+F1vnWeJLOtyoU6SMrebJt2uys9cViUKWvTp rtM2+7ra9cLAQc0UBp0TgFL3Jx1amEA9tm4zhPzAqqu1vjHxWQHRjaoZQxU+JCCASXQvQrZ3HyZG /wIAAP//AwBQSwMEFAAGAAgAAAAhAGguXbaoAwAAzAoAACEAAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0Mi54bWysVl1u2zgQfl+gdyC0z4okS7ZsIXYRSfZigTQJ6vQAjERFbCmRS9Ku3aJA r9U9Tk+yQ0pK2iYbOKlf9EPOfJz5+HE4p693DUNbIhXl7dwJTnwHkbbgJW1v586765U7dZDSuC0x 4y2ZO3uinNeLV3+cikSx8hzv+UYjwGhVgudOrbVIPE8VNWmwOuGCtDBXcdlgDb/y1isl/gjYDfNG vj/xGkxbp/eXh/jzqqIFyXmxaUirOxBJGNYQv6qpUAOaOARNSKIAxnr/HJLeC8iW37x3kDWSW/gN nAXkXaxZiVrcwMA11YwgYAdlvNWAZA2UuJaEGNN2+5cUa3Elrd/F9koiWhqc3t/x+onezP62YAYf 3i/utwMSTnaVbBanOAEy0G7uwJ7tzROccEJ2GhXdYHE/WtSXj9gW9fIRa29YACK4WxS2W3QZPUxn NKTT0RHcZdWZYnA958UHhVoOeZr0u/SKi+0AZnI28KJGHfPaMNvbdZOWj8FeAaeWLL1Lebk3id/A 2w7ihCm91ntGLCEQNk4AHB5AP8NG2KR1360NOk70ImO0+IA0R6SkGr3BShOJ7PqgfEA5BUI07IdF gScAQizDwvDZMfP//IQDP71I0BXDBak5K2GhkQkDRDVw8Uy2aAl7PRB6BKKAV8S27E5OzyfOCNDy ph4hzrIHj2EVG/nT27MmBYcDxsiWsAMQLZ9PI17XVB4OGHY6eYqIFd9IXR8cYnQAIq2eAHye/KJB fjnW5Cft2dRerr3upJYabohPUG0xqxwob0aPthbZA2uOtf146cmtoNiamvk58PPl8mwSuNNxELih H2XuNBqP3EkYpTFMTOM4/OL05aOEVDVtyIrebiS53JjCbE7xxBt7QXwvI0A3E6Qtr7DEbx8WiJec 9/FA+IpzU0t+PO5273+X8krLjvN/NljCCgPtR6wDx2VkMjCyZrQk6GLT3PzCy/j3ymAnRehIAPpR amxZOLIi02WWx5P4zJ0FeerOVlHkzsLcd/1slKfLIJ+GcXynSGUybyG6Tojfv3778/vXf4+gREjq vuGA4nuu4LIStg/YSAoHJ01nk1E2Td00iFZulM9i92w1GburcRhFWTo9y8LlFwhLBFFSSGKbob/L vimDwQeNVEMLyRWv9EnBG6/ryDzBPxIpOLVNWeD3nd0Ww1USBHEQhLOpPzObDPFClMPbRgtDpqmy 9yCTb7C43ELZwAn0kKDuzA4J6Bo77+LexOQ+dKGL/wAAAP//AwBQSwMEFAAGAAgAAAAhAILh6o0y BQAA6hEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWzEWFtu4zYU/S/QPRDq tyJRbxuxB/GrKJBJgtqzAFqiY3UkUaVoj91igNlWu5xZSS8p0bEdTywnAfrjKNTh0X0ePq4/bPIM rSmvUlb0DHxlG4gWMUvS4rFnfJpNzMhAlSBFQjJW0J6xpZXxof/zT9dlt8qSW7JlK4GAo6i6pGcs hSi7llXFS5qT6oqVtIB3C8ZzIuBf/mglnHwB7jyzHNsOrJykhdHM523ms8UijemIxaucFqIm4TQj AuyvlmlZabayDVvJaQU0avahSWJbgrds/sdsYyAF42sYwEYfPI+nWYIKksPAkBUCGNCXVCzRkJTS DoWpyhmnVKKL9a+8nJYPXE29Wz9wlCaSqqEwrOZFA1P/FgCDB+to+qNmIt3Nguf9a9KFiKBNz4DE beUvTCJduhEorgfjp9F4eX8CGy/HJ9CW/gBYsPso5LysPXrujqPdmaUiowjvvKqhBKbesvhzhQoG fkr3a/fiu7Umkz5L+nKJ6vALSdXg6pcqHhpfqZhqQ3eR8PwQakuFwwld2z+KiWvbkYtdA8nIYBw4 DWLf45q57IrNgCVbGdE5/IXEkSJeMijUeR3nrBJTsc0gzaSbrTMMBiGSPUInZVAEpJvQxe8wVP3V M8AksGmuHd/hIcfwvMcDESZdiAP8wNSMyEakhflpWn9S9IdZGn9GgiGapAJ9JJWgHKlQQaeCMZJQ KFpggWcghLBpV+CxTuKPUwmxOSzuh4zEdMmyBD7kSDOgBXTaLkxsmkBZ6ty3z6nrh77Mk6zxU0n1 McaAqJPqR76LIcOywHR1KLfr8tKR0ElVHbOfgSaTRwl0ZVHVlHsAeHSaMtxPdrSP1QDAuiew3j5W AwDrncDKItrZoAGA9c9hNQCwwTmsBgA2PIfVAMBG57AaANjOOWwNONUaMBMBw07rLm8VqY6qU6oT raL6BX70V1StvtyQUxqzIkEZXdOsBaPqoJcZZ8uUtydUlf4y4YStOCxQbU30ZJGdYUwXLxBeJjie FpyZTM2+2ijXXq829TIitRt2MSDCS5ItDFh9QYNUFsDM9hq0t65gz/Vx3YpPi+3BwuIFHWwHb9Yg lBN+qxb3tEhgnyEfZWbmqzvYjqkk7ckOPpASuRpJLDSLVKCGSnvRiu9A8o5krOHrYE9+FbXiO5Cv I6lr+LAb4qAtYecFOdR8kRNJNW5l4AHfkWQ2fI4TgXmv4TuSVc0Xempludy+I+lt+CRZ64Qc+Hsk z5ov8MPX5eN/k/DLxMfX4jMigh6Ij1LBt4pPIp5JD67X8B9qD7T1037t5C5FNb7aKC7gJCJPE39j ezQe3wTYjGAvZLq2NzQjz3fMwPUGIbyIwtD9ajQb6wRcFWlOJ+njitP7lVCiIvqB5Vs4fFrDgF0q CC2SB8KJ3Moe7Udfs70MdMAnjMmt677e+3LheWvIF4LXMf9zRTh8oVF8fGbbeUnY3zcioY7INEsT iu5W+fwoLsF7xAUO7EB9MjRnVsNLQrOryMF4OAqD8Mbs4NHA7Ew8z+y4I9u0h85oMMajyA3DXUVW 0vMCrJP1Jvrfv/3zy/dv/75DJaqNvz6Kw/bitoKzUalOyCueQuMMBp3AGUYDc4C9iemNOqF5Mwl8 c+K7njccRDdDd/wVzCqx1405VXcFvyXNnQUMPrtnyNOYs4otxFXMcqu+sLBK9oXykqXqzgLbzcXH msA+1ong6ILtjqp9MBeMVCc2bSwMyQsH1RcZ/0jK+7Va1+GGBYp7qIZKuFOBJEnoE0S6ru9o+v8B AAD//wMAUEsDBBQABgAIAAAAIQCeLNnu/wIAACIHAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDcueG1srFXhbtowEP4/ae8QZb/TJCQQiICKEJgmdS0a7QO4jgNRHduzDYVOlfpa2+P0 SXZ2SLu1nVRp/AHnfHf+vu/O5+HprqbOlkhVcTZyw5PAdQjDvKjYauReXc69vusojViBKGdk5O6J ck/HHz8MRapocYb2fKMdyMFUikbuWmuR+r7Ca1IjdcIFYbBXclkjDZ9y5RcS3ULumvqdIOj5NaqY e4iX74nnZVlhknO8qQnTTRJJKNKAX60rodps4j3ZhCQK0tjovyHpvQC21xSxG9exbnILhtAdA3O8 pIXDUA2GzHoYoxKXkhCzYtvPUizFQlrf8+1COlVhYg8xrn/YOLjZTwZusPBfhK/aTCjdlbIeD1EK Eji7kQuV2ptfCEIp2WkHN0b8bMXrizd88Xr2hrffHgAIng41rBpGr+l0Wjo50sRZUITJmtOCSCd8 IthEIchyxvGNchgHykaJhik+37Z5DX1zklg7jfSFhsa7gyIiWrqgH5ALLVmrkHG2izZegdxWR73L eLE3mlzDvzWilCq91HtKrFbACKUlVNAU5UcY5LPZpBd6/W4YelEQT71+3O14vSjOEtjoJ0l077ag gKquajKvVhtJLjYa2gGletzzu36YDEFDDbhsdlsVViyQRN+gAaBN4EIR5l0tLXmUAgxg0MKFZSP1 vwWPWsHnnGuQ+U/JO8eQvNSy0fz7Bkk4oZW9LVdTo/+SnRxVkbhVZEmrgjjnm/r6hS7RMXSBQQep 35TG6m4VOV5HZrNpnvSSiTcI88wbzOPYG0R54AXTTp7NwrwfJclTRyrDnAG6phEfH35+enz4dYRO tA3ZTjQYL2cKWlvYQbORFVycLBv0OtN+5mVhPPfifJB4k3mv6827URxPs/5kGs3uAZYI4xRLYmfs l+Iw68H4aj7XFZZc8VKfYF77zaD3Bb8lUvDKzvowODwYW0RH7qDb6UbwiNgaA1wAaa9UCxZMZlAb 1JjKr0hcbGFqoBReJmjuqTUJeIsOs+jZxVBv37bxbwAAAP//AwBQSwMEFAAGAAgAAAAhAAcJmsLC AwAAAwsAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1srFbRbts2FH0fsH8g tGdFkiVbshC7iCx7GJAmQe3unaWoiCglaiSt2h0K9Le2z+mX7JKykqbOAifNiyyTl4f3Hh4e3fM3 u5qjjkrFRDNzgjPfQbQhomDN7cx5v1m5iYOUxk2BuWjozNlT5byZ//rLeZsqXlzivdhqBBiNSvHM qbRuU89TpKI1VmeipQ3MlULWWMNfeesVEn8C7Jp7I9+feDVmjXNYL09ZL8qSEZoLsq1po3sQSTnW kL+qWKsGtPYUtFZSBTB29cOU9L6FaoEYvdk5yMbJDkYCZw6lkzUvUINrGNgwzSkCgtCfEMwI5mhD d9qGqXYjKTULmu532a7bG2lXX3U3ErHCoB1QHO8wcQizfxsIgxfvh+W3AxJOd6Ws5+c4BVbQbubA 4e3NExbhFJJApB8k96Okun4kllTLR6K9YQPI4G5TOPe2r+i4nNFQTk9KcFdVH4ph6aUgHxVqBNRp yu/LI1fdAGZqNvBthfoj0IbfQ1w/afkY4hVwasnSu0wUe1P4B/i1gzjlSq/1nlNLCKSNUwCHB9DP sVE4bdz3a4OOUz1fcEY+Ii0QLZhGb7HSVCK7P1wBQDkHQjSch0WBJwBCLsPG8Noz8//8hAM/D6SC bjgmtBK8gO1GJhkQ2MDIizgzDDhISAba7kXsgNxACwPhzyHSuAOgUGyS7qk6phVOAfGO34nv+TQb uVqW1SM0W67hMexi63j6MNeUCLiUnHaUn4BoeX8acVMxeTpg2FP1FBErsZW6OjnF6AREVj4B+Dyx RoNYc6zpA43a0n5Wo4WGD8tnMGnMy0Gd1rns9TYmYF9ees9LMGjjsH8Hfr5cXkwCNxkHgRv60cJN ovHInYRRFsNEEsfhF+dgNgWUqllNV+x2K+n11ti4ufMTb+wF8b2MAN1M0Ka4wRK/O7aTl7jDeCB8 JYRxnu9twZ79z1Jeatlz/tcWS9hhoP0lrmAt89gHXpeRycDImrOCoqtt/eEHXsavYZfQyAD0o9RY W3hlRWbLRR5P4gt3GuSZO11FkTsNc9/1F6M8WwZ5EsbxnSKVqbyB7Hohfvv6z2/fvv77CkqEou7b EzDfSwWfttZ2DVvJ4OJk2XQyWiSZmwXRyo3yaexerCZjdzUOo2iRJReLcPkF0mqDKCWS2h7qj+LQ y8HgUf9VMyKFEqU+I6L2+kbOa8UnKlvBbC8X+IeGsMPwKQmSIBiFo8S34od8IUvrCkO2MGQaMfu9 5PItbq87sA2cQusJ6l7YoRaaTdCqCb0PMbUPzev8PwAAAP//AwBQSwMEFAAGAAgAAAAhAOU8qSsP BQAAtxEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWysWNlu4zYUfS/QfxDU Z0WidhuxB/FWFMgkQZ35AEaiY2G0laI99hQDzG+1nzNf0nsp0raydBzHL7ZEXR7e9fCSlx82RW6s GW+yqhyY5MIxDVYmVZqVjwPz0/3Mik2jEbRMaV6VbGBuWWN+GP76y2Xdb/L0mm6rlTAAo2z6dGAu haj7tt0kS1bQ5qKqWQnfFhUvqIBX/minnH4B7CK3XccJ7YJmpanm82PmV4tFlrBJlawKVooWhLOc CtC/WWZ1o9HqY9BqzhqAkbO7KoltDdbWWXK/MQ0pxtcwQMwhWJ7M89QoaQEDd1kiVpwZXzKxNMa0 Rj2kTFPfc8ZQulz/zut5fcfl1Jv1HTeyFKEUhGmrD0pMvpYgBg/2k+mPGon2NwteDC9pHzxibAYm BG6LvzCJ9tlGGEk7mOxHk+XtC7LJcvqCtK0XAA12i0LM69ai5+a42pz7TOTMIDurWlEKU6+r5HNj lBXYiea35iU3aw2GNiN8vTRa9wuEUnLtR+kPLd9In2pFd54gUc91Y8hbsNyPIcucJ14J/Dj0YdBA 3wRhGHmxXEQjwSItdN0Xm1GVbtGlD/APkaNlsqwgUx9wBu3njZiLbQ5xhud1TkAjg+aPUEo5ZAHt p2zxJww1Xwcm5Dss+aAt38lDkLs44GLaB0fAD0zNKVYiK61P83ZJMRznWfLZEJXB0kwYH2kjGDek r6BUQRkEFBIWUOAZAMEkbYq0Dt38eiw9HUud3Xc5TdiyylNYyEU1oAZ03E6KLBSWCVUAKarz4LT4 hsSNoqB1jE76Tnh9QjAHUOIwpV+L76tBLSi/lkWWlSkwBj5ihB5WN0CLctZBqD2ItVpRJQXKwqOL +dFC+UGEUsYxeO7eAgWi8Lw9Xo/4MqePwkPJ1iOAhyAKz9/jES8iWDnHKYi5vQNEFAUYHADGUJSn ASKKAgz3gFDkoOBJGiKKAowOACNfRu4EkxFFAcZ7QEQ7PigdHyKKAuwdAIZBdGJQEEXWwCFlSaph ZXpHOUWeekI2p3CHr7njHuvxkDg8zJD3EgfSMHQkwKdLmi8Uh0hKkluDtBH3zLk0VxO5ZvYX94jA gx2g3QL2O2eHRGIHdox2EY30P3uEZINDLysOUIV/ZMKSTo3ixqLS4UQOIR1OQhCFdyKHkE66noFD ememkA7eGRikg3cGAungnYE/OnhnoI8O3uvsAYlkQILvWk+ZVm9qXJAnZN/SvLtxCTT5TKhgHfLx z0E+qXhGPaTd95ByXuQeSXm69dJdZIch5Isk4gWcKvBk8DdxJtPpVUisOCDE8hx/bMV+4Fqh548i +BBHkffNVE1yCqaKrGCz7BEOIrcrYWJhi2FoBzaJ9i4FdPxwXrYPtcNnVYVd6CHfy7bsvXy/ELz1 +V8rymEF3TX+pG18i9vP65FIe2SeZykzblbFwxO/hOdIRTh8A/SLrvnJbvgW1+wycjQdT6IwurJ6 ZDKyejPft3rexLGcsTsZTckk9qJol5ENWl6Cdm0i/vj+z28/vv97hkyUm64+VgNtXDdwzKnlaXfF Myic0agXuuN4ZI2IP7P8SS+yrmZhYM0Cz/fHo/hq7E2/gVo18fsJZ/Lc/0eq7h9g8NmdQZElvGqq hbhIqsJuLx/suvrCeF1l8v6BOOoSY02BBN2eB32z7wSy2QF9QUt5+tLawhDeHshGKOcfaX27lowJ 1yWQ3WM5VMMFCUQJRfciaLu+cBn+BwAA//8DAFBLAwQUAAYACAAAACEAmh39RAIEAADjCwAAIgAA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWy0VttuGzcQfS/QfyC2z+u9XyRYCrS6 FAUc24iUvjO7lEWEu9ySlCK1CJDfaj8nX5IhV5RrS3Hl2H1ZW+TwcOac4cxcvtnWDG2IkJQ3Aye4 8B1EmpJXtLkbOO8XMzd3kFS4qTDjDRk4OyKdN8Off7ps+5JVV3jH1woBRiP7eOCslGr7nifLFamx vOAtaWBvyUWNFfwUd14l8CfArpkX+n7q1Zg2zv68OOc8Xy5pSSa8XNekUR2IIAwr8F+uaCstWnsO WiuIBBhz+qFLatdCtECMWlDFyKipFlsHGXuxgZ3AGQIF5ZxVqME1LPwOprTEDBl7BIyhBdkqYybb hSBEH2g2v4p23t4Kc/p6cysQrTTaHsXx9ht7M/OzATP4x3t0/M4i4f52KerhJe4DO2g7cEDEnf7C IdwHJ1DZLZb3q+Xq5oRtuZqesPbsBeDB4VLQv+0iOg4ntOE8IiU4hNedwYBxxcuPEjUcAtY8dHGW 1xuLqoPX97Qr1GmitB4O4oKCcp1E+1OdqaHJnpaGauv/gaA0DXux39EUZnEa5Q+5Cv0kM/uasSRP giRMzCUWCS7poNu+2ha82mmmP8BfEFQnzcAhWAffwTKp5mrHiNEDWMN9CAk+YMywfmikcd/PO1s1 HDNafkSKI1JRhd5iqYhAJmp4iYByCXooSAeDAl8ABHesG8YzTdj35YmO5dFJcstwSVacVXBdqJ2B /LY6/JBSmo9HQkG2Qypamc8XLE4yqBcmrU/plfpBL9f7/5dekEaIbdjhUT1fP82wkU+e0M+ICB97 iyHo6SyZk5JDjWFkQ9gZiEbQpxEXKyrOB4y6dH2KiBlfC7U628X4DES6fALwea8gtq9gghV5kPwm tJcmf6Wgcf4JTQizpbNPe1ORwcvv5L15cvYd23JiasZxAVlC49Gd46/An0ynozRwoUoFbuTHYzeP k9BNo7jIYCPPsuizs6+dFYSqaE1m9G4tyM1atyddTFIv8YLsPo0AXW+QprrFAr87rlM/UnYSS/iM c13S/l1vjPYvpXypRMf5H2ss4AZL+3+Um+fQ/rqMpJaROaMVQdfr+sMjXkzXeSkvMKgB9ElqTFl4 5YwspuNJlmYjtxdMCrc3i2O3F0181x+Hk2IaTPIoyw4ZKXXkDXjXJeLXL3//8vXLP6+QiaYP2rEL iu+VhJ7ZmmloLSg8nKLopeE4L9wiiGduPOll7miWJu4sieJ4XOSjcTT9DG61QdwvBTEz4m/VflaF xaP5sqal4JIv1UXJa68bVL2WfyKi5dTMqoG/H3g3GFpJEMRZ0EuixAwf4C94aVq59RaW9IBpGjET b3F7szHlFkZryO6xWWphmIYE1qb3Jjp2O5wPvwEAAP//AwBQSwMEFAAGAAgAAAAhAJMKbXUTBwAA 5x0AABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZzW8bRRS/I/E/jPbexk6cNInqVLFjt9CmjWK3 qMfx7tg7zezOamacxDfUHpGQEAVxQeLGAQGVWolL+WsCRVCk/gu8mdld78TjxinhQ9AcWu/s7715 7/c+5mOvXjtOGDokQlKeNoP65VqASBryiKajZnC33720HiCpcBphxlPSDCZEBte23n3nKt5UMUkI AvlUbuJmECuVbS4tyRCGsbzMM5LCuyEXCVbwKEZLkcBHoDdhS8u12tpSgmkaoBQnoPbOcEhDgvpa ZbBVKO8weEyV1AMhEz2tmjgSBhsd1DVCTmSbCXSIWTOAeSJ+1CfHKkAMSwUvmkHN/AVLW1eX8GYu xNQc2Ypc1/zlcrlAdLBs5hSjQTlpvdvYuLJT6jcApmZxnU6n3amX+gwAhyF4am2p6mx01+utQmcF ZH/O6m7XVmsNF1/RvzJj80ar1VrdyG2xSg3I/mzM4Ndra43tZQdvQBa/OoNvtLbb7TUHb0AWvzaD 717ZWGu4eAOKGU0PZtA6oN1urr2EDDm74YWvA3y9lsOnKMiGMrv0FEOeqnm5luAHXHQBoIEMK5oi NcnIEIeQxW3M6EBQPQHeJLjyxg6FcmZIz4VkKGimmsH7GYaKmOp79fzbV8+folfPn5w8fHby8IeT R49OHn5vdTmCN3A6qgq+/PqT37/8EP329KuXjz/z42UV//N3H/3046d+IFTQ1KIXnz/55dmTF198 /Os3jz3wbYEHVXifJkSi2+QI7fMEfDPEuJaTgTifRD/GtCqxnY4kTrGexaO/o2IHfXuCGfbgWsRl 8J6ADuIDXh8/cAzuxWKs8pA7nt2MEwe4yzlrceFl4aaeq0Jzf5yO/JOLcRW3j/Ghb+42Tp34dsYZ tE7qU9mOiWPmHsOpwiOSEoX0O35AiIev+5Q6vO7SUHDJhwrdp6iFqZeSPh042TQVukETiMvEZyDE 2+Fm9x5qcebzeoccukioCsw8xvcJc2i8jscKJz6VfZywKuG3sIp9RvYmIqziOlJBpEeEcdSJiJQ+ mTsC/K0E/SZ0D3/Yd9kkcZFC0QOfzluY8ypyhx+0Y5xkPmyPpnEV+548gBTFaI8rH3yXuxWinyEO OJ0b7nuUOOE+uxvcpSPHpGmC6Ddj4YnldcKd/O1N2BAT02qgrzvtOqHp2969cO/eFtRbPDdOdex5 uNN9us1FRP/9bXoHj9M9ApUxu1a97dJvu3Twn+/S8+r54nvztB1Dp9Z7J7vpNlvwZO4OfEgZ66kJ I7ek2YRLWISiLgxqOXP6JOWJLIvhp65kmMDBjQQ2Mkhw9QFVcS/GGWzg64FWMpK56pFEGZdwcDTD Xt0aD4cAZY+dq/pAYjuHxGqXR3Z4RQ8X545SjbFqZA63xUQrWsGik61cyZWCb28yWV0btfBsdWOa aYrObKXLmmJzQAfKS9dgsGQTdjcI9kTA8hqc//XUcPDBjESadxujIiwmCn9NiHKvrSMxjogNkTNc YbNuYlek0Ix/2j2bI+djs2QNSDvbCJMW8/NnQZILBVOSQfB0NbG0WlssRUfNYGN1eTVAIc6awRCO vPAzySBoUu8HMRvBvVGohM3aM2vRFOnU4w1/VtXhFmNOwThlnAmpdrCMbQzNqzxULNUzWfuXVxs6 2S7GAU8zWcyKlXVIkX/MCgi1G1oyHJJQVYNdGdHc2ce8E/KxIqIXR0dowMZiH0P4gVPtT0Ql3FyY gtYPcM2m2Tav3N6ad5rq5ZbB2XHMshjn3VJf0xQVZ+Gmn5Q2mKeKeeCb13bj3Pld0RV/Ua5U0/h/ 5opeDuAWYSXSEQjhlldgpCulGXChYg5dKItp2BWw7pveAdkCV7XwGsiHu2bzvyCH+n9bc1aHKWs4 DKp9OkKCwnKiYkHIHrQlk31nKKvnS49VyXJFJqMq5srMmj0gh4T1dQ9c0z04QDGkuukmeRswuNP5 5z7nFTQY6T1Ktd6cTlYunbYG/u6Niy1mcOrUXkLnb8F/aWK5uk9XPytvxIs1suqIfjHdJTWKqnAW v42NfKo3NGGRBbiy1tqONePx8mphHERx1mMYLPczGdwFIf0PrH9UhMx+uNALap/vQ29F8B3C8ocg qy/prgYZpBuk/TWAfY8dtMmkVVlq852PZq1YrC94o1rOe4psbdki8T4n2eUmyp3OqcWLJDtn2OHa js2lGiJ7ukRhaFicQ0xgzBev6kcpPngAgd6B6/8xs5+pZAZPpg6yPWGya8CjSf6TSbvg2qzTZxiN ZOk+GSIaHRfnj5IJW0L2U0mxRTZoLaYTrRRc8R0aXMEcr0XtalkKL58tXEqYmaFll8LmUs2nAD6U 5Y1bH+0Ab5us9VoXV8EUS/8MZQsY76fMe/JZlDJ7UHxtoN6AMnX8espypoC82cSDT50Cw9GrZ/ov LDo2003Kbv0BAAD//wMAUEsDBAoAAAAAAAAAIQDdj7IInzAAAJ8wAAAXAAAAZG9jUHJvcHMvdGh1 bWJuYWlsLmpwZWf/2P/gABBKRklGAAEBAQBIAEgAAP/hAHRFeGlmAABNTQAqAAAACAAEARoABQAA AAEAAAA+ARsABQAAAAEAAABGASgAAwAAAAEAAgAAh2kABAAAAAEAAABOAAAAAAAAAEgAAAABAAAA SAAAAAEAAqACAAQAAAABAAABAKADAAQAAAABAAAAwAAAAAD/7QA4UGhvdG9zaG9wIDMuMAA4QklN BAQAAAAAAAA4QklNBCUAAAAAABDUHYzZjwCyBOmACZjs+EJ+/+IHuElDQ19QUk9GSUxFAAEBAAAH qGFwcGwCIAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAA AAAAAAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAALZGVzYwAAAQgAAABvZHNjbQAAAXgAAAVsY3BydAAABuQAAAA4d3RwdAAA BxwAAAAUclhZWgAABzAAAAAUZ1hZWgAAB0QAAAAUYlhZWgAAB1gAAAAUclRSQwAAB2wAAAAOY2hh ZAAAB3wAAAAsYlRSQwAAB2wAAAAOZ1RSQwAAB2wAAAAOZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0Ig UHJvZmlsZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG1sdWMAAAAAAAAAHgAAAAxza1NLAAAAKAAA AXhockhSAAAAKAAAAaBjYUVTAAAAJAAAAchwdEJSAAAAJgAAAex1a1VBAAAAKgAAAhJmckZVAAAA KAAAAjx6aFRXAAAAFgAAAmRpdElUAAAAKAAAAnpuYk5PAAAAJgAAAqJrb0tSAAAAFgAAAshjc0Na AAAAIgAAAt5oZUlMAAAAHgAAAwBkZURFAAAALAAAAx5odUhVAAAAKAAAA0pzdlNFAAAAJgAAAqJ6 aENOAAAAFgAAA3JqYUpQAAAAGgAAA4hyb1JPAAAAJAAAA6JlbEdSAAAAIgAAA8ZwdFBPAAAAJgAA A+hubE5MAAAAKAAABA5lc0VTAAAAJgAAA+h0aFRIAAAAJAAABDZ0clRSAAAAIgAABFpmaUZJAAAA KAAABHxwbFBMAAAALAAABKRydVJVAAAAIgAABNBhckVHAAAAJgAABPJlblVTAAAAJgAABRhkYURL AAAALgAABT4AVgFhAGUAbwBiAGUAYwBuAP0AIABSAEcAQgAgAHAAcgBvAGYAaQBsAEcAZQBuAGUA cgBpAQ0AawBpACAAUgBHAEIAIABwAHIAbwBmAGkAbABQAGUAcgBmAGkAbAAgAFIARwBCACAAZwBl AG4A6AByAGkAYwBQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A6QByAGkAYwBvBBcEMAQzBDAE OwRMBD0EOAQ5ACAEPwRABD4ERAQwBDkEOwAgAFIARwBCAFAAcgBvAGYAaQBsACAAZwDpAG4A6QBy AGkAcQB1AGUAIABSAFYAQpAadSgAIABSAEcAQgAggnJfaWPPj/AAUAByAG8AZgBpAGwAbwAgAFIA RwBCACAAZwBlAG4AZQByAGkAYwBvAEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcAByAG8AZgBp AGzHfLwYACAAUgBHAEIAINUEuFzTDMd8AE8AYgBlAGMAbgD9ACAAUgBHAEIAIABwAHIAbwBmAGkA bAXkBegF1QXkBdkF3AAgAFIARwBCACAF2wXcBdwF2QBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABS AEcAQgAtAFAAcgBvAGYAaQBsAMEAbAB0AGEAbADhAG4AbwBzACAAUgBHAEIAIABwAHIAbwBmAGkA bGZukBoAIABSAEcAQgAgY8+P8GWHTvZOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw6wBQAHIAbwBm AGkAbAAgAFIARwBCACAAZwBlAG4AZQByAGkAYwOTA7UDvQO5A7oDzAAgA8ADwQO/A8YDrwO7ACAA UgBHAEIAUABlAHIAZgBpAGwAIABSAEcAQgAgAGcAZQBuAOkAcgBpAGMAbwBBAGwAZwBlAG0AZQBl AG4AIABSAEcAQgAtAHAAcgBvAGYAaQBlAGwOQg4bDiMORA4fDiUOTAAgAFIARwBCACAOFw4xDkgO Jw5EDhsARwBlAG4AZQBsACAAUgBHAEIAIABQAHIAbwBmAGkAbABpAFkAbABlAGkAbgBlAG4AIABS AEcAQgAtAHAAcgBvAGYAaQBpAGwAaQBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkA bAAgAFIARwBCBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgZFBkQGQQAgBioGOQYx BkoGQQAgAFIARwBCACAGJwZEBjkGJwZFAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYA aQBsAGUARwBlAG4AZQByAGUAbAAgAFIARwBCAC0AYgBlAHMAawByAGkAdgBlAGwAcwBldGV4dAAA AABDb3B5cmlnaHQgMjAwNyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBYWVogAAAA AAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQWFlaIAAAAAAAAFp1AACscwAAFzRYWVog AAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAABzZjMyAAAAAAABDEIAAAXe///zJgAAB5IA AP2R///7ov///aMAAAPcAADAbP/AABEIAMABAAMBEQACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAA AAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdo aWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJ Cgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVi ctEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqC g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl 5ufo6ery8/T19vf4+fr/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/3QAEACD/2gAMAwEAAhEDEQA/ AP7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgD/0P7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgD/0f7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgD/0v7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgD/0/7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgD/1P7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgD/1f7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgD/1v7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgD/1/7+KACgAoAKACgAoAKAPzz/AGjP2wvjb8Ov2pfhj+yh +z7+zV4T+PHjrx1+z/8AFL9o3WdQ8a/tAP8AAzS9B8GfC74i/Cj4a32laO0fwd+KqeJPE2r6z8Wt GuLK11C58JaXBZ2F41xq29kCgEvwt/4KUfs8eJvgl4p+Lnxv1aH9lHVvhh8a9d/Zm+Mfw2+OPiDw xYeI/AX7Q/hvTrPXbz4Y6ZqOg6tq2ifEa617wpqOl/EDwDqXgO81lfGnw61bT/FlnY2kS6nZaWAZ vxw/4KtfsOfAfwn+y78QvEnxy8EeIPhx+1x8Sb/4d/Cz4heEPFfhTV/CAh0LRPEmpeLPHGs6xLrt pBF4N8FavoNr4L8X3GmDVNb0Dxl4j0PQ73REuG1H+zwD3D/huP8AY8/4XBo3wA/4aW+DP/C5/EF7 pOlaR8Of+E80H/hJb3XfEHh+LxZoPhhbT7WUi8W654XuLbxJo3hKeaLxJqug3Ntq9hpc+n3ME7gH hH/BTX/goXb/APBN/wCE/wAJvi1efBfxF8b9N+IXxvi+GXiHRPCviSDw9rXg7wRo3wY+M/x6+I/x MsrefQdfPiybwT8O/gh4q1GDwVbppN34juWhtLbXdOkUGcAw/wDgot/wU08GfsGfBz4UfFDQfh7c ftD6t8ZPEVuvg7wj4U8Z2Hhe2l+GOnaB/wAJX45+MVz4pn0TxLaJ4O8JaHc+HraBodNnbxB4p8b+ BvDdrc2beIk1C3APp741/trfsi/s3+LPD/gT49/tJfBf4QeMfFFlbaro/hv4g/EHw54Y1aTRb3Uz oln4gvrTU9Qt5NG8N3etK+j2viTWRYaFc6qkmmw6g17G8NAHiv7dn/BRn9nP9ir4X/Fy68T/ABp+ CelfH/w1+z38UfjP8Kfgt47+IGj6FrnxE1Dwj4N8Uaz4M0z+yhqNvrCaZ458UeHj4V0OeJYJ/Eeq fatI8NPfaxCbdADvdf8A28P2XfhP4S+C+pftGfHz4M/A3xZ8Y/h/4R8c6R4a8d+PtD8NSm08SWmj xS6kia1fW89l4Wt/EOsW3h+PxNq/2TRf7UntdNl1EahPHbsAcrY/tu+F/Dvx/wD23PAfxm1n4e/C v4N/skeDf2XvFX/C1fEviFNDtLz/AIaA0nx5cXUHiO/1e7j0e3MGs+GdE0Twra6eFvda1HW4tNhi vdRurC3lAPpDwx+0P8D/ABp8G7/9oXwr8UfB2u/BLStE8XeI9V+Jdhq8EvhXSdH8Azavb+OLvVb8 lf7NbwhdaBrdn4ltL5ILzRb3SdQstQt4Lq0nhUA/Nn9ib/grF8Kvjr+yrfftk/tBfGf9lv4R/Cfx X8RZfCXw+0nRfHWprr3g27vJNRu9A+F3xJ1DxRc20Hij4y6j4XTRvFL6L4E0e13WmpX0Fpos1tpD 6pdgH3Drv7c/7G3hn4ReCvj5r37T3wO034KfEi51mx8AfFKf4j+GD4I8Y6n4e0HxP4l1zR/DniCP UX0/Vtc0rR/Bfiye90Ozmm1eC58P6ppr2Q1S1ksqAK37Q/7ZHwr+AH7M9t+0/HHq3xX8K+LE+F+n /Bvw38Mf7O1XxL8cfGPxz1/w54U+Cfgz4c/2jfaZpd7qXxK8SeMPDdlpN9fX9lpdlYahLrmp3Vrp djd3EQBznwt/aJ+P+n6b8QfFH7av7PHw1/ZF+HPgnwaPHf8Awtez/ar8IfFn4dWGj2ryNrumfEPW Na8A/BnUPAOv+H7FU1TULqDR/Ffw+ayW88j4gy3MEFvdgHnXxf8A+CnX7Nnhf9jb9qP9sH4BeOfh 9+1JpH7LXgPXPF/i7wX8OviLpNvfNqmnaT/bGleGdf1GGw1698FyeIrJo73StT1Tw3dpeaW/9q6Z ZapahSwB4/4i/wCCnfxD+D1j+2p4b/aT/ZVs/hz8Zv2Q/wBiLxT+3lYeEfh38eLH4u/Dj4vfCPw5 Y/EqIaVpXxPuPhj8PNf8E+LJfFXwz1Pw5ead4n+FXlw217Br+iz+I7O2vLeAA+yf2YPit+1J8V9N k8Q/Hz9nX4T/AAO8Nat4Y8OeIvBF58Pf2ltb+O+q662uwfbprLXdJ1T9nj4K2/hgWFhLZyrdW2re Izd3M8tt9mtkgFzOAfWVABQAUAFABQAUAFAH/9D+/igAoAKACgAoAKACgD8m/wBpbw7+0l8Ov+Cj XwQ/ar+E37KfxH/ad+HmlfsT/tBfs7eI7b4Y/EX9nXwTq/hPx38Qfjr+zh8SPC97rtt8evjL8JXu vDFzoXws8SxXeo+EE8V6lY3v2GKTR2W5DqAfMsvwB/4KJfCf4f8Ai34yeFfCes2fxc/a/wD+Cgd/ +0b+1f8ADj9lzxP+z34l+Nvwa/Z7f9nmy+CXw3+HHwP8d/tXQeFvgJ4n8faAvwv+EDfGbxfqNpo8 93YeJvipZ/C2edrfw9rlAHl3gD9kb9s/4V/sr/s++IdT+AHxC+IvxR+Cn/BYn40ftw+JPguvxT/Z 61P4zeLPgj8UvE/7SsKalY+L/wDhMfhv8A9V+Jiaf8cdM8Ya9og8UeA9G1C/svENrpiWNxNYWlwA an7SnwV/4KVftB/tA6BY+I/hd8bj8NfAf/BSP9h74/fDm08L+PP2JvDP7LuhfssfCr4x/ALx5401 bxXazatc/tX+Mv2l/Dkmk/Ey98a6MNQh8AXthoij4da3rcEuh+EfGwB+m/7dHwB8bfHjx3/wT5k8 N+C7Txr4M+Ef7bj/ABO+NttqGoeHbXT9I+Ed7+x5+158JdT1O+07X9RspPEdneeLvin4M8NXGg6F a6zrE8XiB719JbRrHV7+wAPxWj/4Jfftu6h+y/8Ath/DD4heGLLx1r/wO+EWk/sFf8E0tMXx54Qm 1Txf+yZoH7QOi/GKT4n+ItS1nxFFpXhPxj4x8AaP8DfhF4g0vxNrGi6t/wAYuRag1k9v4n0241AA +1v2gfgp+1L4J+NH/BTmDwL+yBqX7VXhb/gov8Kfhr4T+HHjrSviJ8C/DHhD4Waj4c/Z9u/gNrHw 1/aFsPix8RPBvjmy+FWnauNR+LGn6r8JvB3xfu70ePfGmlx+FIPEb2sGrgHy74//AGHf2yPgx8If 2/f2ZPCX7Mtx+2U/7ZP7Cf7PPwH+H/x3X4kfBLwh4R8J+OPgp+x7F+zPrmi/GKx+LPjXRfiFZWcH jPR5vjf8MrvwH4I+Idhqfir4gapYa5f+AriDUfE9oAdJ8Yf2F/2itO+MHxR1jxJ8Lv2v/jF8Gv2o P2IP2Yv2dPF/hL9kT4t/sdeEtS8M6p8KPBHxJ8DfEf4S/GLTP2n/ABV4Qg1H4b+JrT4gXWueGvFn wv8AFeuwWeq654/t9b0CFrnQtXvwD2PxZ+w74s0rVP21rXxF+zl8dfid8H/Gnw8/4Jf6L8E7D4N/ Gn4ReHv2irTxR+yLa+JtSTx94G8Z+Ovib4D0S0+JHwH8c2XgDxjFqHjPxB4d03xvf6dcDRovF1tN e6HegH6U/sGwftUW37Oujwftgy6xP8VYvGnxKj0SXxkPhaPio/wjTx1rq/B5vjYfgZPc/BJ/jI/w +Ghv8QZPhNPL4IfWWc6dI9yb12APyh+DP7J37Wn7Nnwa/wCCO3xJvv2cte+Mni79iH4aftCfDv44 /s4+CPHnwUi+JWjal8dfDeh6VofxN+HOsfED4leDPgx4n8RfD5PC2oeGdRsH+Kuh3lz4R+KPiZtA v9QvILjSL0A2fhl+wd+0DeePf2VPir8Qvgnofh/T9T/4LAftLf8ABQL4kfCC88T/AA58Sr+zb4A+ IP7JXx3+HPwyGs3On67deF/FPxC/4W3cfD3x34lHwou/Glv4f+J/xB1LWdF1bVtI8OXvjNQD9Ef+ CkX7O/xS/aI+AHhcfAtPDV/8b/gH+0L+zz+1Z8JvC/jTVp9A8H+P/GH7OvxU8O/EYfDjxJr1taX8 mg2fj7Q9L1rwtZa89nPb6HrWp6Xq915VtYz3EAB8o/tTxfto/tzfs2+LPA8X7B3jH4Hal8OfiT+y 78b7H4efHn46fs5amn7SWrfAP9pH4ZfGXxn8BtOT4N/EH4ueFtN8F+OPCvgPV9CsPHPxI8T+DbW8 8Q32gWmq+EoPDl1rGtaUAfNX7Wv7KH7XP7afgz/gp78YtD/Zc8WfAbxP+0H/AME8PAv7HXwd+Afx H+IXwDl+Kvxe8d+D/G3xb+IF/wCP/Her/DD4s+Pfg34R0nTF+I1j4E+HX9sfFe/1q7s4/FOp64nh bTptDsroA6P4y/8ABNX4k/B7Tf8Agqb8Gv2O/g2mv/BH9v8A/wCCbXxf0PQJtW8f6Bf+K/CH7aGh fD3xz8JvCnw1k8a/Fjxn/wALDuPh38a/CHxD0PVfDltrOu6t8NvhZ4t8A+Nr9rzwNbfEGVNSAPt7 /gm18NdL+EPhvXPBuk/8E5vip+w3cyeEvAP/AAlviXxz40/Zd8VaL8U/EnhywutLaLSk+An7Tfx5 12C50mS91O/WfxNonhWwltNUItrm4vPMtIAD9P6ACgAoAKACgAoAKAP/0f7+KACgAoAKACgAoAKA CgD5r/aN/a5+Av7KFv8AD6X43eKPEui3XxW8Ual4M+HOheC/hX8WvjH4t8YeJNG8L6z421jTtG8F /BnwL8QPFtwuk+EvDut+INTvm0VNOsNM026ubu6iVAKAO1+Bfx8+D37THw30j4ufAvx5o/xF+H2t Xms6Za69pC31q9rrPhzVbrQ/EXh/XNG1e003XvDXiXw9rNjeaTr/AIa8RaXpevaLqNtNZ6np1rcI Y6APX6ACgAoAKACgAoA+HPjZ/wAFH/2Ov2d/ib4l+EPxb+J3iLw9438EeEPC/j7x5HpPwW+O3jjw r8PvBvjWTxJH4V8RfEL4ieAvhp4m+HfgPTtcPg/xRJYy+L/FWjM9voWpXLoltbvLQB9DaX8dvhb4 g1X4R6b4W8SS+NLP46+EvEPjr4XeL/AuheIvHHw28SeEvDWn+HNVu9cl+KXhPSdX+HWg2Wqad4r0 W78JP4j8TaS3jiKW8Hg5dcfS9TS0APXaACgDk9T8e+CNF8X+FPh9rHi7w3pfjvx3p3ijV/BXg7UN a0+08TeLdK8EjRD4x1Hw5ok9xHqOs2XhZfEnh5vEFzp9tcRaQut6W188AvrcygHWUAFABQAUAFAB QAUAFABQAUAFAH//0v7+KACgAoAKACgAoAKACgD8Zf8Agp14Z+JfjD9rT/gkR4e+EHxNtPg38RNQ /aX/AGnl8OfEm/8AAenfE2y8MzW/7An7S11eyXPgjVtW0LT9dTUtMgvtI8qfV7E2hv8A+0IZTPaR RuAfj3N448e/DD9nP4OfCbxt4y0XwCdH/wCCo/7YHgv/AIK0/FD4nfGfx/8As+fCXxl+0Vq3hHxv 8T/hz41+IvxY+CehaB4g+DX7On7Rk3iX4X/EnwNodhaeFPBcB1T4XfCPxpr+sWV7rl34pAPavHWo R+Dv2Gvglrnjb/go3+yj8TPhx4O/ac/aP8e/D/wL4p/bt+M3gr4GftG/BbT9A8SRaH+yzYft1Wut xfFPxx4x+AWr+JWv/hrqniVPiXaa3J4Z0HSvEuha3J4Qi8TeHgCz46+Pv7O3xK8b+L9a/bq+Mf7R H7HHwyvv+CdP7I3xQ/4J8/DHxj+018bvgp8Q49V8efD7x/rXxZ1Dw/qHhz4h6F4i/aF/bM8CeN0+ HvgjWdA8T6j8R/iRamw8MyW3h25X4g+IZtcAPU/ht+198Qv2ffib8E9d/wCChHxW134SeP8A4z/8 ERv2b3i8L+ML7W9Kf4hftl+GfGnxEuPjR4T+HngHTIWj8T/tLSN4/wDAEep/D34e6JqXxE1Rr2y0 7QdH1DTtJgS3AOU/4J4+DtV/af8Ai5/wTvk+NPxX+PfibQvAv/BDP/gm/wDtFx+ELD46/Ffwn4Z8 X/Hu78b/ABA8n4rfEm38JeLNDv8A4ieJLeLTpYruz8Xajq/hzxQuoSSeNdC8SzaboEujAHBfDX4v 6dJ+zj+2F8QfDH7QXxQ8Tf8ABdDTvD3/AAUfkb9nWT47/F7WvGfhLxN4KvvjSnwr8IWP7IDeLdS+ GukfCzwX8OtJ+GutfAnXLn4X2HhXxl4ij8Iax4e8Q6n4o8dXVrrQB9Q/8Ekb/TvEH7QGoeKfhb+2 b8Afiz8M9Z/ZYsP+FkfAP4aftm/Hn9rr4iSfFqDxp4Mfw18dfidpnx0ln1n4HeOBoVx468E/EXw7 HbeG9R8XeItR0wa34fTUfBE5tQDvD+2D+y7+yX/wVn/4KNSftJ/HH4d/CO48dfsr/wDBOm68B+Hv F2uQReL/AIjReE7/APbYHia3+HPga0S88X/EO/0dtb0aC+0nwboeu6klzq+mWgtDc6haRSgHzN+x vonxi+Cd5/wTB+H+t6f8Q/gt4f8AiJ4B/wCC13xj0b4D6vLq3hO78CfDHx38aPBnxb/Zx8FeNPBk dzAmm+Ivhv8ADT4h6LDp/hvW7NdT+Gt/qOpeE7aDTZtNuLegDwCw0Txv8Hf+CUH/AASr+M0Hxg+J Nzon7XV7+yH4m/4KE/Hn9oX9q79ovQvC58Dah+y18SPFHgPTfiF8UvDmua5qn7P3wUuPi7qHwz+H nijxN8PNM8FWevaNF4S8NfFrxHqel67r+vuAei3viW/8Gfstfs/6N8S/24PCPjT9gDxx/wAFQfEW gfG743/s3ftV/Fzx/wCCPgZ+y5efs++LPEXgH9nfxh+2VqHiDSPibB8LJv2r9O8NeGvF/wAQrzx5 ptv4R8I+NfDXwu1bxXb6Db31kwB6D8VPCn/BPqL9sT/gkB8ZNG+N3iXVv2ZtU8Nftw/Cb4YfHHxV +15+0DceBfEHxC0v4hfDLxT8Hvh34f8Aix4k+LMEHi6DWfFifFPw78OLJ9e1mw+LfhLwz4c8FWVz 478IeE/AmmWAB4z4D+Ldnrd38FPEGm/tEfFm+/4LJah/wU1svBvxq/Zub49/FC71fRfgPD+15rfh 74r+CvFn7Kj+LZvAHhj9kvwj+xdFceMfB3xGh+Gdp4clbT/CHxB0LxlffEDxCbvVQD3nwh+zT8Uv jT8Af+CnP7Q3ww+LP7QOs/tkfDz9tz9tC3/ZhN/8d/i43gjwxZ/s2/tTwfFv4cfAjw58LbDxdZ/D mPwT8RPFHw7g8G+KJdV8J6zrt34X8aa34UXVv+ENh0zw1YAH3z/wSx+NWr/tp2/7RP8AwUKg1Pxr bfB79pTxt4Q8Dfsx+BPEt9q8Wm+Gvgh+zz4Zl8Har4jtvDd7JDYaT4i8eftA638dr/WdUtNLs7rW /DWk+BEu7m+tdK0024B+tNABQAUAFABQAUAFABQB/9P+/igAoAKACgAoAKACgAoAQgHBIBIORkZw cEZHocEjI7EjvQAx4opUlikjjkjmVkmjdFdJUdPLdZUYFZFaP5GVgwZPlORwoBG1naPDFbva2728 DQNBA0EbQwtbFWt2iiKlI2gZFaAoFMRVShG0UASvFFIY2kjSRoZPNiLorGKXY8fmRkglJPLkkj3r htjuuSrOKABo43aNnRGaJzJEzKGaOQxyRF4yeUcxSyRllwTHJIn3XYMAOCquNqgYAUYAGFX7qjHQ DJwOg7d6AGCGFZXnWKMTyRxxSThFErxRNI0UbyAb2jjaWVo0ZtqNJIVALsaAEit4IWmeGGKJriXz rhoo0jaebYkfmzFVBll8uNE8xyzbERcgKtAEtACYGQcDIyAccgHqAe2cDPrj2oAQohQxlVMZXYUK goUI2lSvKlSONuMY45oAiW1tlthZrbwLaCH7OLVYkFsLfZ5fkCAKIxD5fyeVt2bPlwQaAHNbwOkc bQxNHC0TxI0aMkTwENC8akbUaFlUxMoBjKgrjAoAcIohK0wjQTMiRNKEXzWijZ3SNpMbiiNJIyIS VVpHIALMWAMrX9IbXdA1zQotV1bw++taTqelJrnh6eCz17RpNSs57Qavol1dWt9a22sae0/23Trm 4sryCG9hhlmtbhFaJgDzj9n/AOB3w/8A2Z/gj8Kf2ffhVYXem/Dv4OeBPDfw98I2+o3X9oatLpHh nTLfTodR1zU/KhbVvEOrvDJqviDWJYkm1fWr2+1KdRNdPQB6/QAUAFABQAUAFABQAUAf/9T+/igA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/9X+ /igAoAKACgAoAKACgAoAKACgAoA8m+OHivxV4L+Gmt694I/sX/hLBqXhHRdCbxHa3d9ocV94p8Z+ HvC6z6laWF7p15PbQJrDzFLe9t5NyKQ5AZGAPFP+Gj9c8QeKvgjYeFdN0y10TxXbTH4rQ6nb3F5q /hbX9T8EfEjWNG8H6dLBqFpZxa5omv8Awv8AFtr4riulumtorPTIkSFNYhvUAJr/APaG1vVPhN4x 8QeDvD2tX2oeFvgh/wAJpq3jq4h8NWGj6D4u1X4QP8StCtbjw5d65d319ItrdaHc6la6dDq1hYy6 9pdmtzqNsurXOmgHaP8AH+Gw0fXJ9c8IXnhzXvD2reHtLvNG8VeLvh/4ehnj8TeH5fEOj38WuXXi d9EeS7gtbvT20i0u7zVY9Yt5Y0tZtIjfWqAMq2/ar8B6jqngWw0rS9cv4fG2ifCvXVlWXRIdR0q1 +MTxJ4RWXQH1X+2NTNklzaXvi2fSLa8s/D2lXUeom4vYbbUlsADE1z48+IfBfwA8G/FjVLR/EF7d eJrGz8Q2em6T9p1C/wBHfxBq1newaLp9nLaRLqz2FjHDZSSN9ljn/fXYMXmSKAdJd/HTUPB/h2O7 8TaGPGuq6R8O3+MHxA1D4c3GlN4Z8LeAr+81efTp9Hudc1u2u/GEkGmaVq0dhNpcKy+JYPDWpawt lok2qaRodwAU/Fv7Rd1p8fiS38KeDH1fV/DHxK+GPgW60vVNe0LS9TubLx58RvD/AIG/t5dDl1OP V7HStTXWDL4N1q8gXStbMkGoPItja3sSgF69/ab8J2XjDWfCDaHrFzcaFN4g0vULuyvNCumt9f8A DPgW58f6rZXGlxan/bFppCadZ3WiweJbuxi0ubxPEmlBlgvdNvr0A9m8CeJ7vxn4W0nxPd+HNS8L DWrWHUbLSdXutLutRXTLyKO5064uzo97qFlBPc2k0Uk1mt1LJaSl4JGdk3sAddQAUAFABQAUAFAB QAUAFABQAUAf/9b+/igAoAKACgAoAKACgAoAKACgAoAxPEPhzRvFWmHRtfs/t+mtf6PqZtvtF1a5 vdA1iw1/SZvOs5ref/RNW0yxu/LEvlT+R5FzHNbSTQuAcbY/Bz4a6Zd3V/p/ha2s7u++IGsfFK8l t73VIjc+PNf8O6l4U1jxBKq33ltLfaFrGp2stjs/stZ7ybUorJNUYXqgGM3wA+FZtpbCPQ9WtdLu vBsHgHUNHsPGvjjTtF1fwxa+FrjwVaWut6PY+I7fTdb1C08LXUmj2uvara3mvQwR2Mqamt1pemXF oAbWvfB/wB4j1D+19R0rUYtX/tLStXTV9G8U+K/DuqwX+jaBrHhWxmtNR0DWtNvLNR4d8QazpF1D aTRQ39pqEwvo7mURPEAQ6T8Gfh/oFz4buvD+na1oDeFPD/hbwrpcGh+M/GmkWNx4e8ExyQ+FtL8Q afp/iG3sfFcGjwSzW0L+KLbWJ57See0vJri0nmgcA3Ifhz4Ng0Lw94bi0bbovhXWrHxDoNl/aGqt 9g1jTdRl1WyvPtDXxu7ryb+4mn8i8nuLWTd5Utu0ISNADjbn9nv4SXVpaae3hq8t9NtLHVNI/svT /FfjHS9LvfD2saxc67eeE9Y03TvEFrZa34MXUbu7+weDdXt77wvpWn3V1oulaTZ6LdXGnOAaWr/B T4e69c69eazY69qV74hNibm8u/G/jia70v8AsvxLY+MtNHhS4bxF5vgtNP8AFOmabrlnH4SfRkt7 zTdN8sLBp1jBbgFz/hUfgj+0ta1RbbxBFJ4kt7qDxDYQeN/G8Gg6297oMfhm7vtV8Nw+Ik0C+1a5 0WGC2uNZuNMfVZri3ttSlu31S1t71ADvtO0+z0nT7DStPh+z2GmWdrp9jB5ksvkWdlAltbQ+bPJL NJ5cMaJ5k0skr7d0kjuWZgC5QAUAFABQAUAFABQAUAFABQAUAf/X/v4oAKACgAoAKACgAoAKACgA oAKACgD520H44/8AEw8TaT4h055rrTL3486jp0ukxRxQf8I38GNf8K6VJa3QubxpJNY1GHxdYvDL HstJHtbppRaZhRwB2m/tD6XqWvWmmr4M8T2+hzeIvCPhS68WzXPh0aTYa743+Huh/EPQrWWyGsnW 5YhY67Z6XqV3Dpj29nqM9oY2urOS7udPALnwl/aE8J/F5tRk0axv9N0628N6P4ysdWv7zRbnT7zw 3rjXv2Wa9m0rUr8aBrFtDZLeanoGt/ZL6xs7+xlbzZRqEGngHmngj46+MPiZr/jeLwzf+GBoljdf B/xP4PtNK099e8Rt8O/Ffi3xDouv3niG0i1jzDeajo2g2vigQW1hYX/hfStei0jULV9ZtXu1APfP hfN45Ph61tPHccbalaaX4a8q9FnPZ3Vy1x4c0ybU4NU87UdRF5q1hrBv7e+1CA2VvdyYaPT7bY28 A888cfEbxr4I+JMVlHf+H/FHhQeC/G3jbX/C2n+HL+x8R+EPDfhfQGudJ1u+8TnxHqFldzeJPFVv PoGn2M/h7Tv7Sgmu5tKic+EtcuLsA4WT4r/GOw8MeOPtF78Pb/xNY/Anw98a9C1KLw3rtroukNqM Xiptc8O3ulr4pu7rXYbM6FZf2BqA1fQ5Lz7ZetqEe2xRLoA7bx/4u+JtlZ/Cy/8ACHiTwvbaj8Qt V8EeHrTwpqXgy81aS+vdRWXxB401lNZg8W6W9hp+g+BtP1/XFtTpl03maIlsbt5tSiEAB9I0AFAB QAUAFABQAUAFABQAUAFABQB//9D+/igAoAKACgAoAKACgAoAKACgAoAZLGssckTlwsqPGxilkhkC upUmOaF45onAOUlidJI2w0bq4DUAeN3P7P3wrvNF0/QbnRtbks9On8Vzi6Hjvx9FruonxzOLnxlb 6/4mh8TR+IvElh4mnWGTWdM1/VNS069+x2CS2vl6fZJbgHSWfwp8A2ChLTQfKVfEXhrxYo/tPWZM a/4Q8OaN4S8O3/7zUHJ/s/w/oGkaf9lP+h3f2T7VfW91ez3FxKAWvB3w58K+ArWbT/DEOtWukyW1 vYW2iah4r8V69oOkadaCVbXTPD2ha/rWp6T4c0y2jma3g0/Q7PT7SGyS10+KJbCxsba1ALWi+AfB vhzX9Y8T6D4c0vSNc17TdI0jVr3T4PswutP0KbU7jTLf7NEVs4BBNrF+8sltbwzXZkhF7JOLOyEA Ba1Lw8+peJPDGvNrGp21t4ai11holpPJb2Grahq9ta2FteasIpU+2xaTZDVFs7CdJbY3mpR6gVW6 02zdQDl7X4QeBbPxlrvj23tfESeIfE86XHiJW8eePZfDuuPHoo8PQJqngubxNJ4Mvba20hVtbSzn 0CS0tHAu7aCC8AuGAMe2+APwvs/Deu+E7fSvEMWjeJNH0vw5qyr8QfiH/acvhnREv49I8K2ev/8A CV/2/pPhXTotV1SG18M6TqdloUcWpajH9gKX12JQDrdJ+HPhHRbjwnd2llqNxd+B9G1rQPC93rHi LxJ4hu9M0zxBNpkuqxtda/rGpz391MNHsLW31LUnvNS07To59K028tdNvb21uADuKACgAoAKACgA oAKACgAoAKACgAoA/9H+/igAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoA/9L+/igAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoA/9P+/igAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoA/9T+/igAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoA/9X+/igAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/9b+/igAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/9lQSwMEFAAGAAgAAAAhAFycRxROAQAAiQIA ABEAAABwcHQvcHJlc1Byb3BzLnhtbLSQzWrDMBCE74W+g9FdkWQ7dmxiBzt2odBDDu0DCFtOBNYP kvJTSt+9wnFLQy+59LbLMrPfzHpzEWNwYsZyJQtAFhgETHaq53JfgLfXJ7gCgXVU9nRUkhXgnVmw KR8f1jrXhlkmHXVeujOBN5I2pwU4OKdzhGx3YILahdJM+tugjKDOr2aPekPP/oEYUYhxggTlEsx6 c49eDQPvWKO6o/AAVxPDxonEHri23276HrffOW6QSh+SXdyLdfMUHA0vwEebJts2iyuY4GgLYxKH sM7aGiYNiVKMCa7C9BN4DYnzntuOmv5Z0D1re+4a6ugc1Z//4AneGWXV4BadEuiaE2l1ZkYrPkUl eO7rRMcCYIDKNZowbxmbiFQ4CSuYZqsKxlGYwapuGljX1WqZJCFeEvzDyAZ6HN3E2Gj+X3hXzKlN P/5ufWfKLwAAAP//AwBQSwMEFAAGAAgAAAAhAFR/ElG4AQAAjgMAABEAAABwcHQvdmlld1Byb3Bz LnhtbIxSwW7bMAy9D9g/CLq3toM1S4w4RYthuxTYgKS7a5LiqLAlQVRSJ1+/J9tJmyKH3kiKfHzv iYv7rm3YXgcyzla8uM0501Y6ZWxd8ef1z5sZZxSFVaJxVlf8oInfL79+Wfhyb/Trn8AAYKkUFd/G 6MssI7nVraBb57XF28aFVkSkoc5UEK8AbptskufTrBXG8nE+fGbebTZG6h9O7lpt4wASdCMiyNPW eDqh+c+g+aAJMP30BaUlxNlEu/k7SNy6cHwUYYVeWNCKzrTmqBVPjQCJLmj1pDeR0REe3k0nOc/e v62d75/m8+ndnDOxi+5BvewoVrzvzC73pVFqjNLD+pTKVaNGMmSFX7tfwag0zYb0978XLSNhe09K jr17kJaiAemhTilZLkRJHUvfXYANYIq8p4Hy4UoZ7MY5X7pgamNZV/GbopjgNg4pyr8lvegb9ybG 9Q4CniieY4ZZ2I2fgZuceQe2k2I6WtW3j8XZ7OTKG0gCP3vQ7/rgkHVR01p38Z1pb+FH4RB8Tfhl +bpwTEL0ieFZMZqvUKjxTSsvJK6eSbj2HbcBAAmEIRx82/d3tvwPAAD//wMAUEsDBBQABgAIAAAA IQDY/Y2PrAAAALYAAAATAAAAcHB0L3RhYmxlU3R5bGVzLnhtbAzMSQ6CMBhA4b2Jd2j+fS1DUSQU wiArd+oBKpQh6UBooxLj3WX58pIvzT9KopdY7GQ0A//gARK6Nd2kBwaPe4NjQNZx3XFptGCwCgt5 tt+lPHFPeXOrFFfr0KZom3AGo3NzQohtR6G4PZhZ6O31ZlHcbbkMpFv4e9OVJIHnHYnikwbUiZ7B N6qCIKK0wKfL5YhpSANcejTGcVTW1bmp/SosfkCyPwAAAP//AwBQSwMEFAAGAAgAAAAhAAth9lCK AgAA/gUAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAnFTfb9owEH6ftP/BysvaBwh0qOuQcVXBqk4aAwFtn13nQqwFX2QbWvbX7+I0lIyo0pan +/H5892X8/Hrl03OdmCdRjOK+t1exMAoTLRZj6L71W3nKmLOS5PIHA2Moj246Fp8/MDnFguwXoNj RGHcKMq8L4Zx7FQGG+m6lDaUSdFupCfXrmNMU61ggmq7AePji17vMoYXDyaBpFMcCKOKcbjz/0ua oCrrcw+rfUEFC75CL/OV3oDoX/R4/ObyR7SJE18ur3hcmfymKHKtpCdFxFQriw5Tz6ZSaePRZWyO z2DnSB6Pj7EkCTjqK5y8DW2Lmek4ZQEMW2b4zM4Gw8/nPG4B8rm0cm1lkTnR71OJRz5f5joBJ6jE V4v/RE8BglUGv9NJAuY1S+GGz6fTca6LgK9NvlQyhzGJJFKZOyDqQ4DfgSwHYC61dYLv/HAHyqNl Tv+mERhE7Ek6KKUdRTtptTSeJC5hlRPsvHDeihXNAnFTrvKDeQw7tvVA9AOAjHeBFVfolq20z8H9 wxWkIpVzckUZrNqku5sCVFfMUvolvkWPr8d6hNIqNaoqZ2Hm2YkQB0km0ks2xQRyx+ixsDEuvjG2 AIdbq4BNtA3i749bPBx+zKT/5JjPtGPyCbf+uhUWOBcT9nZXK0yhha5NWEnGFOY53UyvgGFKSyEp ypFvKH0o4/Vgp0a1MdDjCB29z7C2uC3ajrOQ0aZcRqr5w0/KaEDbyOo622uZ+QwsOzNoztn3TSFV s+vGpPw1G2MkvNmLm8WUx7XDf2jzy90XKyT9oX5vzSBfZtJCQruxzr8F+B09NZuXJONMmjUkNeY0 UW6vh2qdi/6g26MvbKk6Vi6fenGLPwAAAP//AwBQSwMEFAAGAAgAAAAhAOjkSdHuAwAAsyQAACgA AABwcHQvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu5FnNctowEKa5wRv05nIH kYSGtOOQoRCmzJDEE6AzPWUUW6FOjOWxRVP6SH2/3ruyLSP8F9pDajuHzDhCWu3vt6vdg1qt9gb+ fr2t1dTzHytL+U5cz6T2WfOw3WkqxNapYdrLs+ZiPm6dNs/7DfXd6Ho4/6pdKI5lekzRFp+mk6HS bCE0cByLIDSajxRtOpnNFaCB0MVVU2l+Y8z5iNDT01Mb811tna74Rg9pLnWIyzZTINaCA22DGU24 JqC+ww6sGqbO+o26+kg2fSAREnNc02ZtDS/JmLorDJ+Xn6lr/qQ2w9YN8VTE98Ox8Hj6eWbqj4S1 dZdgRl1xpq56DMgvpese6F2wV0Xhb416LkmTkdXAdfFmSxTzf4ElOCiYyqDxvFicCDBt9XtHKvI/ ON1cjjyGGRlbeBlxBPtBiWRJ3H5HReLTZxAJDlUk2FbF2vOWuHZNAnZg4FXiskjk1NNlsEOKUFzj Qm2HuxosiilmOrbAlatjhphAUSCA/gsXB18A5UwwQKXwKEWoyAiFRCPBcMxzyo9IGYJF1ihISHjr u3mQZx0Mef/WtO/pbYD46bCkXWraSON7h9QgV3hFxD4pc/5NHtk3oeeCdjKj11WRG7nKjaBOgc+A TI4UfEtYRkwJYwQqj21VIc7Ha51AY+20NL7NQrE8Xo+SNtwYZXJp1deiz+ncxbZn+Tl75lc/vgFK rfw9RJIssZgpxTDG3KRLXHLtZ8ggqdvGLasAvh+Psp3Se2A8rD1GDL54Q3RWRhj6NwG5oSRwg/9E nRtHmPyfgjfKcVcuzuCEv/y+d7KzLAHUy2PgnmqCnFRxR4hLmPQE33itw9Md44U2zVju9dI94MPu csE8AFQxgVoFWgulRuOka+cJVgaI3vK/sHElMXovCZOh+epAOl1PsFodlN5PxKQvvDqYdhyjulCd JZwE10V4vcRzTfhoHWgTaFbwKcO2hA5fvJ1O+whqyu37N+9hzzaO1AsIz8Tv9JM1T9xzv+sg0Y5e w3l3JHkVb/U4q3lUZE7F+SSjYnoR51QwqiJ/JtJvHMDE5nejAhObEdXXKxgOBBJDvM4cSq1ghiN8 I2ql5Cm4aDObfQSTgpWPxKA1zEckyDHuJSflm9JmXWEopfV/sh5nwo2AYtT8idZSL9H4WG0G73KY GXhgnSF1zLIP03JF4toWVVOBRjhJnjdDakF7LoK/UgZJinvF5eIGYe6aIH9SWqBQGJuux3gnqNQw FbdAQqpyBMQUV9AWcaFkUxwddnvd0+OTbq84c+YYSPldUmxXLEASUnGryK3RzPSxTSzZxovSMqf6 37J+WFq8YOUru86zxe8fAAAA//8DAFBLAwQUAAYACAAAACEAwUYFd20BAAC2AgAAEQAIAWRvY1By b3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJdT4MwGIXv TfwPpPdQPoYfDbBEzW50CYkzGu+a9t3WCC1p69j+vQU2ZJkXXpZz3qfnPSWb7+vK24E2QskcRUGI PJBMcSE3OXpbLfw75BlLJaeVkpCjAxg0L66vMtYQpjSUWjWgrQDjOZI0hDU52lrbEIwN20JNTeAc 0olrpWtq3VFvcEPZF90AjsPwBtdgKaeW4g7oNyMRHZGcjcjmW1c9gDMMFdQgrcFREOFfrwVdmz8H emXirIU9NG6nY9wpm7NBHN17I0Zj27ZBm/QxXP4IfyxfXvtVfSG7rhigIuOMWGErKErVgi6VkNYr NRiXmFpXdoZHR+dlGqhVulgKtqVQec/KuLi96SR1lVfU2KV7nbUA/nC4cF86uiENO9G9b5HeZ3h6 dhf3nQy3A/fclmTo5KS8J49PqwUq4jC69cMbP0xXcUhmKZnFn126s/lu6+FDfcz4T2JCwpQkU+IJ UPSJz/+04gcAAP//AwBQSwECLQAUAAYACAAAACEAel71aP8BAABJEAAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCj7IImDQEAAOICAAALAAAAAAAA AAAAAAAAADgEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAA AAAAAAAAAHYHAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVsc1BLAQItABQABgAIAAAA IQBjXCO0wQAAADcBAAAgAAAAAAAAAAAAAAAAAHMIAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54 bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAHIJAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAg AAAAAAAAAAAAAAAAAG8KAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc1BLAQItABQA BgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAGwLAABwcHQvc2xpZGVzL19yZWxzL3Ns aWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAGkM AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAA ADcBAAAgAAAAAAAAAAAAAAAAAGYNAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc1BL AQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAGMOAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlOC54bWwucmVsc1BLAQItABQABgAIAAAAIQC1asWaZQEAABoIAAAfAAAAAAAAAAAA AAAAAGAPAABwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALvj eMmFAgAAjg0AABQAAAAAAAAAAAAAAAAAChIAAHBwdC9wcmVzZW50YXRpb24ueG1sUEsBAi0AFAAG AAgAAAAhAFfL096fAgAATgYAABUAAAAAAAAAAAAAAAAAwRQAAHBwdC9zbGlkZXMvc2xpZGUxLnht bFBLAQItABQABgAIAAAAIQCL4swzkAMAAFMIAAAVAAAAAAAAAAAAAAAAAJMXAABwcHQvc2xpZGVz L3NsaWRlMi54bWxQSwECLQAUAAYACAAAACEATdepwA4OAAClsAAAFQAAAAAAAAAAAAAAAABWGwAA cHB0L3NsaWRlcy9zbGlkZTMueG1sUEsBAi0AFAAGAAgAAAAhACd1E0xQAwAAcwcAABUAAAAAAAAA AAAAAAAAlykAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQItABQABgAIAAAAIQDluEt8twMAAPEP AAAVAAAAAAAAAAAAAAAAABotAABwcHQvc2xpZGVzL3NsaWRlNC54bWxQSwECLQAUAAYACAAAACEA BFo4K64DAAAvEAAAFQAAAAAAAAAAAAAAAAAEMQAAcHB0L3NsaWRlcy9zbGlkZTYueG1sUEsBAi0A FAAGAAgAAAAhAAW7I/jVAwAAIRAAABUAAAAAAAAAAAAAAAAA5TQAAHBwdC9zbGlkZXMvc2xpZGU3 LnhtbFBLAQItABQABgAIAAAAIQDdhj9/+QMAAFcRAAAVAAAAAAAAAAAAAAAAAO04AABwcHQvc2xp ZGVzL3NsaWRlNS54bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAAAZ PQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAIj4AAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAA AAAAAAAAAAAAKj8AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAMkAAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAAC0AAAAAAAAAAAAAAAAAOkEAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx MC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAENCAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc1BLAQItABQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAEtDAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAA AAAAAFNEAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc1BLAQIt ABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAFtFAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAs AAAAAAAAAAAAAAAAAGNGAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwu cmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAGtHAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc1BLAQItABQABgAIAAAAIQA0zbnO HwEAAMcHAAAsAAAAAAAAAAAAAAAAAHNIAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFz dGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQCqUN5alAQAAG8QAAAhAAAAAAAAAAAAAAAAANxJ AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAAACEAtKtbX9kH AAAHLgAAIQAAAAAAAAAAAAAAAACvTgAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s UEsBAi0AFAAGAAgAAAAhAAyvcS44AwAASwgAACEAAAAAAAAAAAAAAAAAx1YAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQBxwT0NwwUAAPYaAAAhAAAAAAAA AAAAAAAAAD5aAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54bWxQSwECLQAUAAYACAAA ACEA7GAGSm0EAABBEQAAIQAAAAAAAAAAAAAAAABAYAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAGFdmI3ZBAAA3xAAACEAAAAAAAAAAAAAAAAA7GQAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbFBLAQItABQABgAIAAAAIQBoLl22qAMAAMwK AAAhAAAAAAAAAAAAAAAAAARqAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwEC LQAUAAYACAAAACEAguHqjTIFAADqEQAAIQAAAAAAAAAAAAAAAADrbQAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgAAAAhAJ4s2e7/AgAAIgcAACEAAAAAAAAAAAAA AAAAXHMAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbFBLAQItABQABgAIAAAAIQAH CZrCwgMAAAMLAAAiAAAAAAAAAAAAAAAAAJp2AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 MTAueG1sUEsBAi0AFAAGAAgAAAAhAOU8qSsPBQAAtxEAACEAAAAAAAAAAAAAAAAAnHoAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbFBLAQItABQABgAIAAAAIQCaHf1EAgQAAOMLAAAi AAAAAAAAAAAAAAAAAOp/AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1sUEsBAi0A FAAGAAgAAAAhAJMKbXUTBwAA5x0AABQAAAAAAAAAAAAAAAAALIQAAHBwdC90aGVtZS90aGVtZTEu eG1sUEsBAi0ACgAAAAAAAAAhAN2PsgifMAAAnzAAABcAAAAAAAAAAAAAAAAAcYsAAGRvY1Byb3Bz L3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhAFycRxROAQAAiQIAABEAAAAAAAAAAAAAAAAA RbwAAHBwdC9wcmVzUHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhAFR/ElG4AQAAjgMAABEAAAAAAAAA AAAAAAAAwr0AAHBwdC92aWV3UHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhANj9jY+sAAAAtgAAABMA AAAAAAAAAAAAAAAAqb8AAHBwdC90YWJsZVN0eWxlcy54bWxQSwECLQAUAAYACAAAACEAC2H2UIoC AAD+BQAAEAAAAAAAAAAAAAAAAACGwAAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQDo 5EnR7gMAALMkAAAoAAAAAAAAAAAAAAAAAEbEAABwcHQvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJT ZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAMFGBXdtAQAAtgIAABEAAAAAAAAAAAAAAAAAesgA AGRvY1Byb3BzL2NvcmUueG1sUEsFBgAAAAA0ADQAmg8AAB7LAAAAAA== --Apple-Mail=_2890A3AE-A783-4359-B51F-2C1D12AB8DBE Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Sep 4, 2017, at 8:27 AM, Jim Schaad wrote: > > Yes that is what I had in mind. It would be useful to add a ttl attribute > as well. > > Jim > > >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Monday, September 4, 2017 1:46 AM >> To: Jim Schaad >> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org >> Subject: Re: draft-ietf-core-resource-directory = GET /rd >> >> Hi Jim, >> >> Personally, I like the idea. >> That would mean that all registration resources are returned. >> In the next version of the RD, location or endpoint identifies the > registration. >> Uniqueness of links is specified in section 5.3.4, already commented on by >> you. >> Your request means returning all locations with the ep, lt, d, and et > attributes >> and the associated scheme://authority:port value. >> >> Correct? >> >> Peter >> >> Jim Schaad schreef op 2017-08-31 03:59: >>> I am wondering if there should be a GET action defined against the >>> resource directory object. Currently, if an entity does a >>> registration for an endpoint it gets back a location for that >>> registration. If a second entity modifies the endpoint and wants to >>> update the registration, it currently has no method to get the >>> location associated with the endpoint and cannot make a second new >>> registration since the pair is required to be >>> unique. >>> >>> Thus >>> >>> Interaction: EP -> RD >>> Method: GET >>> URI Template: {+rd}{?ep,d} >>> >>> Content-Format: application/link-format (or variants) >>> >>> ;ep=endpoint1,;ep=endpoint1;domain=beta, ... >>> >>> Jim > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_2890A3AE-A783-4359-B51F-2C1D12AB8DBE-- From nobody Mon Sep 4 23:37:32 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE413236D; Mon, 4 Sep 2017 23:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 A5DvKpvRdE21; Mon, 4 Sep 2017 23:37:28 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 33DE4120727; Mon, 4 Sep 2017 23:37:27 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud7.xs4all.net with ESMTPA id p7UCdXTLyb2snp7UCdkSX3; Tue, 05 Sep 2017 08:37:26 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 05 Sep 2017 08:37:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 05 Sep 2017 08:37:24 +0200 From: peter van der Stok To: Michael Koster Cc: Jim Schaad , peter van der Stok , draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfFuQUURrMw5+lMsHUGBi2Iv+rVLWS0z/JUBnYF4mU2Tug9IdLLNpkjis+WwKdIsFGsQGP7eMTCAAKGMhmupyWfB4O9930B+iOWyHGYHb1RJHYj2XOZJP Qri67itSNwaMsvZwjjHf4kyFYwAoEeTw37Or6Y5iobA6dYu70L/lgz++CvoGwSiHZ7OOufSRWxnUdS/Zq5wOoOE0ahLYv0aQFa6Uk9thSAm5joAdddRQodpk D0RsGesYQk/SUxaAMM5d5gxFZz0TNUo0MgppV4L+QP3KL+zDkmeccJhhSLu95wFq Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 05 Sep 2017 06:37:31 -0000 Hi Michael, Originally, I thought the same, but the packets get really large by doing a complete dump. The compromise is just sending the (endpoint names/ registration resource location) with its registration attributes. Peter Michael Koster schreef op 2017-09-05 08:27: > I would propose returning links for all registration resources in the > RD as shown in slide 4 of the attached deck (JSON format shown). This > would include the most recent setting of the "lt" or lifetime > parameter as a link target attribute as shown. > > > > >> On Sep 4, 2017, at 8:27 AM, Jim Schaad wrote: >> >> Yes that is what I had in mind. It would be useful to add a ttl >> attribute >> as well. >> >> Jim >> >> >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Monday, September 4, 2017 1:46 AM >>> To: Jim Schaad >>> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org >>> Subject: Re: draft-ietf-core-resource-directory = GET /rd >>> >>> Hi Jim, >>> >>> Personally, I like the idea. >>> That would mean that all registration resources are returned. >>> In the next version of the RD, location or endpoint identifies the >> registration. >>> Uniqueness of links is specified in section 5.3.4, already commented >>> on by >>> you. >>> Your request means returning all locations with the ep, lt, d, and et >> attributes >>> and the associated scheme://authority:port value. >>> >>> Correct? >>> >>> Peter >>> >>> Jim Schaad schreef op 2017-08-31 03:59: >>>> I am wondering if there should be a GET action defined against the >>>> resource directory object. Currently, if an entity does a >>>> registration for an endpoint it gets back a location for that >>>> registration. If a second entity modifies the endpoint and wants to >>>> update the registration, it currently has no method to get the >>>> location associated with the endpoint and cannot make a second new >>>> registration since the pair is required to be >>>> unique. >>>> >>>> Thus >>>> >>>> Interaction: EP -> RD >>>> Method: GET >>>> URI Template: {+rd}{?ep,d} >>>> >>>> Content-Format: application/link-format (or variants) >>>> >>>> ;ep=endpoint1,;ep=endpoint1;domain=beta, ... >>>> >>>> Jim >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Tue Sep 5 11:37:36 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54D6132E01; Tue, 5 Sep 2017 11:37:34 -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 kGmLtYWo4fFc; Tue, 5 Sep 2017 11:37:32 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 D15E6120720; Tue, 5 Sep 2017 11:37:32 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id v82so1735720pgb.1; Tue, 05 Sep 2017 11:37:32 -0700 (PDT) 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=plTfvRlB36lvlWo19mg7nb70tgacT1NfwC1GCJ5GWyE=; b=T/ZfKMpjYC8rxnmPLEAYUg0P210cK5J/NfUgkBs3nnBBjyV3gekEGwCz/wUwsCYa1c sM9b0YCMJpSaEpu42m5zrsp/Njj8txTA1ObNAwqTm/JDaCENaC1FDFK7WT1bGVVaI6kT 8QOcMxUq3r3iIezjtzjt7I3roTYGHlDHHBKBHs3hhZumTPz/Vrql/n/vhhY2zuCo/JOB GNTZeU8N5AyWeTdbVvII+J06M3QFXflY/tUDDPDCpMWb50mKcwisSpz/fX7IDZzuTjJ5 xRrdn/t9lJx6ZZYnMRLxUVSLwevIVeqw57pM/sdnww0/AEWLh/07ygozyKs22m9/9pBe JNSg== 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=plTfvRlB36lvlWo19mg7nb70tgacT1NfwC1GCJ5GWyE=; b=pupcq7qKeXpY8/YXeeo92ld3bHq8xMi7lchMlZHaEl0y1z2WQna9ADDBrL1Zrt6BUv tLt6XJOSY54vkLIM/0Es6JIvq/y0oNJO1zcJe26vbhXLd1FYXfj8pDhM0sBAMuV9bd4w ChN6AXCa6She61+9nScgyFos4sRUL27Nkc7/cprRCXXVVIWOwIfiOWIHXPpwl5FjzjP+ zkn+cDyUSbWKjF8+gXOgKV6+maaQZbL9VPqRPEIi1sk5H+slYKuMMyNYEV3sgQ6bPTR1 85sxXJ1Y+1bYknSYaSvisjQtT+JZtxFH9c10EfvuTib593ImLCjAR0bPgZbLcCsr4vRB cRKw== X-Gm-Message-State: AHPjjUhppoxG9VKWlXk6WwIcwy25UuzGUzf4WUIWFxjqGp8+6Iqkj8Ad jX2r/rfREu7htg== X-Google-Smtp-Source: ADKCNb6hm9m5zwbV6CApzylGU0pO5zJqHuYPeN6p57/n4iROeVoAb8kOsLFJtKvpn/s3mH3yI6VKoA== X-Received: by 10.99.117.88 with SMTP id f24mr5075232pgn.453.1504636652251; Tue, 05 Sep 2017 11:37:32 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id n29sm1597612pgf.76.2017.09.05.11.37.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 11:37:31 -0700 (PDT) From: Michael Koster Message-Id: <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E7C433B6-7D23-40A2-B22F-0455F6B12404" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 5 Sep 2017 11:37:30 -0700 In-Reply-To: Cc: Jim Schaad , "draft-ietf-core-resource-directory@ietf.org" , core@ietf.org To: consultancy@vanderstok.org References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 05 Sep 2017 18:37:35 -0000 --Apple-Mail=_E7C433B6-7D23-40A2-B22F-0455F6B12404 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Peter, The representation on slide 4 is not a complete dump, but exactly what = you say; it's the locations and the registration parameters, exposed as = link target attributes. The example has one "self" link for the RD itself, and one link for each = registration resource (only one is shown). [ { "href": "/registration/", "rel": "self", "rt": "core.rd", "ct": 40 }, { "href": "/registration/f3cca57e/", "con": "coap://[fdfd::12]:17072" "rt": "core.rd-endpoint", "ct": 40, "ep": "example-endpoint-name", "et": "ocf-device", "lt": 600, "d": "floor-3" } ] > On Sep 4, 2017, at 11:37 PM, peter van der Stok = wrote: >=20 > Hi Michael, >=20 > Originally, I thought the same, but the packets get really large by = doing a complete dump. > The compromise is just sending the (endpoint names/ registration = resource location) with its registration attributes. >=20 > Peter >=20 >=20 > Michael Koster schreef op 2017-09-05 08:27: >> I would propose returning links for all registration resources in the >> RD as shown in slide 4 of the attached deck (JSON format shown). This >> would include the most recent setting of the "lt" or lifetime >> parameter as a link target attribute as shown. >>> On Sep 4, 2017, at 8:27 AM, Jim Schaad = wrote: >>> Yes that is what I had in mind. It would be useful to add a ttl = attribute >>> as well. >>> Jim >>>> -----Original Message----- >>>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>>> Sent: Monday, September 4, 2017 1:46 AM >>>> To: Jim Schaad >>>> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org >>>> Subject: Re: draft-ietf-core-resource-directory =3D GET /rd >>>> Hi Jim, >>>> Personally, I like the idea. >>>> That would mean that all registration resources are returned. >>>> In the next version of the RD, location or endpoint identifies the >>> registration. >>>> Uniqueness of links is specified in section 5.3.4, already = commented on by >>>> you. >>>> Your request means returning all locations with the ep, lt, d, and = et >>> attributes >>>> and the associated scheme://authority:port value. >>>> Correct? >>>> Peter >>>> Jim Schaad schreef op 2017-08-31 03:59: >>>>> I am wondering if there should be a GET action defined against the >>>>> resource directory object. Currently, if an entity does a >>>>> registration for an endpoint it gets back a location for that >>>>> registration. If a second entity modifies the endpoint and wants = to >>>>> update the registration, it currently has no method to get the >>>>> location associated with the endpoint and cannot make a second new >>>>> registration since the pair is required to be >>>>> unique. >>>>> Thus >>>>> Interaction: EP -> RD >>>>> Method: GET >>>>> URI Template: {+rd}{?ep,d} >>>>> Content-Format: application/link-format (or variants) >>>>> ;ep=3Dendpoint1,;ep=3Dendpoint1;domain=3Dbeta, = ... >>>>> Jim >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_E7C433B6-7D23-40A2-B22F-0455F6B12404 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Peter,

The representation on slide 4 is not a complete dump, but = exactly what you say; it's the locations and the registration = parameters, exposed as link target attributes.

The example has one "self" link for the = RD itself, and one link for each registration resource (only one is = shown).

[
  {
    "href": = "/registration/",
    "rel": "self",
    "rt": = "core.rd",
    = "ct": 40
  = },
  = {
    = "href": "/registration/f3cca57e/",
    "con": = "coap://[fdfd::12]:17072"
    "rt": "core.rd-endpoint",
    "ct": = 40,
    = "ep": "example-endpoint-name",
    "et": "ocf-device",
    "lt": = 600,
    = "d": "floor-3"
  = }
]


On Sep 4, 2017, at 11:37 PM, peter van der Stok <stokcons@xs4all.nl> = wrote:

Hi Michael,

Originally, I = thought the same, but the packets get really large by doing a complete = dump.
The compromise is just sending the (endpoint names/ = registration resource location) with its registration attributes.

Peter


Michael Koster schreef op 2017-09-05 08:27:
I would propose = returning links for all registration resources in the
RD = as shown in slide 4 of the attached deck (JSON format shown). This
would include the most recent setting of the "lt" or = lifetime
parameter as a link target attribute as shown.
On Sep 4, 2017, at 8:27 = AM, Jim Schaad <ietf@augustcellars.com> wrote:
Yes that = is what I had in mind.  It would be useful to add a ttl = attribute
as well.
Jim
-----Original = Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl]
Sent: Monday, = September 4, 2017 1:46 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org
Subject: Re: draft-ietf-core-resource-directory =3D GET = /rd
Hi Jim,
Personally, I like the idea.
That would mean that all registration resources are = returned.
In the next version of the RD, location or = endpoint identifies the
registration.
Uniqueness of links is = specified in section 5.3.4, already commented on by
you.
Your request means returning all locations with the ep, lt, = d, and et
attributes
and the associated scheme://authority:port = value.
Correct?
Peter
Jim = Schaad schreef op 2017-08-31 03:59:
I am wondering if there should be a GET action = defined against the
resource directory object. =  Currently, if an entity does a
registration for an = endpoint it gets back a location for that
registration. =  If a second entity modifies the endpoint and wants to
update the registration, it currently has no method to get = the
location associated with the endpoint and cannot make = a second new
registration since the <domain, = endpoint> pair is required to be
unique.
Thus
Interaction: EP -> RD
Method: GET
URI Template: {+rd}{?ep,d}
Content-Format: application/link-format (or variants)
<rd/0099>;ep=3Dendpoint1,<rd/0098>;ep=3Dendpoint1;d= omain=3Dbeta, ...
Jim
_____________________________________= __________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_E7C433B6-7D23-40A2-B22F-0455F6B12404-- From nobody Tue Sep 5 15:14:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBC21320CF; Tue, 5 Sep 2017 15:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 v2hfEHV4h3SJ; Tue, 5 Sep 2017 15:14:29 -0700 (PDT) Received: from mail4.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 ECA3A132076; Tue, 5 Sep 2017 15:14:28 -0700 (PDT) Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504649629; h=from:subject:to:date:message-id; bh=QL4vmFuAvhS0QHU9kwfwYtw4Uu6B91/CgXy5VqMz5Nw=; b=KcAOJD52qvPokygmhrPRqsY66sc+gpXMvyUhkiblcIGSfM1IHCPu+nTiT6wSsml5wUxDK3Npk5u cA43QQYseZkkkfzeUapyTo91+HxtMr/AxH4lrtyUN18BRl8Wv+/of2/AkgD2XAReOmttPmmKT+gZH YYlMvS46SqzSjZSZ1EoH9Nwa1Qp7KhVd40JRZmGNxxHBM3jkAseubx4OAeAr0ujxhq0XRMgkwnhx5 eFHao8FJI+e+PNsLyLlY21fFUddh7laqsRPx8yDQYlbPEB4QJIda/M892RIKdUQuhz+HnJzbU/h9y Z+BIO25MgT508d5n3719FoPd33aeV6Vg4rig== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 5 Sep 2017 15:13:49 -0700 Received: from Hebrews (100.46.251.223) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 5 Sep 2017 15:13:44 -0700 From: Jim Schaad To: CC: Date: Tue, 5 Sep 2017 15:14:16 -0700 Message-ID: <007801d32694$51c49790$f54dc6b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMmk6dW81pdiJqPSXWDaAjV6O6d9Q== X-Originating-IP: [100.46.251.223] Archived-At: Subject: [core] My endpoint has two addresses 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, 05 Sep 2017 22:14:30 -0000 One of the issues that I just come up with, and might be part of an I don't care space, is that if an endpoint has two different addresses then the registration resource cannot have two different addresses associated with it. You cannot have two different registration resources with the same endpoint name. This means if I want to register both IPv6 and IPv4 (or other address types) with the same endpoint there is a problem. I also just realized that same issue arises with schema. These only apply if you want to use the context parameter. If you are going to supply full URL addresses to resources then this is doable. Given that the context parameter is for space savings, I wonder if some method of dealing with this should be considered. Possibly defining some type of context selector or something? Jim From nobody Tue Sep 5 18:12:47 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6B2132E44; Tue, 5 Sep 2017 18:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 mT9BLXXJp6ov; Tue, 5 Sep 2017 18:12:44 -0700 (PDT) Received: from mail4.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 99D92132E41; Tue, 5 Sep 2017 18:12:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01D32672.8C4A8EA0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504660325; h=from:subject:to:date:message-id; bh=mSQ5hD1LSf6AG86sa8EI4FAbspUIZHDF/WcTrMAGCXQ=; b=RKx/uFrKeRyLMX7wn4ZYhQ417gohVxc2FkgvaU2ym8IgRJRlxcMIMkNCZM/Dt+9xyAXBI6eTu0M tf34CVMjQ3g9HyiRvUp/xzpkTHkVYoyqCSStcYXdBjjQ4VPLJCCXN5iWN+VpgoeCAGKPStt1rEwel IyVkuNoGN4uaEbhqnqn9QkHEScFqYcnHEKmUJtknMts8ckgVCiv+tq5YQQ4h1ywCKw0X1SJr5Kx7B ApGrWrRYwWSXO0+Qu3NvRwuVYAh5NKrPMwnwlkCO12Pgmr909zCviaMpaLAZrd9o5gjT9h1XOka73 vLWfEWmpIz5GE861YO4BqeDU5K520jQq74aA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 5 Sep 2017 18:12:03 -0700 Received: from Hebrews (100.46.251.223) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 5 Sep 2017 18:11:58 -0700 From: Jim Schaad To: 'Michael Koster' , CC: , References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> In-Reply-To: <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> Date: Tue, 5 Sep 2017 18:12:31 -0700 Message-ID: <008501d326ad$38a547f0$a9efd7d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHzp22oYH48fdIyaCnjuMXhFqY5SQImotPEApgot3wBZ0C9FALgZUpwAhaoYvKiDSH6gA== X-Originating-IP: [100.46.251.223] Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 06 Sep 2017 01:12:46 -0000 ------=_NextPart_000_0086_01D32672.8C4A8EA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think that Michael and I are saying the same thing in terms of what the "content" of the resource is. I am not sure that I think that having the "self" node in the registration is useful, but that would be a different issue. Jim From: Michael Koster [mailto:michaeljohnkoster@gmail.com] Sent: Tuesday, September 5, 2017 11:38 AM To: consultancy@vanderstok.org Cc: Jim Schaad ; draft-ietf-core-resource-directory@ietf.org; core@ietf.org Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd Hi Peter, The representation on slide 4 is not a complete dump, but exactly what you say; it's the locations and the registration parameters, exposed as link target attributes. The example has one "self" link for the RD itself, and one link for each registration resource (only one is shown). [ { "href": "/registration/", "rel": "self", "rt": "core.rd", "ct": 40 }, { "href": "/registration/f3cca57e/", "con": "coap://[fdfd::12]:17072" "rt": "core.rd-endpoint", "ct": 40, "ep": "example-endpoint-name", "et": "ocf-device", "lt": 600, "d": "floor-3" } ] On Sep 4, 2017, at 11:37 PM, peter van der Stok > wrote: Hi Michael, Originally, I thought the same, but the packets get really large by doing a complete dump. The compromise is just sending the (endpoint names/ registration resource location) with its registration attributes. Peter Michael Koster schreef op 2017-09-05 08:27: I would propose returning links for all registration resources in the RD as shown in slide 4 of the attached deck (JSON format shown). This would include the most recent setting of the "lt" or lifetime parameter as a link target attribute as shown. On Sep 4, 2017, at 8:27 AM, Jim Schaad > wrote: Yes that is what I had in mind. It would be useful to add a ttl attribute as well. Jim -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: Monday, September 4, 2017 1:46 AM To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org ; core@ietf.org Subject: Re: draft-ietf-core-resource-directory = GET /rd Hi Jim, Personally, I like the idea. That would mean that all registration resources are returned. In the next version of the RD, location or endpoint identifies the registration. Uniqueness of links is specified in section 5.3.4, already commented on by you. Your request means returning all locations with the ep, lt, d, and et attributes and the associated scheme://authority:port value. Correct? Peter Jim Schaad schreef op 2017-08-31 03:59: I am wondering if there should be a GET action defined against the resource directory object. Currently, if an entity does a registration for an endpoint it gets back a location for that registration. If a second entity modifies the endpoint and wants to update the registration, it currently has no method to get the location associated with the endpoint and cannot make a second new registration since the pair is required to be unique. Thus Interaction: EP -> RD Method: GET URI Template: {+rd}{?ep,d} Content-Format: application/link-format (or variants) ;ep=endpoint1,;ep=endpoint1;domain=beta, ... Jim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0086_01D32672.8C4A8EA0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I think = that Michael and I are saying the same thing in terms of what the = “content” of the resource is. 

 

I am not = sure that I think that having the “self” node in the = registration is useful, but that would be a different = issue.

 

Jim

 

 

From: = Michael Koster [mailto:michaeljohnkoster@gmail.com]
Sent: = Tuesday, September 5, 2017 11:38 AM
To: = consultancy@vanderstok.org
Cc: Jim Schaad = <ietf@augustcellars.com>; = draft-ietf-core-resource-directory@ietf.org; = core@ietf.org
Subject: Re: [core] = draft-ietf-core-resource-directory =3D GET = /rd

 

Hi = Peter,

 

The representation on slide 4 is not a complete dump, = but exactly what you say; it's the locations and the registration = parameters, exposed as link target = attributes.

 

The example has one "self" link for the RD = itself, and one link for each registration resource (only one is = shown).

 

[

  = {

    "href": = "/registration/",

    = "rel": "self",

    = "rt": "core.rd",

    = "ct": 40

  = },

  = {

    "href": = "/registration/f3cca57e/",

    = "con": = "coap://[fdfd::12]:17072"

    = "rt": = "core.rd-endpoint",

    = "ct": 40,

    = "ep": = "example-endpoint-name",

    = "et": = "ocf-device",

    = "lt": 600,

    = "d": "floor-3"

  = }

]

 

 

On Sep 4, 2017, at 11:37 PM, peter van der Stok <stokcons@xs4all.nl> = wrote:

 

Hi = Michael,

Originally, I thought the same, but the packets get = really large by doing a complete dump.
The compromise is just sending = the (endpoint names/ registration resource location) with its = registration attributes.

Peter


Michael Koster schreef = op 2017-09-05 08:27:

I = would propose returning links for all registration resources in = the
RD as shown in slide 4 of the attached deck (JSON format shown). = This
would include the most recent setting of the "lt" or = lifetime
parameter as a link target attribute as = shown.

On = Sep 4, 2017, at 8:27 AM, Jim Schaad <ietf@augustcellars.com> = wrote:
Yes that is what I had in mind.  It would be useful to = add a ttl attribute
as well.
Jim

-----Original Message-----
From: peter van der Stok = [mailto:stokcons@xs4all.nl]
Sent= : Monday, September 4, 2017 1:46 AM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: draft-ietf-co= re-resource-directory@ietf.org; core@ietf.org
Subject: Re: = draft-ietf-core-resource-directory =3D GET /rd
Hi Jim,
Personally, = I like the idea.
That would mean that all registration resources are = returned.
In the next version of the RD, location or endpoint = identifies the

registration.

Uniqueness of links is specified in section 5.3.4, = already commented on by
you.
Your request means returning all = locations with the ep, lt, d, and et

attributes

and = the associated scheme://authority:port = value.
Correct?
Peter
Jim Schaad schreef op 2017-08-31 = 03:59:

I am = wondering if there should be a GET action defined against = the
resource directory object.  Currently, if an entity does = a
registration for an endpoint it gets back a location for = that
registration.  If a second entity modifies the endpoint and = wants to
update the registration, it currently has no method to get = the
location associated with the endpoint and cannot make a second = new
registration since the <domain, endpoint> pair is required = to be
unique.
Thus
Interaction: EP -> RD
Method: = GET
URI Template: {+rd}{?ep,d}
Content-Format: = application/link-format (or = variants)
<rd/0099>;ep=3Dendpoint1,<rd/0098>;ep=3Dendpoint= 1;domain=3Dbeta, ...
Jim

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

<= /div>

 

------=_NextPart_000_0086_01D32672.8C4A8EA0-- From nobody Tue Sep 5 20:55:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B8E13218E; Tue, 5 Sep 2017 20:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 hYQ_Hn7h-YMr; Tue, 5 Sep 2017 20:54:58 -0700 (PDT) Received: from mail4.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 CF99D1321A4; Tue, 5 Sep 2017 20:54:58 -0700 (PDT) Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504670056; h=from:subject:to:date:message-id; bh=PUc4hWLUrFGhMy0YzDwW6qOGNEKu1vm2hdYakWgjWgg=; b=YcKstfezENQyom+xRe+Ko/rTYiyfcXa4HRT+C4ZY4ZPQAlif9DAivC25I6dMfjqRK2gKVho8pmO nnjg12x5ydTshHXvFvGwCgd2lqZn7On5+TrzyD7FM/OhWPxREyJnWFqe7TXeYAADx9MO2vWzf97/9 xyz3HnrVOTLpIVGW1tjffe2EuPGxwRueREbF1OV3S/T9S3TfaUBHIxcIttZ+NLZPK0oBvoL5lRLTn v8bby5ljVR2Ymhqr1AGY/+gkKUgLMK+9YQfuRd55PM6iJEIP6dAszM9NKK+Cxyj84Ta45KB8Rwzre 4dv6fATrY1Y2Ep7NMzEpYIAPBL8wNzJhhLHQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 5 Sep 2017 20:54:15 -0700 Received: from Hebrews (100.46.251.223) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 5 Sep 2017 20:54:11 -0700 From: Jim Schaad To: CC: Date: Tue, 5 Sep 2017 20:54:42 -0700 Message-ID: <009501d326c3$e1058570$a3109050$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMmwIXFbHhlCWIUQQWTuMDOzoWf3w== X-Originating-IP: [100.46.251.223] Archived-At: Subject: [core] Resource Directory - Patch 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, 06 Sep 2017 03:55:00 -0000 Somewhere during the day today I had a major paradigm shift in my thinking about how PATCH was supposed to work and a great deal of what is written in the document suddenly became much clearer. I was operating under the mistaken impression that the "document" that was being patched was the same for the add, change and delete cases and it is not. The add case is operating on the array of registration elements while the change and delete cases are operating on individual registration elements. With that shift in how things work the different patch examples became much easier to follow. So, with this new understanding I am going to try some different questions about PATCH. 1. Is there a good reason to support the addition of new resources in two different methods? Addition of new resources can already be done through the POST method, needing to recognize that the documents to be patched are different is a potential error waiting to happen if this is not well described in document. 2. For the delete case, the patch string of {"href":null} is more in line with how I understand a JSON patch document to be designed. The string of {} would say that nothing is to be changed by default unless it is special cased. Setting the value of the href to absent or null would be easily understood as saying remove the element. 3. The text on patch needs to be clear on how to treat a patch document where multiple occurrences of an attribute to modify occur in the patch document. It should also be clearer on the correct way to deal with updating multiple occurrences of the attribute in the link document. My reading of the current text could end up with ";alpha=beta;alpha=beta" as the output if the input was ";alpha=gamma;alpha=delta" and the patch was {alpha:"beta"}. I am not sure that is what you want to be saying. 4. This paragraph is missing some text I believe: If the PATCH payload results in the modification of link target, context, or relation values, that is "href", "rel", or "anchor", the request SHOULD be rejected with a "Conflict" result code. Why is this a SHOULD and not a MUST. If you keep it as a MUST some guidance on which rejections SHOULD occur and when they are acceptable would be highly desirable. Making it a MUST means that a Conflict response would not be able to occur if I have my logic correct for anything other than an addition request. Jim From nobody Thu Sep 7 07:43:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF0C132F2D for ; Thu, 7 Sep 2017 07:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=landisgyr.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 PkYSi-EL5pRm for ; Thu, 7 Sep 2017 07:43:00 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0094.outbound.protection.outlook.com [104.47.2.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 89D54132F1B for ; Thu, 7 Sep 2017 07:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=LandisGyr.onmicrosoft.com; s=selector1-landisgyr-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MnoaoLQ/SLn0HfrX8YdUzbjWyZpF/RnBbdTYQxfTXVQ=; b=NPCV/0dHGSJIsqs8GgYySe3rC1u1UZOcMF2C/ZGcFBCG1FFRfgCR4leLFcdtCnEDJzc7rjk8kCw1t1VBIqCCaWI56lE/D1vBQn5EhswJnI7gO1rQ0qRkeh3oi3SIS2x7KbwCYSUeKfFoRSBi1W9I7GxrfqWUkV2gKP7BOJVQPN0= Received: from AM0PR0102MB3298.eurprd01.prod.exchangelabs.com (52.133.44.27) by AM0PR0102MB3250.eurprd01.prod.exchangelabs.com (52.133.44.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Thu, 7 Sep 2017 14:42:57 +0000 Received: from AM0PR0102MB3298.eurprd01.prod.exchangelabs.com ([fe80::70ad:8e59:d57f:c838]) by AM0PR0102MB3298.eurprd01.prod.exchangelabs.com ([fe80::70ad:8e59:d57f:c838%13]) with mapi id 15.20.0035.010; Thu, 7 Sep 2017 14:42:57 +0000 From: "Turner, Randy" To: "core@ietf.org WG (core@ietf.org)" Thread-Topic: draft-ietf-core-resource-directory-11 Thread-Index: AdMn5usi+ktt4vwxSXa1Gv8XaSMrPA== Date: Thu, 7 Sep 2017 14:42:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.216] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0102MB3250; 6:Zo6nyBpnn7XVOCN5TmH4Uw5k9oDuDAfldPdN85ryGqIq1QejFmcNy7ww5RBUVMfCZed9eKNt1cLqPrpD9iMe3ggIBT8Qk/w6xSI3eHQnQ2I2ENekTJyj/B8jZtckWflWp8uTJzMuzVzAbMrCIuQqHu9MRlYO1kK++ogEe0iS2au1JC0UGQVn/RosTsvi63zXcxBRv0qT21cjlWkd+E+tn6j5r+Tk3s7mOlgdaywwrtMiZ0YM1hrXVwwd17kf9x2R5P9HZc3mU3UMW/Tdc1yAQZyzVy1I2NtfsyXKczrq3IhgE9BS74zy6511xYrTZOXQ5qNmiIQkaNvkxwl0OtyR6A==; 5:JWTpJzCWEzlbof0HbYIMT9rarjZwopHMAJyf/4sbMD09Q0rZxPQ/WxDFifKdUX8eJdKl9ksgN+un1YWAOjpuGt4UsmA2Z8bKDX6dThkH7T3V6Cm/pr+i0hS8dYPq76RgtEI8grsFuwIoOeb2GNg9sg==; 24:HhP6tPSfC4rPaSU8BdJ+/RhtYrRylvD7v6AQ8tuVUJu5J3CbXhjxetFoPiQRHQZmxpeFwrvpN1TwcshU73hZapim5z8DgDu5bXexC4IX0X4=; 7:J9mdLmioyaKpf9AxVZnA2SVFrQMhamHYNVkC17+M3yb5oFoTKt3Sf79vaR3nmtzTND1CT4gMcGij7MQfjRbxoQWrkrZpbneqfAV5zwJyyjShN4s9Pz70DdjeWxELcR+OJ88xsLZAYeML2LKaMitv3gM58ypwx5wo6GUV9Cj+w/VFZtUVNRSaosrujFs1nQxcla2TFIEoP5XIDc9Wc+5h2X5umyjgJHuHXuaFbYuO1q8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0a2ae9cd-dcc6-455f-9759-08d4f5febb17 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM0PR0102MB3250; x-ms-traffictypediagnostic: AM0PR0102MB3250: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM0PR0102MB3250; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM0PR0102MB3250; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(53754006)(86362001)(6506006)(5250100002)(110136004)(5660300001)(6436002)(7696004)(72206003)(53936002)(2906002)(66066001)(189998001)(478600001)(6916009)(74316002)(8676002)(81156014)(81166006)(8936002)(2900100001)(14454004)(230783001)(9326002)(3280700002)(102836003)(25786009)(9686003)(50986999)(97736004)(101416001)(3846002)(54896002)(790700001)(6306002)(54356999)(6116002)(99286003)(7736002)(3660700001)(33656002)(55016002)(68736007)(105586002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0102MB3250; H:AM0PR0102MB3298.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR0102MB329876D3929A836D752BA58880940AM0PR0102MB3298_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 14:42:57.4685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0102MB3250 Archived-At: Subject: [core] draft-ietf-core-resource-directory-11 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, 07 Sep 2017 14:43:02 -0000 --_000_AM0PR0102MB329876D3929A836D752BA58880940AM0PR0102MB3298_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, There is text in section 3.1 "Principles" of the RD draft that says... ...snip..."it follows that no information should be stored in the resource directory that cannot be discovered from querying the described device's /.well-known/core resource directly." This seems counter to the text in section 1 "Introduction", which says... ...snip..."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." Could the text in 3.1 be re-stated differently? Randy --_000_AM0PR0102MB329876D3929A836D752BA58880940AM0PR0102MB3298_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

There is text in section 3.1 “Principles”= ; of the RD draft that says…

 

   …snip…”it follows tha= t no information should be stored in the

   resource directory that cannot be disco= vered from querying the

   described device's /.well-known/core re= source directly.”

 

This seems counter to the text in section 1 “I= ntroduction”, which says…

 

…snip…”These problems can be solve= d by employing an

   entity called a Resource Directory (RD)= , which hosts descriptions of

   resources held on other servers, allowi= ng lookups to be performed for

   those resources.”

 

Could the text in 3.1 be re-stated differently?=

 

Randy

--_000_AM0PR0102MB329876D3929A836D752BA58880940AM0PR0102MB3298_-- From nobody Thu Sep 7 08:39:55 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66050132C3F for ; Thu, 7 Sep 2017 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gVc867x7Pzw0 for ; Thu, 7 Sep 2017 08:39:52 -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 47DB913219F for ; Thu, 7 Sep 2017 08:39:52 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-5d-59b16846a7e2 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.96.22436.64861B95; Thu, 7 Sep 2017 17:39:50 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.26]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 17:39:50 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "Turner, Randy" CC: "core@ietf.org WG (core@ietf.org)" , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: [core] draft-ietf-core-resource-directory-11 Thread-Index: AdMn5usi+ktt4vwxSXa1Gv8XaSMrPP//77wA Date: Thu, 7 Sep 2017 15:39:49 +0000 Message-ID: <47A0180A-ADE1-4CA5-B95C-E87D7410EFF0@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/signed; boundary="Apple-Mail=_53C44F1C-247D-4C50-B858-4FAFF0EDA761"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsUyM2K7ma5bxsZIg3fvVSyWX3jOYrHv7Xpm i93H2tgdmD227r/L5LFkyU8mj4WTprMEMEdx2aSk5mSWpRbp2yVwZVy9uJu5YHVtxYKTi1gb GHcXdTFyckgImEjcfD6XqYuRi0NI4AijxIof/5khnEWMEtvmX2EHqWITcJb49KwRzBYRMJBY /XsqkM3BwSxQJzFzkQdIWFjAUuLWzH5GkLCIgJXEqhYmiGojiTO9y1lBbBYBFYkHv1qYQWxe AXuJjesusIHYQgKpEvt27gCr4RRIk9h8diNYL6OAmMT3U2vAbGYBcYlbT+YzQdwsIvHw4mk2 CFtU4uXjf6wQtqLEzrPtYOczC0xhlNj7/hoTxDJBiZMzn7BMYBSZhWTWLGR1s5DUQRQlSXw4 3cAOYWtLLFv4mhnC1pTY372cBVNcQ6Lz20RWCNtU4vXRj4wQtrXEjF8H2SBsRYkp3Q/ZFzBy r2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjOaDW37r7mBc/drxEKMAB6MSD++kgI2RQqyJ ZcWVuYcYVYDmPNqw+gKjFEtefl6qkgjvnGSgNG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRci hATSE0tSs1NTC1KLYLJMHJxSDYxq1SuNwp6fsDP2EPqecefv3O4TVmucHH5V9r0xXKOzcaMd 91Ut9TwpAaXfk078XmHwLiDD3vWDwHX+mQtvXznxMqXd9/OV3wbKN/YeOr70459pmw/OufR0 0Y8leXNycxUf7FWw+DjrWqbE2fN3p7D0qoV/+vrviOCk5Kyb7m3adR+CLr3xqy1QV2Ipzkg0 1GIuKk4EAM0IYxHuAgAA Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory-11 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, 07 Sep 2017 15:39:54 -0000 --Apple-Mail=_53C44F1C-247D-4C50-B858-4FAFF0EDA761 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB02ABE1-16DC-40BD-85ED-AC8DAC7CD636" --Apple-Mail=_FB02ABE1-16DC-40BD-85ED-AC8DAC7CD636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Randy, Resource descriptions are links to the endpoints actually hosting the = resources and providing the data.=20 So the text is correct, the RD is not providing data directly. Maybe = that text can be clarified in the next version.=20 I=E2=80=99ll added to the issue tracker for discussion: = https://github.com/core-wg/resource-directory/issues = =20 Ciao! - - Jaime Jim=C3=A9nez > On 7 Sep 2017, at 17.42, Turner, Randy = wrote: >=20 > Hi All, > =20 > There is text in section 3.1 =E2=80=9CPrinciples=E2=80=9D of the RD = draft that says=E2=80=A6 > =20 > =E2=80=A6snip=E2=80=A6=E2=80=9Dit follows that no information = should be stored in the > resource directory that cannot be discovered from querying the > described device's /.well-known/core resource directly.=E2=80=9D > =20 > This seems counter to the text in section 1 =E2=80=9CIntroduction=E2=80=9D= , which says=E2=80=A6 > =20 > =E2=80=A6snip=E2=80=A6=E2=80=9DThese 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.=E2=80=9D > =20 > Could the text in 3.1 be re-stated differently? > =20 > Randy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_FB02ABE1-16DC-40BD-85ED-AC8DAC7CD636 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Randy,

Resource descriptions are links to the endpoints actually = hosting the resources and providing the data. 
So the text is correct, the RD is not providing data = directly.  Maybe that text can be clarified in the next = version. 
I=E2=80=99ll added to the issue = tracker for discussion: https://github.com/core-wg/resource-directory/issues <= /div>

Ciao!
- - Jaime Jim=C3=A9nez

On 7 Sep 2017, at 17.42, Turner, Randy <Randy.Turner@landisgyr.com> wrote:

Hi All,
 
There is text in section 3.1 =E2=80=9CPrinciples=E2=80=9D of = the RD draft that says=E2=80=A6
 
   =E2=80=A6snip=E2=80=A6=E2=80= =9Dit follows that no information should be stored in the
   resource directory that cannot be discovered = from querying the
   described device's /.well-known/core resource = directly.=E2=80=9D
 
This seems counter to the text in section 1 = =E2=80=9CIntroduction=E2=80=9D, which says=E2=80=A6
 
=E2=80=A6snip=E2=80=A6=E2=80=9DThese 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.=E2=80=9D
 
Could the = text in 3.1 be re-stated differently?
 
Randy
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_FB02ABE1-16DC-40BD-85ED-AC8DAC7CD636-- --Apple-Mail=_53C44F1C-247D-4C50-B858-4FAFF0EDA761 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA5MDcxNTM5NTRaMCMGCSqGSIb3DQEJBDEWBBTJ 2zJK6FjCKwQfggAYguLHkHkfujBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQC1n4LeEgf0LuS89BUdTf056VDjREfr7BZ8PT78PYAix4ZIfWA+rpG2i+me3cS5FR7XUCPaXhaV oqBpd4tkt5Sb2gHIj7dpte7tf38dVWuk+dCRoJSrgfMNTmG5TaFg1pXZoC69VyMxOUsQsuav19F6 4e0xq7ae0JqroGP4exqXxp4dxRuvqwwH5CH9OeUBJlvtUMUa7SHtUFyblQBgXPzpl3zaMjPQXIg5 X00MJ7Dkyno8bmwQmLDvM048RGLW+yMs8WmfXNL92TBLUn5zgNr+v5vI+tbjp0nRgA0fpeDcP8lm Of6mc55l4Qc5/njmcD02EVwJGwomb7v2zSZKnX5vAAAAAAAA --Apple-Mail=_53C44F1C-247D-4C50-B858-4FAFF0EDA761-- From nobody Fri Sep 8 00:13:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3E8133131 for ; Fri, 8 Sep 2017 00:13:01 -0700 (PDT) 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 yssoUugWuoSq for ; Fri, 8 Sep 2017 00:12:59 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC64133130 for ; Fri, 8 Sep 2017 00:12:58 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud8.xs4all.net with ESMTPA id qDTCd2ThJcQyLqDTCddymF; Fri, 08 Sep 2017 09:12:56 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 08 Sep 2017 09:12:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 08 Sep 2017 09:12:54 +0200 From: peter van der Stok To: "Turner, Randy" Cc: "core@ietf.org WG (core@ietf.org)" Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfONwKeyFU6ehBZjAAfXV1anh/oW3EK1AG1bYs02jnf5ewFiN0k2CgsPccXJu4ou/z6kkHcSW7c6ISDpuMf2dzU6LkiZG0DihoF16hLqBm1gY6KsO9PMo k+Xsd3vvsAnHat9wUew5s3z2VuY8raf1C+i0F2yeqedEeEckpMFegrXsT0aZrAGUFZIw1bMI0Y93U/sf4qRXtKYbGyDjPZ4rYiWcWoFBXfgev28Xpj7FC6ho Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory-11 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, 08 Sep 2017 07:13:01 -0000 Hi Randy, You are right, there are some hidden assumptions in 3.1. Rephrasing seems the best way forward. tanks, Peter Turner, Randy schreef op 2017-09-07 16:42: > Hi All, > > There is text in section 3.1 "Principles" of the RD draft that says… > > > …snip…"it follows that no information should be stored in the > > resource directory that cannot be discovered from querying the > > described device's /.well-known/core resource directly." > > This seems counter to the text in section 1 "Introduction", which > says… > > …snip…"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." > > Could the text in 3.1 be re-stated differently? > > Randy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 8 00:25:32 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA083132FDC; Fri, 8 Sep 2017 00:25:29 -0700 (PDT) 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 zPnqRH3__rF6; Fri, 8 Sep 2017 00:25:27 -0700 (PDT) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 7DEF313219A; Fri, 8 Sep 2017 00:25:27 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud8.xs4all.net with ESMTPA id qDfJd2aHycQyLqDfJde2Ta; Fri, 08 Sep 2017 09:25:25 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 08 Sep 2017 09:25:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Sep 2017 09:25:25 +0200 From: peter van der Stok To: Michael Koster Cc: consultancy@vanderstok.org, Jim Schaad , draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfM+jGErSk63OvHJw3zI3731h0FQCVlROW5L2CFxlMKdZTEgiVMCBfENoWI8bBiKe2yTgCnAuXWmI9NvY3+q9n4MTJnoHVCpAt+QP74NMjerqJ+q5hrBS o4bF6mlkOrkrlh+cSco0P1Pgbxz6+QWvZ3qLG6hu+uroQ3GP9KcpRNlT4MVZi3Lgo2sXUG9wqwWkrbG2BSXMTqAB8uobxgywRnvSAyEK0Lq6zBzVC0bgbKX1 KiFK4p8lfN9WCAi5TNVfxPjoHDHaqSrvA2rtB+GjyWcEP5Iz5KV8ZocK12I4nKyY Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 08 Sep 2017 07:25:30 -0000 Hi Michael, I would have expected: [ { "con": "coap://[fdfd::12]:17072", "loc" : "/rd/541", "ep": "example-endpoint-name", "et": "ocf-device", "lt": 600, "d": "floor-3" } ] and may be only ep and loc attributes; With this information the rest of the link information can be inferred. cheerio, Peter Michael Koster schreef op 2017-09-05 20:37: > Hi Peter, > > The representation on slide 4 is not a complete dump, but exactly what > you say; it's the locations and the registration parameters, exposed > as link target attributes. > > The example has one "self" link for the RD itself, and one link for > each registration resource (only one is shown). > > [ > { > "href": "/registration/", > "rel": "self", > "rt": "core.rd", > "ct": 40 > }, > { > "href": "/registration/f3cca57e/", > "con": "coap://[fdfd::12]:17072" > "rt": "core.rd-endpoint", > "ct": 40, > "ep": "example-endpoint-name", > "et": "ocf-device", > "lt": 600, > "d": "floor-3" > } > ] > >> On Sep 4, 2017, at 11:37 PM, peter van der Stok >> wrote: >> >> Hi Michael, >> >> Originally, I thought the same, but the packets get really large by >> doing a complete dump. >> The compromise is just sending the (endpoint names/ registration >> resource location) with its registration attributes. >> >> Peter >> >> Michael Koster schreef op 2017-09-05 08:27: >> I would propose returning links for all registration resources in >> the >> RD as shown in slide 4 of the attached deck (JSON format shown). >> This >> would include the most recent setting of the "lt" or lifetime >> parameter as a link target attribute as shown. >> On Sep 4, 2017, at 8:27 AM, Jim Schaad >> wrote: >> Yes that is what I had in mind. It would be useful to add a ttl >> attribute >> as well. >> Jim >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Monday, September 4, 2017 1:46 AM >> To: Jim Schaad >> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org >> Subject: Re: draft-ietf-core-resource-directory = GET /rd >> Hi Jim, >> Personally, I like the idea. >> That would mean that all registration resources are returned. >> In the next version of the RD, location or endpoint identifies the >> registration. >> Uniqueness of links is specified in section 5.3.4, already commented >> on by >> you. >> Your request means returning all locations with the ep, lt, d, and >> et >> attributes >> and the associated scheme://authority:port value. >> Correct? >> Peter >> Jim Schaad schreef op 2017-08-31 03:59: >> I am wondering if there should be a GET action defined against the >> resource directory object. Currently, if an entity does a >> registration for an endpoint it gets back a location for that >> registration. If a second entity modifies the endpoint and wants to >> update the registration, it currently has no method to get the >> location associated with the endpoint and cannot make a second new >> registration since the pair is required to be >> unique. >> Thus >> Interaction: EP -> RD >> Method: GET >> URI Template: {+rd}{?ep,d} >> Content-Format: application/link-format (or variants) >> ;ep=endpoint1,;ep=endpoint1;domain=beta, ... >> Jim > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 8 00:28:47 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32562133142; Fri, 8 Sep 2017 00:28:45 -0700 (PDT) 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 hm57FQz8ZxU7; Fri, 8 Sep 2017 00:28:43 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 2DC65133140; Fri, 8 Sep 2017 00:28:43 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud8.xs4all.net with ESMTPA id qDiTd2c4WcQyLqDiTde3Vv; Fri, 08 Sep 2017 09:28:41 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 08 Sep 2017 09:28:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Sep 2017 09:28:41 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <007801d32694$51c49790$f54dc6b0$@augustcellars.com> References: <007801d32694$51c49790$f54dc6b0$@augustcellars.com> Message-ID: <1f46d054a227bdba7dc07e5c22bd1549@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfFVbgnpdA71mmK2+Bk23DsDAuV0EZ5uynRCBDBbNaTiYMZIxQFVQAbzYQdUtesSw5xmmQTPQ544sYsR/vw+Zjw9+IF4ihUUQ2Ojsco/TBYmpWOYsOrrA QoorP/fuLUeyWHEqM+2A4dHRL02QThDcL0edOE+OiFsg/ERtvj7YYRvcJtdHqpSSDw3svuswkSyVCOFmMkYedD/W/Q/Sq0WRoIXFKbxi5Rd82z8bctiu2JkT dQ6J8Uiqtat65HwchF+eWw== Archived-At: Subject: Re: [core] My endpoint has two addresses 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, 08 Sep 2017 07:28:45 -0000 Hi Jim, Indeed this is an issue that was also brought up by Dave Thaler, where he referred to the multiple types of coap schemes that became possible. For the moment, we made the model such that and extension to multiple contexts is possible, but not yet supported by the RD, given that all these extensions are still under discussion, Peter Jim Schaad schreef op 2017-09-06 00:14: > One of the issues that I just come up with, and might be part of an I > don't > care space, is that if an endpoint has two different addresses then the > registration resource cannot have two different addresses associated > with > it. You cannot have two different registration resources with the same > endpoint name. This means if I want to register both IPv6 and IPv4 (or > other address types) with the same endpoint there is a problem. I > also > just realized that same issue arises with schema. These only apply if > you > want to use the context parameter. If you are going to supply full URL > addresses to resources then this is doable. Given that the context > parameter is for space savings, I wonder if some method of dealing with > this > should be considered. Possibly defining some type of context selector > or > something? > > Jim > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 8 01:08:36 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5C4132D8C; Fri, 8 Sep 2017 01:08:34 -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 yx-wB5wbmALy; Fri, 8 Sep 2017 01:08:32 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 BE9711241F3; Fri, 8 Sep 2017 01:08:32 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id t3so1005969pgt.5; Fri, 08 Sep 2017 01:08:32 -0700 (PDT) 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=mfnGqBleC71gbOA+CpvgeRZPJ4DyuUjdPC4h85O0v9g=; b=n4IQdKM7TeSPhPFy3Gh87KbCr15DUIZAKMeBXqsJcJRAVQ/8T5v9TSiJsNkIGx6Hdg VfWSTOfXh1JTgr7sTzyfgoFF7Ok98yE/jgaTvxBq34NPcJUvPALOhLs8TGtxbHVagpoz txlhFXjvvmjxtvKpKmC2BL07Zt9NF0taqMfLD9/081ZQ4a9UIIGOvdd2wZteVTAXrrIx ys9Q404SHGuappP+KBlnWHWybpIIjJ70vH0fxdO1jSVD1iZFa4ftLim4xouqQ6vUUQet nrQV4a4cDVJ4Ai+mOpJNQqYq1Xo8/LobxWamNaiBs47TbeeQlTZVFKOFYODsitjL5ukl cFqA== 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=mfnGqBleC71gbOA+CpvgeRZPJ4DyuUjdPC4h85O0v9g=; b=b5B5sISKtTbCTQwTBuZ/5UkDfms3g7mY1Nqf4/61wRrNI8E/RHAibiSWST9lVSOPmW 5wBLFUdPDPK6bGH8UGplF/vWWfbkjRiQ/vgKCcCOVxGPsP9sU5H2Yd3jni0/eawYRzYg pCuYmn5Igwr+X0nwv8WfnQ2s44EOb9dXzTTRVURwEF+FrsKrBUL2Lh2iF61pTNi3xOrV QD4+7kXjoNUK9g5hSDA2eo29Bj501B1ReaC7DdQDNIbS0rX1yGqJsmlFDqfU7WLZG16z cWJkF6f3JdfYnTtOQfkGM8w3GsKQSMYsMoLkEhCEXnFMZ40MxnO1JZJTjqz7SZPi3cTu zkNA== X-Gm-Message-State: AHPjjUjc3Q7F/nL6spLEmtwBY4TbZrwfLxnHzVTnM97zoEgTZWphEYUb roFxiOuCUM9mT6eMLcQ= X-Google-Smtp-Source: ADKCNb4q+TWBoJAeUCU1KoYz7Qlrk56JKeqO25ST3rQpEopsh1By8+e/VOmN+S4KlS1QhzR9VjHW6A== X-Received: by 10.84.234.197 with SMTP id i5mr2548705plt.184.1504858112193; Fri, 08 Sep 2017 01:08:32 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id s8sm2230558pgf.78.2017.09.08.01.08.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 01:08:31 -0700 (PDT) From: Michael Koster Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A2BA215D-C424-4931-9B68-A9DBB5A08841" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 8 Sep 2017 01:08:29 -0700 In-Reply-To: Cc: Jim Schaad , "draft-ietf-core-resource-directory@ietf.org" , core@ietf.org To: consultancy@vanderstok.org References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 08 Sep 2017 08:08:35 -0000 --Apple-Mail=_A2BA215D-C424-4931-9B68-A9DBB5A08841 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Peter, In your example, "loc" I presume is "location" which is how this is = returned in the response header when the registration resource is = created. In my example, I propose a hyperlink to a resource, so "href" is the = usual key for this in a link JSON. I also propose to include all of the link attributes including rt and = ct, so the client knows what it is without needing to infer anything. So your example would look like this: [ { "href" : "/rd/541", "con": "coap://[fdfd::12]:17072 ", "ep": "example-endpoint-name", "et": "ocf-device", "rt": "core.rd-endpoint", "ct": 40, "lt": 600, "d": "floor-3" } ] > On Sep 8, 2017, at 12:25 AM, peter van der Stok = wrote: >=20 > Hi Michael, >=20 > I would have expected: >=20 > [ > { > "con": "coap://[fdfd::12]:17072", > "loc" : "/rd/541", > "ep": "example-endpoint-name", > "et": "ocf-device", > "lt": 600, > "d": "floor-3" > } > ] >=20 > and may be only ep and loc attributes; > With this information the rest of the link information can be = inferred. >=20 > cheerio, >=20 > Peter >=20 > Michael Koster schreef op 2017-09-05 20:37: >> Hi Peter, >> The representation on slide 4 is not a complete dump, but exactly = what >> you say; it's the locations and the registration parameters, exposed >> as link target attributes. >> The example has one "self" link for the RD itself, and one link for >> each registration resource (only one is shown). >> [ >> { >> "href": "/registration/", >> "rel": "self", >> "rt": "core.rd", >> "ct": 40 >> }, >> { >> "href": "/registration/f3cca57e/", >> "con": "coap://[fdfd::12]:17072" >> "rt": "core.rd-endpoint", >> "ct": 40, >> "ep": "example-endpoint-name", >> "et": "ocf-device", >> "lt": 600, >> "d": "floor-3" >> } >> ] >>> On Sep 4, 2017, at 11:37 PM, peter van der Stok >>> wrote: >>> Hi Michael, >>> Originally, I thought the same, but the packets get really large by >>> doing a complete dump. >>> The compromise is just sending the (endpoint names/ registration >>> resource location) with its registration attributes. >>> Peter >>> Michael Koster schreef op 2017-09-05 08:27: >>> I would propose returning links for all registration resources in >>> the >>> RD as shown in slide 4 of the attached deck (JSON format shown). >>> This >>> would include the most recent setting of the "lt" or lifetime >>> parameter as a link target attribute as shown. >>> On Sep 4, 2017, at 8:27 AM, Jim Schaad >>> wrote: >>> Yes that is what I had in mind. It would be useful to add a ttl >>> attribute >>> as well. >>> Jim >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Monday, September 4, 2017 1:46 AM >>> To: Jim Schaad >>> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org >>> Subject: Re: draft-ietf-core-resource-directory =3D GET /rd >>> Hi Jim, >>> Personally, I like the idea. >>> That would mean that all registration resources are returned. >>> In the next version of the RD, location or endpoint identifies the >>> registration. >>> Uniqueness of links is specified in section 5.3.4, already commented >>> on by >>> you. >>> Your request means returning all locations with the ep, lt, d, and >>> et >>> attributes >>> and the associated scheme://authority:port value. >>> Correct? >>> Peter >>> Jim Schaad schreef op 2017-08-31 03:59: >>> I am wondering if there should be a GET action defined against the >>> resource directory object. Currently, if an entity does a >>> registration for an endpoint it gets back a location for that >>> registration. If a second entity modifies the endpoint and wants to >>> update the registration, it currently has no method to get the >>> location associated with the endpoint and cannot make a second new >>> registration since the pair is required to be >>> unique. >>> Thus >>> Interaction: EP -> RD >>> Method: GET >>> URI Template: {+rd}{?ep,d} >>> Content-Format: application/link-format (or variants) >>> ;ep=3Dendpoint1,;ep=3Dendpoint1;domain=3Dbeta, ... >>> Jim >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_A2BA215D-C424-4931-9B68-A9DBB5A08841 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Peter,

In your example, "loc" I presume is = "location" which is how this is returned in the response header when the = registration resource is created.

In my example, I propose a hyperlink to = a resource, so "href" is the usual key for this in a link = JSON.

I also = propose to include all of the link attributes including rt and ct, so = the client knows what it is without needing to infer anything.


So your example would look like this:

[
  {
    "href" : "/rd/541",
    = "con": "coap://[fdfd::12]:17072",
    = "ep": "example-endpoint-name",
    "et":= "ocf-device",
    "rt": = "core.rd-endpoint",
    "ct": 40,
    "lt": 600,
    "d": "floor-3"
  }
]


On Sep 8, 2017, at 12:25 AM, = peter van der Stok <stokcons@xs4all.nl> wrote:

Hi = Michael,

I would have expected:

[
  {
=     "con": "coap://[fdfd::12]:17072",
=     "loc" : "/rd/541",
=     "ep": "example-endpoint-name",
=     "et": "ocf-device",
=     "lt": 600,
=     "d": "floor-3"
  }
]

and may be only ep and loc = attributes;
With this information the rest of the link = information can be inferred.

cheerio,

Peter

Michael = Koster schreef op 2017-09-05 20:37:
Hi Peter,
The representation on = slide 4 is not a complete dump, but exactly what
you say; = it's the locations and the registration parameters, exposed
as link target attributes.
The example has one = "self" link for the RD itself, and one link for
each = registration resource (only one is shown).
[
=  {
   "href": "/registration/",
   "rel": "self",
=    "rt": "core.rd",
=    "ct": 40
 },
=  {
   "href": = "/registration/f3cca57e/",
   "con": "coap://[fdfd::12]:17072"
=    "rt": "core.rd-endpoint",
=    "ct": 40,
   "ep": = "example-endpoint-name",
   "et": = "ocf-device",
   "lt": 600,
=    "d": "floor-3"
 }
]
On Sep 4, 2017, at = 11:37 PM, peter van der Stok <stokcons@xs4all.nl>
wrote:
Hi Michael,
Originally, I thought the same, but = the packets get really large by
doing a complete dump.
The compromise is just sending the (endpoint names/ = registration
resource location) with its registration = attributes.
Peter
Michael Koster schreef op = 2017-09-05 08:27:
I would propose returning links for all = registration resources in
the
RD as shown in = slide 4 of the attached deck (JSON format shown).
This
would include the most recent setting of the "lt" or = lifetime
parameter as a link target attribute as shown.
On Sep 4, 2017, at 8:27 AM, Jim Schaad <ietf@augustcellars.com>
wrote:
Yes that is what I had in mind.  It would be useful to = add a ttl
attribute
as well.
Jim
-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl]
Sent: Monday, = September 4, 2017 1:46 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org
Subject: Re: draft-ietf-core-resource-directory =3D GET = /rd
Hi Jim,
Personally, I like the idea.
That would mean that all registration resources are = returned.
In the next version of the RD, location or = endpoint identifies the
registration.
Uniqueness of links is specified in section 5.3.4, already = commented
on by
you.
Your = request means returning all locations with the ep, lt, d, and
et
attributes
and the associated = scheme://authority:port= value.
Correct?
Peter
Jim = Schaad schreef op 2017-08-31 03:59:
I am wondering if = there should be a GET action defined against the
resource = directory object.  Currently, if an entity does a
registration for an endpoint it gets back a location for = that
registration.  If a second entity modifies the = endpoint and wants to
update the registration, it = currently has no method to get the
location associated = with the endpoint and cannot make a second new
registration = since the <domain, endpoint> pair is required to be
unique.
Thus
Interaction: EP = -> RD
Method: GET
URI Template: = {+rd}{?ep,d}
Content-Format: application/link-format (or = variants)
<rd/0099>;ep=3Dendpoint1,<rd/0098>;ep=3Dendpoint1;d= omain=3Dbeta, ...
Jim
= _______________________________________________
core = mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_A2BA215D-C424-4931-9B68-A9DBB5A08841-- From nobody Fri Sep 8 02:46:55 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5F6132ECF; Fri, 8 Sep 2017 02:46:53 -0700 (PDT) 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 mHwG_Q6hYkMo; Fri, 8 Sep 2017 02:46:52 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 183FD132403; Fri, 8 Sep 2017 02:46:51 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud8.xs4all.net with ESMTPA id qFs9d3vrycQyLqFs9deqhX; Fri, 08 Sep 2017 11:46:49 +0200 Received: from 83-161-167-172.mobile.xs4all.nl ([83.161.167.172]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 08 Sep 2017 11:46:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Sep 2017 11:46:49 +0200 From: peter van der Stok To: Michael Koster Cc: consultancy@vanderstok.org, Jim Schaad , draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfBXatO8KXtok/s3wxkeGYthBNIF9bsc+BR0OHDp3EDg2s4Yau2NzlgLVXJKZ9mYhtOi2VOLcSoO6HR39Bl0Nmx6kuXJwNTNvVARHv1vxCisnh05gif97 dJI591zXCdpK0V0uYn3wpRBLchMoC2G1ez0bK/nWUTdXEy6NPBi9gyzJ2+HLjfb2IoSPfrpN03tTVVk+Y5/U7O2c+mPbspV1YXSjOgO4VNmY1H1A/Dn4SaCR DzK2CgynzpH0jwdT2YzzMOs33b10xfcOiJjgS3LnuOnOAibxhCfnHjEdtGPnAAGW Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 08 Sep 2017 09:46:54 -0000 HI Michael, For me it looks OK. A few reflections: It must be clear in accompanying text, that "href" refers to the registration and "con" to the links of the registration. And core-rd.endpoint needs to be explained in text, and registered in core registry. Further, "ct" is an attribute of the links in all RD examples and not of the registration. Cheerio, Peter Michael Koster schreef op 2017-09-08 10:08: > Hi Peter, > > In your example, "loc" I presume is "location" which is how this is > returned in the response header when the registration resource is > created. > > In my example, I propose a hyperlink to a resource, so "href" is the > usual key for this in a link JSON. > > I also propose to include all of the link attributes including rt and > ct, so the client knows what it is without needing to infer anything. > > So your example would look like this: > > [ > { > "href" : "/rd/541", > "con": "coap://[fdfd::12]:17072", > "ep": "example-endpoint-name", > "et": "ocf-device", > "rt": "core.rd-endpoint", > "ct": 40, > "lt": 600, > "d": "floor-3" > } > ] > >> On Sep 8, 2017, at 12:25 AM, peter van der Stok >> wrote: >> >> Hi Michael, >> >> I would have expected: >> >> [ >> { >> "con": "coap://[fdfd::12]:17072", >> "loc" : "/rd/541", >> "ep": "example-endpoint-name", >> "et": "ocf-device", >> "lt": 600, >> "d": "floor-3" >> } >> ] >> >> and may be only ep and loc attributes; >> With this information the rest of the link information can be >> inferred. >> >> cheerio, >> >> Peter >> >> Michael Koster schreef op 2017-09-05 20:37: >> Hi Peter, >> The representation on slide 4 is not a complete dump, but exactly >> what >> you say; it's the locations and the registration parameters, exposed >> as link target attributes. >> The example has one "self" link for the RD itself, and one link for >> each registration resource (only one is shown). >> [ >> { >> "href": "/registration/", >> "rel": "self", >> "rt": "core.rd", >> "ct": 40 >> }, >> { >> "href": "/registration/f3cca57e/", >> "con": "coap://[fdfd::12]:17072" >> "rt": "core.rd-endpoint", >> "ct": 40, >> "ep": "example-endpoint-name", >> "et": "ocf-device", >> "lt": 600, >> "d": "floor-3" >> } >> ] >> On Sep 4, 2017, at 11:37 PM, peter van der Stok >> wrote: >> Hi Michael, >> Originally, I thought the same, but the packets get really large by >> doing a complete dump. >> The compromise is just sending the (endpoint names/ registration >> resource location) with its registration attributes. >> Peter >> Michael Koster schreef op 2017-09-05 08:27: >> I would propose returning links for all registration resources in >> the >> RD as shown in slide 4 of the attached deck (JSON format shown). >> This >> would include the most recent setting of the "lt" or lifetime >> parameter as a link target attribute as shown. >> On Sep 4, 2017, at 8:27 AM, Jim Schaad >> wrote: >> Yes that is what I had in mind. It would be useful to add a ttl >> attribute >> as well. >> Jim >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Monday, September 4, 2017 1:46 AM >> To: Jim Schaad >> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org >> Subject: Re: draft-ietf-core-resource-directory = GET /rd >> Hi Jim, >> Personally, I like the idea. >> That would mean that all registration resources are returned. >> In the next version of the RD, location or endpoint identifies the >> registration. >> Uniqueness of links is specified in section 5.3.4, already commented >> on by >> you. >> Your request means returning all locations with the ep, lt, d, and >> et >> attributes >> and the associated scheme://authority:port value. >> Correct? >> Peter >> Jim Schaad schreef op 2017-08-31 03:59: >> I am wondering if there should be a GET action defined against the >> resource directory object. Currently, if an entity does a >> registration for an endpoint it gets back a location for that >> registration. If a second entity modifies the endpoint and wants to >> update the registration, it currently has no method to get the >> location associated with the endpoint and cannot make a second new >> registration since the pair is required to be >> unique. >> Thus >> Interaction: EP -> RD >> Method: GET >> URI Template: {+rd}{?ep,d} >> Content-Format: application/link-format (or variants) >> ;ep=endpoint1,;ep=endpoint1;domain=beta, ... >> Jim >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 8 06:58:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84F8132153; Fri, 8 Sep 2017 06:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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] 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 iqKgq1khXQR7; Fri, 8 Sep 2017 06:58:31 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 9CBC41323A3; Fri, 8 Sep 2017 06:58:30 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id e1so4673639pfk.1; Fri, 08 Sep 2017 06:58:30 -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=oFGtO7flMTA+lH2X/msPvxoxOLyRuPM7Y+G+8xuDI1c=; b=Nwi5vV2aqsah/pGV4W7oxqF9sJNPwrCFcGe/YeLhgCcs9TkW59hYzIFZ9GM6wPBDmS sVpotuyutHliakmSSamZajUZwHew/b93LHcEXiylBpz1zS2QyrVCTMKgladGf0eV1BFK P3kSRxtZq1NAveM5F8torN0v7G5zK8VOTwsaBcoOGJVI9fWJqfl5aQ5k0kI7n2j+/C9O zQ+T3jklTPDHmAJ6er9hJxk5PYsiuTQ/lVNnlyfdOV/6vOGAGwOM+Q6B6WBWBLCTwP87 rjzyUXEFa4owSKOv2R5YIOdM94QlwqdEMIAdgTK8HopoLcydXSO/rSXpcHkYcKKAlS2i FuNg== 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=oFGtO7flMTA+lH2X/msPvxoxOLyRuPM7Y+G+8xuDI1c=; b=sHN6KNjIJlLV1VumrPyL0wAM47eHGpwhHoBkH57sijCSNvsSKxZJPH6Sb3YhD2A+SQ iLUGn3OJhOLL1x1ZQSQYnyzeUbQwbZ/nZ6z+sCDAtg0DyFweglOYO021/Xo8jDplRC4E P+79iYAbKUbZJ+51wZcfB3q3DLoefPb0rJCA6fsR+t1Oak+aRjcVmDkroA4ZrJ+wNtuL q+mSSWO+O1yDiXAyPwB9OED8fDGArutlLV6YOaCS7TanufO4uoBfpyOUgOC0lYarn+4Q ilYwq+ffYBW+QPG8ft1HGUHeMZdBRME8B3ElAdurPX6mN8wIU/y9rnWnsBGF6QIonp6a ckgA== X-Gm-Message-State: AHPjjUiYFX5aAiwXKUTQr+5zTAgQYwsZyBz1EmbCCM38rBf0aVecfNZ6 mAyn1sikP2HRvj8mI0U= X-Google-Smtp-Source: ADKCNb5/TdBS+M03sA9CHyR+/wLwTVXZ9zNTvcGPzFka2K9JOC1VoNOvYl9/+GF+RE/DvsMAby7wEg== X-Received: by 10.84.130.9 with SMTP id 9mr3526365plc.241.1504879109978; Fri, 08 Sep 2017 06:58:29 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id l25sm4767789pfj.141.2017.09.08.06.58.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 06:58:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: Date: Fri, 8 Sep 2017 06:58:27 -0700 Cc: Jim Schaad , "draft-ietf-core-resource-directory@ietf.org" , core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <64ECEBB9-06D5-4A88-A89D-622B4DFB6D54@gmail.com> References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 08 Sep 2017 13:58:34 -0000 Hi Peter, Sounds like we are basically on the same page. In RFC6690 links, "href" always points to the target of the link, and = "rel" describes the relationship between the parent resource that holds = the link and the target resource. The other items are all attributes of = the target resource. So "con" refers to the registration resource, and reflects the "con" = parameter that was supplied during registration. Likewise, "ct" refers to the ct of the registration resource, that is = the format that the registered links are returmed in. Anything that = returns a payload has a ct. Does it all make sense? Best regards, Michael > On Sep 8, 2017, at 2:46 AM, peter van der Stok = wrote: >=20 > HI Michael, >=20 > For me it looks OK. A few reflections: > It must be clear in accompanying text, that "href" refers to the = registration and "con" to the links of the registration. And = core-rd.endpoint needs to be explained in text, and registered in core = registry. Further, "ct" is an attribute of the links in all RD examples = and not of the registration. >=20 > Cheerio, > Peter >=20 > Michael Koster schreef op 2017-09-08 10:08: >> Hi Peter, >> In your example, "loc" I presume is "location" which is how this is >> returned in the response header when the registration resource is >> created. >> In my example, I propose a hyperlink to a resource, so "href" is the >> usual key for this in a link JSON. >> I also propose to include all of the link attributes including rt and >> ct, so the client knows what it is without needing to infer anything. >> So your example would look like this: >> [ >> { >> "href" : "/rd/541", >> "con": "coap://[fdfd::12]:17072", >> "ep": "example-endpoint-name", >> "et": "ocf-device", >> "rt": "core.rd-endpoint", >> "ct": 40, >> "lt": 600, >> "d": "floor-3" >> } >> ] >>> On Sep 8, 2017, at 12:25 AM, peter van der Stok >>> wrote: >>> Hi Michael, >>> I would have expected: >>> [ >>> { >>> "con": "coap://[fdfd::12]:17072", >>> "loc" : "/rd/541", >>> "ep": "example-endpoint-name", >>> "et": "ocf-device", >>> "lt": 600, >>> "d": "floor-3" >>> } >>> ] >>> and may be only ep and loc attributes; >>> With this information the rest of the link information can be >>> inferred. >>> cheerio, >>> Peter >>> Michael Koster schreef op 2017-09-05 20:37: >>> Hi Peter, >>> The representation on slide 4 is not a complete dump, but exactly >>> what >>> you say; it's the locations and the registration parameters, exposed >>> as link target attributes. >>> The example has one "self" link for the RD itself, and one link for >>> each registration resource (only one is shown). >>> [ >>> { >>> "href": "/registration/", >>> "rel": "self", >>> "rt": "core.rd", >>> "ct": 40 >>> }, >>> { >>> "href": "/registration/f3cca57e/", >>> "con": "coap://[fdfd::12]:17072" >>> "rt": "core.rd-endpoint", >>> "ct": 40, >>> "ep": "example-endpoint-name", >>> "et": "ocf-device", >>> "lt": 600, >>> "d": "floor-3" >>> } >>> ] >>> On Sep 4, 2017, at 11:37 PM, peter van der Stok >>> wrote: >>> Hi Michael, >>> Originally, I thought the same, but the packets get really large by >>> doing a complete dump. >>> The compromise is just sending the (endpoint names/ registration >>> resource location) with its registration attributes. >>> Peter >>> Michael Koster schreef op 2017-09-05 08:27: >>> I would propose returning links for all registration resources in >>> the >>> RD as shown in slide 4 of the attached deck (JSON format shown). >>> This >>> would include the most recent setting of the "lt" or lifetime >>> parameter as a link target attribute as shown. >>> On Sep 4, 2017, at 8:27 AM, Jim Schaad >>> wrote: >>> Yes that is what I had in mind. It would be useful to add a ttl >>> attribute >>> as well. >>> Jim >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Monday, September 4, 2017 1:46 AM >>> To: Jim Schaad >>> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org >>> Subject: Re: draft-ietf-core-resource-directory =3D GET /rd >>> Hi Jim, >>> Personally, I like the idea. >>> That would mean that all registration resources are returned. >>> In the next version of the RD, location or endpoint identifies the >>> registration. >>> Uniqueness of links is specified in section 5.3.4, already commented >>> on by >>> you. >>> Your request means returning all locations with the ep, lt, d, and >>> et >>> attributes >>> and the associated scheme://authority:port value. >>> Correct? >>> Peter >>> Jim Schaad schreef op 2017-08-31 03:59: >>> I am wondering if there should be a GET action defined against the >>> resource directory object. Currently, if an entity does a >>> registration for an endpoint it gets back a location for that >>> registration. If a second entity modifies the endpoint and wants to >>> update the registration, it currently has no method to get the >>> location associated with the endpoint and cannot make a second new >>> registration since the pair is required to be >>> unique. >>> Thus >>> Interaction: EP -> RD >>> Method: GET >>> URI Template: {+rd}{?ep,d} >>> Content-Format: application/link-format (or variants) >>> ;ep=3Dendpoint1,;ep=3Dendpoint1;domain=3Dbeta, ... >>> Jim >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 8 09:00:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3353D1321BB; Fri, 8 Sep 2017 09:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 i_zkvX-YcxgB; Fri, 8 Sep 2017 08:59:59 -0700 (PDT) Received: from mail4.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 5663613202D; Fri, 8 Sep 2017 08:59:59 -0700 (PDT) Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504886356; h=from:subject:to:date:message-id; bh=8fjKC/tVdOmT5SWas65IBvxEdc/obPUpBjmp/npRr14=; b=ahXhoMe0E32pTZyEj4TGkP2VdmEETkCOQdIZsZUxGbcKrDtbN79kVqDeaTyzX9xFocS+HgGRw7H 3ZuyqvTeRAI+pR9o0fybKeYW2Ij45l72VpGp80t1gQBcHGoCI33shwMs3dS7QnwZnTzLjFr8CUtS5 /AzofV9L6Kf5zq8lFzUAAQIaxg5Fu+u+6OFlSnht4g++LNZ2a+68hBZ8MXX3wqxYm6MrYrs37flk2 lJNuvIV5vnsFfXAneuRK1a7XzREujBJfuV4Py0TD8xac1zgI5txRLz53kali1rM3PHfr5ybk+VOKS LJj704UO7KrFnYDCrL/BPI2yB34rOVX2mLsQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 08:59:15 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 08:58:52 -0700 From: Jim Schaad To: CC: , References: <007801d32694$51c49790$f54dc6b0$@augustcellars.com> <1f46d054a227bdba7dc07e5c22bd1549@xs4all.nl> In-Reply-To: <1f46d054a227bdba7dc07e5c22bd1549@xs4all.nl> Date: Fri, 8 Sep 2017 08:59:27 -0700 Message-ID: <01e001d328bb$74914830$5db3d890$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG7y7s0xzESzvmFLsqwYfNdMU3cZwGcOV+Sosz9WFA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] My endpoint has two addresses 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, 08 Sep 2017 16:00:01 -0000 One way that I have thought of dealing with this is to extend the check on endpoint uniqueness from to . The only downside that I can see is that it makes the query on the endpoint resource slightly more complicated. Jim > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Friday, September 8, 2017 12:29 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > Subject: Re: [core] My endpoint has two addresses > > Hi Jim, > > Indeed this is an issue that was also brought up by Dave Thaler, where he > referred to the multiple types of coap schemes that became possible. > > For the moment, we made the model such that and extension to multiple > contexts is possible, but not yet supported by the RD, given that all these > extensions are still under discussion, > > Peter > > Jim Schaad schreef op 2017-09-06 00:14: > > One of the issues that I just come up with, and might be part of an I > > don't care space, is that if an endpoint has two different addresses > > then the registration resource cannot have two different addresses > > associated with it. You cannot have two different registration > > resources with the same endpoint name. This means if I want to > > register both IPv6 and IPv4 (or > > other address types) with the same endpoint there is a problem. I > > also > > just realized that same issue arises with schema. These only apply if > > you want to use the context parameter. If you are going to supply > > full URL addresses to resources then this is doable. Given that the > > context parameter is for space savings, I wonder if some method of > > dealing with this should be considered. Possibly defining some type > > of context selector or something? > > > > Jim > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 8 13:48:30 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C06132D4A; Fri, 8 Sep 2017 13:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Yifk6AZDWkIL; Fri, 8 Sep 2017 13:48:28 -0700 (PDT) Received: from mail4.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 2496B1200F3; Fri, 8 Sep 2017 13:48:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504903666; h=from:subject:to:date:message-id; bh=8Fnlbe+ef3/RJqz/qJZoAWOJloACJsE+ThQur+jYP4k=; b=B/ynCJisi+4M1suC/9mQrGCMlPL7LaMb1870G91JBh+hIqF6bwQPw8+neR99APAdsn06HuxIQx4 5oosrkg980pVXjSMP5UfrVVDSi8fOCPLkuqp4zPPuEBUEruAPjulNAv+R7CkhFQf/tmI6ewpcCi5m YzXIOHeo+hX0LOALju5qafgWbEIOrY/jNXRVrKdeVwUo7LTgTxQrwQ6F0eISSt8IO4283PrIMbK0S agoq0F1aQ+az7e1fkSaowiH97MrRnZuSKZ8rwqBZrylwdfMJ3B3XDZ42jtxhs9sY9qQnqW+90I2LH nXqr+qEbrC+rc7Qw+HyJDU2950y572SkEpTg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 13:47:44 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 13:47:22 -0700 From: Jim Schaad To: CC: Date: Fri, 8 Sep 2017 13:47:57 -0700 Message-ID: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMo4SDXZS5uvdf5TQmJ9FZFrAciVw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Resource Directory - Returned items from Lookup resources 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, 08 Sep 2017 20:48:29 -0000 I am trying to figure out what items are going to be returned from a lookup query and I do not believe that the set of items in the examples is what should be followed. 1. I am going to assume that all attributes registered with a resource are going to be returned with the resource. 2. I am unclear if the context is what should be returned as the link address for an endpoint or if it is just the scheme + authority (i.e. omit any path portion). 3. For the domain and group lookups, is the href an empty string or is it absent? This does not make a different for the standard link formation, but it does make a difference for the cbor and json formats. 4. I assume that the 'et' parameter should be returned on all end points. 5. How would an empty domain name be returned (this is my current pre-configured default domain) - as an empty string or as just the attribute name - i.e d or d="" ? Jim From nobody Sat Sep 9 11:09:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6C132D42; Sat, 9 Sep 2017 11:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 KtCMEY9CMEzz; Sat, 9 Sep 2017 11:09:28 -0700 (PDT) Received: from mail4.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 14F3B13219F; Sat, 9 Sep 2017 11:09:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504980527; h=from:subject:to:date:message-id; bh=MXJdtX7p6cxU7ubbpxvUuQLTKOjdRglGI+c4hqkxNk0=; b=F1ArWK8m+QEzHfhwx1nyzqRYn55qskhZu4wz7orLnTSGdGjodfBMahOctTnbNGN8rXqm9lqAyEb XNJO5FXxc1VDHI+24bwCn47G3aWDygtGoL9w+HWBZLhcRFKD5HH+vUCWwG2LWVJU8OucwaNB9v6+j nM+hBKt+XkOiuhiPMkxcQvCi4noaPU6Ti/EXlV910MpWzVDS3cveUMHGUQfr23ObZTgIslwq+beKJ LLHldaeU96JFW3p5KiHCJtKpKw4KzvPQDSTzB7ddjZCo/z2GqjinesfsEQEqCBnH6TWHm3+lqVKc9 waiikAHqDSil2662e46lEDiCo2kABr4M2ozQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 9 Sep 2017 11:08:46 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 9 Sep 2017 11:08:43 -0700 From: Jim Schaad To: CC: Date: Sat, 9 Sep 2017 11:09:18 -0700 Message-ID: <003b01d32996$c2c35210$4849f630$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMpjtYIUFzbtEriR3ihHOp6Hi6nIQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Resource Directory - Group Processing 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, 09 Sep 2017 18:09:30 -0000 I am going through the group processing and I have the following issues: 1. There are no methods defined for modifying the contents of a group. There is only a method for replacing the contents entirely. Is this intentional? 2. The description of the context parameter looks to be a cut and paste that you did not review. If the parameter is absent, I do not believe that it makes sense to try and infer a context. My assumption is that a context is only going to supplied in the event that a multicast address is associated with the group. 3. Similar to the request for a GET on the resource directory to get the list of resource registries, I believe that you should have a GET on the group directory to get the list of group registries. Jim From nobody Tue Sep 12 00:35:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CEE132F99 for ; Tue, 12 Sep 2017 00:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=tcs.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 cKuC68fIjPmV for ; Tue, 12 Sep 2017 00:35:02 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) (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 1FDC1132F7A for ; Tue, 12 Sep 2017 00:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default; t=1505201701; x=1536737701; h=mime-version:in-reply-to:references:subject:from:to: message-id:date; bh=JgxHBnB3YWdUKfAXtSw6C06OCwW4ZlOAbgh15rqnms8=; b=mIvBZQUDq4WCH99lhtlztCWZwMOpatiQcN2SivVS71YFK7/lvy9t4kCr 6sV2bEKfULwesAl1rhuYI8H7cg32gqaJaC0Hq7NavEuO9fkHPbz6gPuR+ GO/at9BPEQuu6gwYGMPUJtTHCJxahw92Iik0YLiHmz/ezYna5BLG9Y3Ie o=; IronPort-PHdr: =?us-ascii?q?9a23=3AZrC/NRCY98vmgysThrdPUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPvyp8bcNUDSrc9gkEXOFd2CrakV2qyK6uu/BiQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Zb5+Nhq7oRjeusQUg4ZpN7o8xAbOrnZUYe?= =?us-ascii?q?pd2HlmJUiUnxby58ew+IBs/iFNsP8/9MBOTLv3cb0gQbNXEDopPWY15Nb2tRbY?= =?us-ascii?q?VguA+mEcUmQNnRVWBQXO8Qz3UY3wsiv+sep9xTWaMMjrRr06RTiu86FmQwLuhS?= =?us-ascii?q?waNTA27XvXh9R/g61YuhyupRJ/zZPUbo+LN/RwcKTTcs8BSGVbQspcTTZMAoeg?= =?us-ascii?q?Y4cSCecKIOZWr5P6p1sLtRazGRKjBOPuyj9KnHD227Ax3vkhEQ7cwAwgA8gBv2?= =?us-ascii?q?jUrNrvLqcTUeC0w7PVxjjEdfxZwjf96InKch87p/GAR6l/ccrLxkkzCwPKlEmf?= =?us-ascii?q?qYz/MDOP1uUMs3KU4vF8Ve2zkG4rsR1+oj+qxso1jITCm4wbylfB9SpjwYY1I8?= =?us-ascii?q?W1SFJnbt6/CpdfqyaaN45wT8g/QG9ooD43xqAEtJKlZiQG1ZcqywTBZ/GJaYSF?= =?us-ascii?q?7RTuX/uLLzhinnJqYre/ig638Uin1+LzSNG50E1PripZitnMsW0N1wDL5siHVP?= =?us-ascii?q?R9+kCh1C6M2Q7L7+9KOEY6m7fHJpAnzLA+kIAdv0PdECLqhUn6lK6WdkM69ei0?= =?us-ascii?q?8+nrf7frqoGGO4NpiQzyKLoil8KlDek3KgQOWnKU+eW41L3t5035R7BKg+Usna?= =?us-ascii?q?bCsJDaJMYbqbS/AwNPyYkj6wywDyu60NsCgXYHLEhKeAiHjonpIV7DO+z4Auuk?= =?us-ascii?q?g1i2jDhrwPXGMqX7AprRNnjDjKvhfbFl5kFAzwoz185Q6olVCr4fPPLzVFX9tN?= =?us-ascii?q?vCDh82YESIxLPsD89w/oITRWzJBbWWY43Itlrdz+gvIuuFYsc/uD/hN/Eu5/f0?= =?us-ascii?q?nG4w0QsUd6mo35IRLnq4F+h6Kk6ZaGD9k94pDWwR+AE5Sbq52xW5TTdPaiPqDO?= =?us-ascii?q?oH7TYhBdf+AA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DOAQDDjLdZ/wQXEqxcHgYMGAEFAQsBh?= =?us-ascii?q?BSBFbZXDoIEJYoNGAEBAQEBAQEBAQEBgRKCMyKCSoEOCgEIMk0REQgRCrNLAQE?= =?us-ascii?q?BgxCLZIMrgiRvigmBBIJyBYIxBZI2jj+CLqUWlmYfgUV3X4RIgltuig0BAQE?= X-IPAS-Result: =?us-ascii?q?A2DOAQDDjLdZ/wQXEqxcHgYMGAEFAQsBhBSBFbZXDoIEJYo?= =?us-ascii?q?NGAEBAQEBAQEBAQEBgRKCMyKCSoEOCgEIMk0REQgRCrNLAQEBgxCLZIMrgiRvi?= =?us-ascii?q?gmBBIJyBYIxBZI2jj+CLqUWlmYfgUV3X4RIgltuig0BAQE?= X-IronPort-AV: E=Sophos;i="5.42,382,1500921000"; d="scan'208";a="248326882" MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Abhijan Bhattacharyya To: core@ietf.org Message-ID: Date: Tue, 12 Sep 2017 13:04:08 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP8HF242 May 5, 2017 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 09/12/2017 13:04:08, Serialize complete at 09/12/2017 13:04:08, Itemize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 09/12/2017 13:04:08, Serialize by Router on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 09/12/2017 13:04:10, Serialize complete at 09/12/2017 13:04:10 Content-Type: multipart/alternative; boundary="=_alternative 002993F265258199_=" Archived-At: Subject: [core] CoAP on INET? 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, 12 Sep 2017 07:35:04 -0000 --=_alternative 002993F265258199_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear List, Is there any implementation of CoAP on INET & OMNET++? Thanks. With Best Regards Abhijan Bhattacharyya Associate Consultant Scientist, TCS Research Tata Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- 033 66884691 Cell:- +919830468972 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ = =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 002993F265258199_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear List,
Is there any implementation of CoAP on INET & OMNE= T++?
Thanks.

With Best Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- 033 66884691
Cell:- +919830468972
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.= tcs.com
____________________________________________
Experience certainty. IT Services
 Business Solutions
 Consulting
____________________________________________

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

--=_alternative 002993F265258199_=-- From nobody Tue Sep 12 16:46:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F682133188; Tue, 12 Sep 2017 16:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 vzfU5s_FFHlY; Tue, 12 Sep 2017 16:46:48 -0700 (PDT) Received: from mail4.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 60C7013219A; Tue, 12 Sep 2017 16:46:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505259963; h=from:subject:to:date:message-id; bh=+6Mht5NJAkRROjSu6BdmhJxsCoLqNAIm4AlmTl3kURU=; b=QrkbbwmhPwqm+OUdVwMVZEFvA5BoQ/5Uk0WqNcxNptKJJsBrowShAPx6oP1ec0BtS7IuhZhu2g9 NdasXgeOXL5S4oA60knKc/M4AaKFfXu6SmpO5hR4xv24gBGxcYO4l1k+IVaEj6ydrcpeyI+uvbkc0 QEs/VAsORiwZdjvulfF7bILbbF/eV7fBJV7PFgKKvKCU/MIp8DNSk+eICGyJrX2CQUmdD+LZDOgAi WSbj8437a7ZlR52tNs81BOTd2iabIKrAzdNzCgBzAHhfNwDH1oBxe0Un5CxknHRpXvNTzWidML+vr jkxTEV49qmsZ/q9gYCQPBNKLji4g2tI/a0tA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 16:46:02 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 16:45:40 -0700 From: Jim Schaad To: CC: Date: Tue, 12 Sep 2017 16:46:15 -0700 Message-ID: <018301d32c21$551bbb20$ff533160$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMsHDJynaiCAuwIQgSX+zcrwFDS1w== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Resource Directory - Filters on Lookup Resources 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, 12 Sep 2017 23:46:50 -0000 I am working on figuring out how to deal with the filter properties when working with the lookup resources and I am have problems because I don't understand how some of them are supposed to be applied. It may be that you just did cut and paste more than you should have when specifying what lookup resources they applied to. An idea of how things are supposed to work would be nice to see. If I am doing a look up for groups, what does it mean to specify that you are looking for a specific resource type? Should this not be supported for groups or does this mean that the RD is expected to only return those endpoints where a resource exists of the specified resource type? A similar question exists for the "res" query parameter. For a group, does this mean that the multicast address is being matched or a resource for some endpoint in the group is being matched? You need to look at each of the items and determine what it means for each lookup resource type and identity it for the reader. Jim From nobody Wed Sep 13 21:11:48 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25E132D89; Wed, 13 Sep 2017 21:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 xyf3tgxbGBs9; Wed, 13 Sep 2017 21:11:46 -0700 (PDT) Received: from mail4.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 745221321A4; Wed, 13 Sep 2017 21:11:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505362202; h=from:subject:to:date:message-id; bh=yHIjTaKaeSOyCq7MxIpOzrujm21Qd55tG5YwCP3jql8=; b=gg7nRSEVPuxJGfObCIcJJqJq3zKw0Yx//G26tu4qfqJZ632O19i/xuoQxSq8rUYQJ7p27NsV1OR v+V0YgfKYCpDHs+AHAxall0ZlgZ6uJgKfMwsdbngCIUYSFrNj1A03+ByLchmcew0NO0u9Dk7EfwdY drRrvoalzrDYGc50L9XbtAnNbDLDYxHe8MeLefUYv9Da1mhM1HrVJyMUwboBUaYoi7xSKOKikWu9x BAFSc5LmvAibFi7Nnz4Qz5I1JnY/DwKRAlLmq4pCWhArpL2iziK67NS9U+tq2fNz1PD4NEmxaEWcx DOUMltOZZMiCUV3ZwZCNk4KwOcOR0yfsGxow== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 21:10:00 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 21:09:57 -0700 From: Jim Schaad To: CC: Date: Wed, 13 Sep 2017 21:10:34 -0700 Message-ID: <000001d32d0f$6ba39b80$42ead280$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMtDUO/Se0FaC9oQ8e7prarOw47xg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [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: Thu, 14 Sep 2017 04:11:48 -0000 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? 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. 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=temperature;ct=50". Do you believe that I am wrong? 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. Jim From nobody Fri Sep 15 01:55:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51201321BB; Fri, 15 Sep 2017 01:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 SwIGOYag9UR5; Fri, 15 Sep 2017 01:55:41 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 3492F133082; Fri, 15 Sep 2017 01:55:40 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud7.xs4all.net with ESMTPA id smPRdUDWrG5oqsmPRdsbc7; Fri, 15 Sep 2017 10:55:37 +0200 Received: from AMontpellier-654-1-184-83.w92-145.abo.wanadoo.fr ([92.145.163.83]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 15 Sep 2017 10:55:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 15 Sep 2017 10:55:37 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <018301d32c21$551bbb20$ff533160$@augustcellars.com> References: <018301d32c21$551bbb20$ff533160$@augustcellars.com> Message-ID: <0458bd70a9f4ed8d1df8b36861441239@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfLIWOlpjGMIzr/s4HaSpol1GA6JQDER2dm6oErj8EEB1Srz2El6JLN6YTPEsyqJtU+u1VwIrXmGf8KGVaHTHCWsKsHCh8Zc6k5Hj2drbKo8Ai1jzfoWo hOMJjQmdlH/TPoWJzR/UNsAnDTtF5bElH98kBzhgrYtvnbjYkbscKq9SM6gyqayGRr/011XMfjUt53vjgcXJ5J6H6J6CHZnO6B1nU7t3Zyr3K1tYEk2cLXKj Hu6bq53u5DJ08CZ9lrtptw== Archived-At: Subject: Re: [core] Resource Directory - Filters on Lookup Resources 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, 15 Sep 2017 08:55:49 -0000 Hi Jim, Really thanks for this detailed inspection of the RD draft. The draft has had a long history of reviews, improvements and (forgotten) discussions. See below. Jim Schaad schreef op 2017-09-13 01:46: > I am working on figuring out how to deal with the filter properties > when > working with the lookup resources and I am have problems because I > don't > understand how some of them are supposed to be applied. It may be that > you > just did cut and paste more than you should have when specifying what > lookup > resources they applied to. An idea of how things are supposed to work > would > be nice to see. > > If I am doing a look up for groups, what does it mean to specify that > you > are looking for a specific resource type? Should this not be supported > for > groups or does this mean that the RD is expected to only return those > endpoints where a resource exists of the specified resource type? The purpose of groups was to service MC requests. That means that the path and rt on the receivers (group members) are identical. So, if one ep supports that particular rt, I would expect that all eps do. Do you want to extend the group concept? or suggest text in the group specification? > > A similar question exists for the "res" query parameter. For a group, > does > this mean that the multicast address is being matched or a resource for > some > endpoint in the group is being matched? Is that answered above? > > You need to look at each of the items and determine what it means for > each > lookup resource type and identity it for the reader. > > Jim > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 15 02:34:26 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4C613308B; Fri, 15 Sep 2017 02:34:25 -0700 (PDT) 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_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 185vSEw4fjK9; Fri, 15 Sep 2017 02:34:24 -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 4ED98124B18; Fri, 15 Sep 2017 02:34:24 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud7.xs4all.net with ESMTPA id sn0vdUYQUG5oqsn0vdsnkK; Fri, 15 Sep 2017 11:34:21 +0200 Received: from AMontpellier-654-1-124-214.w90-0.abo.wanadoo.fr ([90.0.211.214]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 15 Sep 2017 11:34:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 15 Sep 2017 11:34:21 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <003b01d32996$c2c35210$4849f630$@augustcellars.com> References: <003b01d32996$c2c35210$4849f630$@augustcellars.com> Message-ID: <6a9614c27dd85afdedf4f607e5357289@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfE4uEvoMXV43kryNYwz1YKXUlj0WvLYq1C3j1x9rSOoOWHlVk/P5+/2msprzw4T0CyU3BGMBHoHZM6ULWoVlE0Hzkxrpmm5qZZF1rJdb4Fkm44Dgto4I 65ABAo4sMO7+ae1BGv3ovrQCTtc7SYPEDtHc44D4kRQLvYeGGVWDWfN9CW1RcFP4U7XBS7G8ZMOfBHYL3k9w9TPm56re2H461LWVkQ8iwySQwxnDGvx2XvFO dWOZv016dpE4eIL0pM/dxg== Archived-At: Subject: Re: [core] Resource Directory - Group Processing 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, 15 Sep 2017 09:34:26 -0000 Hi Jim, see below. Jim Schaad schreef op 2017-09-09 20:09: > I am going through the group processing and I have the following > issues: > > 1. There are no methods defined for modifying the contents of a group. > There is only a method for replacing the contents entirely. Is this > intentional? In the beginning, yes. You suggest to specify a PATCH? > > 2. The description of the context parameter looks to be a cut and > paste > that you did not review. If the parameter is absent, I do not believe > that > it makes sense to try and infer a context. My assumption is that a > context > is only going to supplied in the event that a multicast address is > associated with the group. I concur with you. Suggestion to remove con parameter from gp interface. > > 3. Similar to the request for a GET on the resource directory to get > the > list of resource registries, I believe that you should have a GET on > the > group directory to get the list of group registries. As suggested in your earlier e-mails to do a GET on the registrations, and add the gp option? > > Jim Cheerio, Peter From nobody Fri Sep 15 02:48:51 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E833132F76; Fri, 15 Sep 2017 02:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_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 W1klStRMX2Mn; Fri, 15 Sep 2017 02:48:48 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 310B2133094; Fri, 15 Sep 2017 02:48:47 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud7.xs4all.net with ESMTPA id snErdUfx9G5oqsnErdssFf; Fri, 15 Sep 2017 11:48:45 +0200 Received: from AMontpellier-654-1-124-214.w90-0.abo.wanadoo.fr ([90.0.211.214]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 15 Sep 2017 11:48:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 15 Sep 2017 11:48:45 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> References: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfC9qVjubWFb5yyIcLTEZ5/sucqUpDOGA1dRasl2IvzZO56DqqnhcaWFyOW2Uh2KFCj9C7hX72uL/e1RPjgucjK9vpqHrmJCjnLxJu5dBdBUMWKyKjkcX DTFA0NMSkiTho7MRop4/O9TUcy2rN9eH31OzzDsRfQfcfBV6iLTl6gTxeX+uV9H+xVkHNQNreaSlTq7CIOyer70ugRNbttf3dS5Nak2XjBZlYOv1WTsfurAQ fhtzqSXP6sEu1/Jpp8o6gQ== Archived-At: Subject: Re: [core] Resource Directory - Returned items from Lookup resources 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, 15 Sep 2017 09:48:50 -0000 Hi Jim, Again thanks. You mention controversial subjects; and I am going to present my opinion. These issues are also related with the properties of the anchor parameter. I am looking forward to reasoned alternatives by co-authors. Jim Schaad schreef op 2017-09-08 22:47: > I am trying to figure out what items are going to be returned from a > lookup > query and I do not believe that the set of items in the examples is > what > should be followed. > > 1. I am going to assume that all attributes registered with a resource > are > going to be returned with the resource. An attribute can have zero values. In that case (IMO) I assume nothing is returned. > > 2. I am unclear if the context is what should be returned as the link > address for an endpoint or if it is just the scheme + authority (i.e. > omit > any path portion). I find the concatenation of "con" and "href" values, as currently suggested in the examples, also difficult to understand. IMO the href value should be returned between <> brackets, and the con as an additional attribute. > > 3. For the domain and group lookups, is the href an empty string or is > it > absent? This does not make a different for the standard link > formation, but > it does make a difference for the cbor and json formats. @ Michael can you answer, being involved in the link-json document > > 4. I assume that the 'et' parameter should be returned on all end > points. et can have no value; IMO do not return anything. > > 5. How would an empty domain name be returned (this is my current > pre-configured default domain) - as an empty string or as just the > attribute > name - i.e d or d="" ? Actually the d= can have no value, and IMO like et, do not return anything when there is no value. > > Jim > > cheerio, peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 15 04:51:26 2017 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 7D06C1331BA; Fri, 15 Sep 2017 04:51:18 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150547627843.2403.4685194638379613038@ietfa.amsl.com> Date: Fri, 15 Sep 2017 04:51:18 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dynlink-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: Fri, 15 Sep 2017 11:51:18 -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 Michael Koster Christian Groves Julian Zhu Bilhanan Silverajan Filename : draft-ietf-core-dynlink-04.txt Pages : 16 Date : 2017-09-14 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-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 Fri Sep 15 15:15:47 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BA7134236; Fri, 15 Sep 2017 15:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 3p3-EFPl6Xt0; Fri, 15 Sep 2017 15:15:44 -0700 (PDT) Received: from mail4.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 08CB6134231; Fri, 15 Sep 2017 15:15:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505513698; h=from:subject:to:date:message-id; bh=+jf44iU4Owwhk2DrSdGL2w0wHq+cEnaZ0Ti/viLX7S0=; b=Wz7PbUBalJR2ZjVOBezTUhhF9ZKBulFVzFGRGaDO5N77+7sYl4c9/gMoXIqZHb1whtFpry7SxUt 6TaaaEtKQ0vELsZ/ssZtYuwJGi3BbQ9JImU1j6tPAUF2rPmNttmNjVtfYGZaod3IpKTzaAey0rIws jXSfdBDWk4QREwyh7WjtjNcSgW8847nWwe0ObmYPCY4DxmCsC8nUHAAENGiAMXk57lxyAgGxOmCnQ 0DxdWrUndR+KUFhP7tT0mG5/rYkP7CdEY6Y7+6m2YM2fLEfr5+43xf3lKIdc+bodWp7IoIe5m0Xsr y6O6sNCxIbosoVVEufacT9wceBO53t2Nrb7A== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 15:14:57 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 15:14:55 -0700 From: Jim Schaad To: CC: , References: <018301d32c21$551bbb20$ff533160$@augustcellars.com> <0458bd70a9f4ed8d1df8b36861441239@xs4all.nl> In-Reply-To: <0458bd70a9f4ed8d1df8b36861441239@xs4all.nl> Date: Fri, 15 Sep 2017 15:15:32 -0700 Message-ID: <00fa01d32e70$2736bd30$75a43790$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHuIXHfk97MEuh4cqfx7aNqZM/2fAJTf3dfom38mSA= X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [core] Resource Directory - Filters on Lookup Resources 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, 15 Sep 2017 22:15:46 -0000 See inline comments > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Friday, September 15, 2017 1:56 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > Subject: Re: [core] Resource Directory - Filters on Lookup Resources > > Hi Jim, > > Really thanks for this detailed inspection of the RD draft. > The draft has had a long history of reviews, improvements and > (forgotten) discussions. > See below. > > Jim Schaad schreef op 2017-09-13 01:46: > > I am working on figuring out how to deal with the filter properties > > when working with the lookup resources and I am have problems because > > I don't understand how some of them are supposed to be applied. It > > may be that you just did cut and paste more than you should have when > > specifying what lookup resources they applied to. An idea of how > > things are supposed to work would be nice to see. > > > > If I am doing a look up for groups, what does it mean to specify that > > you are looking for a specific resource type? Should this not be > > supported for groups or does this mean that the RD is expected to only > > return those endpoints where a resource exists of the specified > > resource type? > > The purpose of groups was to service MC requests. > That means that the path and rt on the receivers (group members) are > identical. > So, if one ep supports that particular rt, I would expect that all eps do. > > Do you want to extend the group concept? or suggest text in the group > specification? Just to be clear. The rt parameter is not included as far as I can tell in the group registration process. Doing a query based on this parameter would require looking at the resources registered for one or more endpoints in the group. My initial assumption was that the query only looked at attributes that were assigned to the endpoint itself and not to the resources of the endpoint. I am also operating under the assumption that the attributes assigned to an endpoint are the query parameters that were provided when the resources were registered. This means that one could include an rt query parameter when the endpoint was registered which would be available for filtering of endpoints. Even doing a query based on the endpoints is a bit odd depending on how you design the data model. Is there a query on all groups - i.e. give me the list of groups which meet this criteria (1), or is there only a query on membership of groups - i.e. give me all endpoints that are members of some group and meet the following criteria (2). (1) GET /group-lookup?group-type=beta (2) GET /group-lookup?et=alpha I am not sure why you would make the assumption that all members of a group are identical. Consider a lighting group. Members of the group would include not only the light bulbs but also the switches as well. It might even include some type of alarm monitoring device which might take an action based on a command issued on the group. > > > > > A similar question exists for the "res" query parameter. For a group, > > does this mean that the multicast address is being matched or a > > resource for some endpoint in the group is being matched? > > Is that answered above? No this doesn't really. Consider the items below. (1) says that it was to know the group which is at given multi-cast address. (2) says give me the set of endpoints that are in a group and which have a resource registered which starts with the string "/lights". It is not really a good thing to try and support both of these so a choice really needs to be made. Again - what is the data model. (1) GET /group-lookup?href=coap://multicast-address (2) GET /group-lookup?href=/lights* Jim > > > > > You need to look at each of the items and determine what it means for > > each lookup resource type and identity it for the reader. > > > > Jim > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 15 15:21:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F107D133224; Fri, 15 Sep 2017 15:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 kq7Nhj20krkR; Fri, 15 Sep 2017 15:21:09 -0700 (PDT) Received: from mail4.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 DD16D120724; Fri, 15 Sep 2017 15:21:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505514026; h=from:subject:to:date:message-id; bh=rWLqErmPOsy59ua2cr0w0EOj/va08GfWGtvPo4hK1hM=; b=PsXv69O9N6Z+zSXfGKmKpxJaw5dYFfXLfFxesnH9HQoieAyboQMwMYP9Ise4hrh0RGv0Ow7000x PjY5Tn6TgV1dfO2WBKHjhEsL+i2a62gmTYN4xrZWEDaJ6Km6A2aVMk1T8kc3oN7ovhI3Yg4Rs4SU3 1Ort48ZBhRzlv4wH6NJZt0eYCgLC9JI6gThCS3ZwEhcZoVhs0Q5g8MyYaIWwwMjTELpvnCQxB5UVx zHBQuhI3zaT7ZIADhzhGOqXGL4lz4rUkJm50wbjn/E1QNih1i9BgxmIlhGbMD7tjUklKvPqQW02O8 9sct5lslgPmS0zH2o63qYrlIx/SItOlrzJFg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 15:20:25 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 15:20:23 -0700 From: Jim Schaad To: CC: , References: <003b01d32996$c2c35210$4849f630$@augustcellars.com> <6a9614c27dd85afdedf4f607e5357289@xs4all.nl> In-Reply-To: <6a9614c27dd85afdedf4f607e5357289@xs4all.nl> Date: Fri, 15 Sep 2017 15:21:00 -0700 Message-ID: <00fb01d32e70$eaedbc60$c0c93520$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ6/epcu2VSc4eY4rH24pLOWy1UDgIDiyRNoVbIb4A= X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [core] Resource Directory - Group Processing 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, 15 Sep 2017 22:21:10 -0000 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Friday, September 15, 2017 2:34 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > Subject: Re: Resource Directory - Group Processing > > Hi Jim, > > see below. > > Jim Schaad schreef op 2017-09-09 20:09: > > I am going through the group processing and I have the following > > issues: > > > > 1. There are no methods defined for modifying the contents of a group. > > There is only a method for replacing the contents entirely. Is this > > intentional? > > In the beginning, yes. > You suggest to specify a PATCH? I am not suggesting anything. I am just trying to verify that what is specified is what you want. I think that it might be nice to be able to do an "add" of an item without replacing the entire set and potentially ending up at a different returned location-path which means anybody who has memorized it is messed up. > > > > > 2. The description of the context parameter looks to be a cut and > > paste that you did not review. If the parameter is absent, I do not > > believe that it makes sense to try and infer a context. My assumption > > is that a context is only going to supplied in the event that a > > multicast address is associated with the group. > > I concur with you. > Suggestion to remove con parameter from gp interface. > > > > > 3. Similar to the request for a GET on the resource directory to get > > the list of resource registries, I believe that you should have a GET > > on the group directory to get the list of group registries. > > As suggested in your earlier e-mails to do a GET on the registrations, and add > the gp option? Not a gp option, but a gp attribute so the return would be ;gp="group1" Jim > > > > Jim > > Cheerio, > > Peter From nobody Fri Sep 15 16:15:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED265126DD9; Fri, 15 Sep 2017 16:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 WlZTcpOX9eNd; Fri, 15 Sep 2017 16:15:08 -0700 (PDT) Received: from mail4.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 A4430124207; Fri, 15 Sep 2017 16:15:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505517263; h=from:subject:to:date:message-id; bh=c9H0jTVaNllkreBp48obqDPafV/iVMM2VAQUAGqX7RE=; b=H8CzHm9sp2SiehxiHxXs5wvuLycdUnE65z93uk+D55ic6rNK/BrS593FLy64V/NC/0GzMZsTa+7 QAkT8YX2TwwsTS3jfobnRNHp950bmnLA8sI3Hr/yl8cOH813B8gXvsxjVSYjzpUiDO7rr2Xnvfxf7 99EUNW7VgXMchOV4dsVSjS+aftckvq5vJNMYV40YAprrl4LtTDip1OezIlcZbipGRCxGC3tmP+tGl ayvFbERpwhYk3AD6lcHfHTpHA+EtFquC4rYtHtsAzNQLiPGpt9WMk87c9FOEz9CLrWTBN/V8++ohD KyMfSB/dqt4J9QwY8l1HqDSdZ/xgKKRmfr2g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 16:14:16 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 16:14:13 -0700 From: Jim Schaad To: CC: , References: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> In-Reply-To: Date: Fri, 15 Sep 2017 16:14:51 -0700 Message-ID: <00fc01d32e78$708ba6f0$51a2f4d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFxsMKpl038uX9mtS35w8UdkYJvBwHyN3jgo2n7pcA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Resource Directory - Returned items from Lookup resources 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, 15 Sep 2017 23:15:10 -0000 See inline > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Friday, September 15, 2017 2:49 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > Subject: Re: [core] Resource Directory - Returned items from Lookup > resources > > Hi Jim, > > Again thanks. You mention controversial subjects; and I am going to present > my opinion. > These issues are also related with the properties of the anchor parameter. > I am looking forward to reasoned alternatives by co-authors. > > Jim Schaad schreef op 2017-09-08 22:47: > > I am trying to figure out what items are going to be returned from a > > lookup query and I do not believe that the set of items in the > > examples is what should be followed. > > > > 1. I am going to assume that all attributes registered with a > > resource are going to be returned with the resource. > > An attribute can have zero values. In that case (IMO) I assume nothing is > returned. I don't understand what you mean by an attribute which has zero values. Do you consider presence to be a value? I.e. consider the "obs" attribute, it has no value but it can either be present or absent. This was just a statement say that if an attribute was set when it was registered, then it should also be returned as part of the data for the resource. I don't think this is a very exciting idea, just common sense. > > > > > 2. I am unclear if the context is what should be returned as the link > > address for an endpoint or if it is just the scheme + authority (i.e. > > omit > > any path portion). > > I find the concatenation of "con" and "href" values, as currently suggested in > the examples, also difficult to understand. > IMO the href value should be returned between <> brackets, and the con as > an additional attribute. I would find that logical, even if it makes the client side more difficult to build the entire URI. > > > > > 3. For the domain and group lookups, is the href an empty string or > > is it absent? This does not make a different for the standard link > > formation, but it does make a difference for the cbor and json > > formats. > > @ Michael can you answer, being involved in the link-json document > > > > > 4. I assume that the 'et' parameter should be returned on all end > > points. > et can have no value; IMO do not return anything. Do you mean, do not synthesis a value from the registration and add it? That would be fine with me. > > > > 5. How would an empty domain name be returned (this is my current > > pre-configured default domain) - as an empty string or as just the > > attribute name - i.e d or d="" ? > > Actually the d= can have no value, and IMO like et, do not return anything > when there is no value. I think I understand this. Jim > > > > Jim > > > > > cheerio, > > peter > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Sat Sep 16 05:37:12 2017 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 7F1A0132D42; Sat, 16 Sep 2017 05:37:10 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150556543044.4842.16551616419802276404@ietfa.amsl.com> Date: Sat, 16 Sep 2017 05:37:10 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-interfaces-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: Sat, 16 Sep 2017 12:37: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 : 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-10.txt Pages : 27 Date : 2017-09-14 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 the concept of function sets to specify this set of interfaces and resources. 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-interfaces-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-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 Sun Sep 17 08:43:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421DC1321DC for ; Sun, 17 Sep 2017 08:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 oZ6j8ga_fNif for ; Sun, 17 Sep 2017 08:43:23 -0700 (PDT) Received: from mail4.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 9D6F713304E for ; Sun, 17 Sep 2017 08:43:23 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505662958; h=from:subject:to:date:message-id; bh=l08T5Mt1QrOsr6r1xBy4axnA8YB+/+nZte/E8pUrudo=; b=aip8nM/AClMk0Oc0vcpbXLkif3mYP/zvF1elKzkZmqcDygLuoNT9LBQASsN1idYeSYQJegnuoUt ueiiax912tTZx/Ny2qpxp3v7AfPHAki0sUQTzYhTTwFoBN4P+qa4/7O7tj8kLDAiaOOEbjEDdiL5o WcLfp9MkKjzjNbsQN7JE4r0NqSZwYp1e6cLuaTC9Yn9aL0ehg02ql6tx4Cj2M7fIuNVHHYAxaUZHb aCFLtvTkq6rZ5jr5EZOUTFWX7pMgdsUGQolo00nL8MZrVeE3/8PQ1oadD2na2t3e6lx3GWAKgU4kl LhJb98HrgszaTFSVziD3+cT8dEu6r74yqlEg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 17 Sep 2017 08:42:37 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 17 Sep 2017 08:42:33 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> In-Reply-To: <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> Date: Sun, 17 Sep 2017 08:43:11 -0700 Message-ID: <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLkcV5/cuYwYNvq7zdAWu7g9fdkoQDl1w1UoI+AzVA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization 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, 17 Sep 2017 15:43:28 -0000 I had to stop and wait before responding because of frustration. I complained that this was not a good sorting order before RFC 7049 was = published, so this is not a new issue. I wish that I could find the = mails from the time as my memory was that you said we could discuss it = on the next version which is what I am trying to do. > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Saturday, September 16, 2017 2:08 PM > To: Jim Schaad > Cc: draft-ietf-cbor-7049bis@ietf.org > Subject: Re: draft-ietf-cbor-7049bis - Change suggested = Canonicalization >=20 > Hi Jim, >=20 > On Sep 16, 2017, at 22:59, Jim Schaad wrote: > > > > I have never been happy with the suggested canonicalization steps = for > > dealing with maps in this document. I would like to suggest that = the > > following algorithm be used in its stead. > > > > > > * Key/value pairs are sorted from lowest value to highest. Sorting = is > > performed on the bytes of the representation of the key and value = data > > items. The sorting algorithm is: > > > > 1. For every key value pair, encode the key and encode the value = and > > form a single byte stream by concatenating the key and value encoded > values. >=20 > Why do you think the values need to be in there, too? > Map keys must be different, so the value never can have an effect, That is from below - where you could have multiple duplicate keys. It = is very possible people will do this even if it is not a valid encoding. >=20 > > 2. Sort the resulting byte arrays in (byte-wise) lexical order. = This > > is the standard memcmp sorting order. >=20 > (The reference to memcmp works because one key cannot be a prefix of > another key.) >=20 > > This has the following benefits. > > > > 1. The algorithm used to sort the byte streams is the expected one > > for most people. >=20 > Right. >=20 > > 2. In the event that a key occurs multiple times, there is still a > > canonical ordering for the map which is reproducible. >=20 > I don=E2=80=99t think there is a need for a canonical encoding of = things that aren=E2=80=99t > canonicalizable data in the first place. >=20 >=20 >=20 > Now, if it were mid-2013, I would just agree with you, change the = draft, and > ask the WG (at the time appsawg) whether there are any further = comments. Given that you did not agree with me at the time when I raised this = issue, I would disagree with this statement. >=20 > Unfortunately, CBOR has been out there, we are on the way to an = Internet > STD, and the current canonicalization is what=E2=80=99s implemented = (at least in a > couple of places). If we change this, we have to take = canonicalization out from > the STD and put it into a separate specification. > We could decide to do this, but I=E2=80=99m not sure that this helps. = (We=E2=80=99ll also have > the CER vs. DER situation again.) I do not believe that changing this would in any way stop the = advancement to STD. This section is completely non-normative there is = not a single normative statement in the entire section. Nor is the set = of rules complete given that there are two paragraphs at the end which = have additional rules that "might" need to be added. Making this one = change would not alter the fact that it is non-normative and incomplete. There is a possible multiple encoding issue that may come, but that is = already implicit in the text of this section. The current text reads = "Those protocols are free to define what they mean by a canonical format = and what encoders and decoders are expected to do." Which means that = multiple encodings are already not only possible but probably. I think = that we can get this fixed now and go forward with an obsoleted = suggested canonicalization and be fine. The suggested algorithm is far easier to understand, easier to get right = and also has some advantages where one can do the canonicalization = without having to do the encoding first. int CompareNodes(node1, node2) if node1.majorMode !=3D node2.majorMode then return node1.majorMode - = node2.majorMode; if node1.majorMode has a length field and node1.length !=3D = node2.length then return node1.length - node2.length; return compare node1 and node2 values - this is major mode dependent. With the current method, you need to do a lot more work to try and get = things in the correct order if you have any mixing of major modes, which = is now very common place despite the statement that this is probably a = bad practice. If you have to emit all of the keys, sort them and then = remember the original order to emit the values, it is harder than = concatenating the entire thing and then emitting the values after doing = the sort. You are going to need to keep some type of more complex = structure - and thus more code- to do the emission in the generic case. = Yes for a small fixed set of keys this is not necessary but I do not = believe that is where a good canonicalization routine is going to be = needed. I strongly urge that this change be done even if it might hurt backwards = compatibility and the sooner we make the decision to do it the better as = it reduces the number of people who will do it wrong. jim >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Sep 17 11:08:13 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1E01332D7; Sun, 17 Sep 2017 11:08:05 -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 LmGtg12X-LDj; Sun, 17 Sep 2017 11:08:03 -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 07F171330AE; Sun, 17 Sep 2017 11:08:02 -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 v8HI7lDh008553; Sun, 17 Sep 2017 20:07:47 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xwHDM0dbxzDKxp; Sun, 17 Sep 2017 20:07:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> Date: Sun, 17 Sep 2017 20:07:44 +0200 Cc: "core@ietf.org WG" , cbor@ietf.org X-Mao-Original-Outgoing-Id: 527364464.771584-3e05479fb7064d689c23e5b2f8940562 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization 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, 17 Sep 2017 18:08:05 -0000 Hi Jim, I do share your frustration a bit, because I do believe the canonical = map key sorting order is one of the very few things we didn=E2=80=99t = quite get right about RFC 7049. The question about fixing this really = is procedurally, can we fix it, and what is the impact on people who are = now using the old order. > I complained that this was not a good sorting order before RFC 7049 = was published, so this is not a new issue. I wish that I could find the = mails from the time as my memory was that you said we could discuss it = on the next version which is what I am trying to do. I must admit I don=E2=80=99t remember that discussion (it would have = been more than four years in the past) and my mail program apparently = doesn=E2=80=99t either. (My mail program does remember errata report 4409 from July 2015, where = you did propose another sorting order.) >> Why do you think the values need to be in there, too? >> Map keys must be different, so the value never can have an effect, >=20 > That is from below - where you could have multiple duplicate keys. It = is very possible people will do this even if it is not a valid encoding. The reason why 7049 does not outright make emitting duplicate keys a = conformance issue is that, in a streaming implementation, it is hard to = check for duplicate keys. That argument does not apply to an = implementation that has to sort map member keys to achieve a canonical = encoding. So, while creating canonical encoding, the implementation can = also check for key duplication and raise an error if that happens. >> Now, if it were mid-2013, I would just agree with you, change the = draft, and >> ask the WG (at the time appsawg) whether there are any further = comments. >=20 > Given that you did not agree with me at the time when I raised this = issue, I would disagree with this statement. Well, I probably should have said =E2=80=9Cknowing what I know now=E2=80=9D= (i.e., the degree of POLS violation that the current rules pose) I = would agree with you. (At the time, the definition we now have in RFC = 7049 appeared to be expedient.) >> Unfortunately, CBOR has been out there, we are on the way to an = Internet >> STD, and the current canonicalization is what=E2=80=99s implemented = (at least in a >> couple of places). If we change this, we have to take = canonicalization out from >> the STD and put it into a separate specification. >> We could decide to do this, but I=E2=80=99m not sure that this helps. = (We=E2=80=99ll also have >> the CER vs. DER situation again.) >=20 > I do not believe that changing this would in any way stop the = advancement to STD. =20 Now that (i.e., just going ahead and changing things here) is an = interesting thought. One problem with that is that in the IETF, the IESG is the gating = function, and it is sufficient for a single member of the IESG to = disagree with this thought to hold up the process. > This section is completely non-normative there is not a single = normative statement in the entire section. Nor is the set of rules = complete given that there are two paragraphs at the end which have = additional rules that "might" need to be added. Making this one change = would not alter the fact that it is non-normative and incomplete. Filling in those blanks might be another argument for going ahead and = writing a separate document about canonicalized CBOR instead. > There is a possible multiple encoding issue that may come, but that is = already implicit in the text of this section. The current text reads = "Those protocols are free to define what they mean by a canonical format = and what encoders and decoders are expected to do." Which means that = multiple encodings are already not only possible but probably. I think = that we can get this fixed now and go forward with an obsoleted = suggested canonicalization and be fine. >=20 > The suggested algorithm is far easier to understand, easier to get = right and also has some advantages where one can do the canonicalization = without having to do the encoding first. >=20 > int CompareNodes(node1, node2) > if node1.majorMode !=3D node2.majorMode then return node1.majorMode = - node2.majorMode; > if node1.majorMode has a length field and node1.length !=3D = node2.length then return node1.length - node2.length; > return compare node1 and node2 values - this is major mode = dependent. >=20 > With the current method, you need to do a lot more work to try and get = things in the correct order if you have any mixing of major modes, which = is now very common place despite the statement that this is probably a = bad practice. =20 Indeed, this is one thing we have learned since 2013: There are quite = good reasons for mixing major types in the keys of a single map. > If you have to emit all of the keys, sort them and then remember the = original order to emit the values, it is harder than concatenating the = entire thing and then emitting the values after doing the sort. You are = going to need to keep some type of more complex structure - and thus = more code- to do the emission in the generic case. Yes for a small = fixed set of keys this is not necessary but I do not believe that is = where a good canonicalization routine is going to be needed. Here is my implementation of a pre-canonicalizer for maps from the = cbor-canonical gem (the type =E2=80=9CHash=E2=80=9D in Ruby is an = order-preserving map, so we can do all this entirely at the data model = level): def cbor_pre_canonicalize Hash[collect {|k, v|=20 k =3D k.cbor_pre_canonicalize v =3D v.cbor_pre_canonicalize cc =3D k.to_cbor # already canonical [cc.size, cc, k, v]}.sort.collect{|s, cc, k, v| = [k, v]}] end A sorting rule that is entirely based on (byte-wise) lexical ordering = would enable pre-sorting on types =E2=80=94 there often would be no need = to generate the entire key encoding for sorting. But then, you have to = generate them anyway, so the additional overhead is mostly a matter of = memory allocation/copying. Here is an (untested) implementation of what I think you are proposing: def cbor_pre_canonicalize Hash[collect {|k, v|=20 k =3D k.cbor_pre_canonicalize v =3D v.cbor_pre_canonicalize cc =3D k.to_cbor # already canonical [cc, k, v]}.sort.collect{|cc, k, v| [k, v]}] end I.e., the size of the key encoding is removed from the list of things to = sort for. > I strongly urge that this change be done even if it might hurt = backwards compatibility and the sooner we make the decision to do it the = better as it reduces the number of people who will do it wrong. Now whether we should do this or not is a good question for the CBOR WG = to look at. (I=E2=80=99ve added the WG back to the recipient list.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 18 00:12:16 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14E11341F6; Mon, 18 Sep 2017 00:12:14 -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 YEaCzPlD5PVk; Mon, 18 Sep 2017 00:12:13 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 EDBF71341E5; Mon, 18 Sep 2017 00:12:12 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id h66so16276328ioh.11; Mon, 18 Sep 2017 00:12:12 -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=x7DEPw8amN6eaW/kCQzhrFuoZ9yJpgJs8RVPmqumgGU=; b=LoJoiC8yXThkV7PJ3Wl15BZbp3Bga+X3DkMuKbI75Di8SSffPRoM8t+blkHqJwoE2G tsK6NkuzVAC9rtQlDkuB1G14UZ0PL56rlYAgVLLAZK5NBHjacDAi8wgd8Ut0FnbD33NO 5KjKa44+b75uLTcor5wKT+/NXGrFgxh/hCqYxzZdc4LNFnHxgKSg7wewBzJJ1QJ1vSQS 4lbPdWYNAxIc+eHvCx2Pux57t9ymB1LUXiY5IjRbi0L5kGnxreqdeIEKEI+3zEyuJMag br1CJ4uvBHKWMXKi4YpsGO7Zk81OEd9I925DnV+frZrQifkY13e9nOCmux0aBEcmbS2U W29Q== 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=x7DEPw8amN6eaW/kCQzhrFuoZ9yJpgJs8RVPmqumgGU=; b=ZDfJ/XgGhzU+F1bxB9NQgkdiRxJbDn8rqXGOH/8iWPXxVXd8mK1eZOMqUwiuhc2o65 Ovm+7hXbZcgQ8abL/VMhgP/1oKnsnryTF6GolfO5Rr+n3ZhTWoHsVVKvSmE5pi6MO9Ka rLwsg2glg6ZNKKqzXPcCd1T8UegtinvPwo4szCqkYDNYAVlfJIf2Kviyyowa/Jgxa1lF WPJaTIoUAIKM5R51P0nGFNxsO4Q/KSbRnOP9yzpldHN9epIpIGRsZHos1jdDKmcN6yot blSwqh03k9Nno+jlo086tJrWHOIhccyH9p/nCVTw5EDwsCpGtWdFkkI3ons7EN3mM0lY 1g7A== X-Gm-Message-State: AHPjjUimDSkg1Q73vG0d50wXdWca9aFK2emNNYuItldlQ5DSVcp+r/5D 9WELoNPuwFc9ULhLZiU= X-Google-Smtp-Source: AOwi7QCgsAGCXikd5bP7xwtI90+jACeMeK6yD8e7zFGyyVaUwfjb/vmn36xfVuZ/mwk7TxMNl9MWYA== X-Received: by 10.202.226.7 with SMTP id z7mr9807546oig.88.1505718732136; Mon, 18 Sep 2017 00:12:12 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id k144sm10332246oih.45.2017.09.18.00.12.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 00:12:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <018301d32c21$551bbb20$ff533160$@augustcellars.com> Date: Mon, 18 Sep 2017 00:12:07 -0700 Cc: "draft-ietf-core-resource-directory@ietf.org" , core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <552EA54D-56AD-4D66-92CE-B78FF754408C@gmail.com> References: <018301d32c21$551bbb20$ff533160$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Resource Directory - Filters on Lookup Resources 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, 18 Sep 2017 07:12:15 -0000 HI Jim, I want to start over to try to answer your questions, below. > On Sep 12, 2017, at 4:46 PM, Jim Schaad = wrote: >=20 > I am working on figuring out how to deal with the filter properties = when > working with the lookup resources and I am have problems because I = don't > understand how some of them are supposed to be applied. It may be = that you > just did cut and paste more than you should have when specifying what = lookup > resources they applied to. An idea of how things are supposed to work = would > be nice to see. >=20 > If I am doing a look up for groups, what does it mean to specify that = you > are looking for a specific resource type? Should this not be = supported for > groups or does this mean that the RD is expected to only return those > endpoints where a resource exists of the specified resource type? >=20 It looks like some updates may have been missed in the group and group = lookup sections. In addition to the points below, we should look it over = carefully again. Thanks again for the careful review. A group lookup (using the lookup resoure rd.lookup-group) returns a list = of links to group resources where endpoints in the group contain = resources that satisfy the match criteria. So if I specify a resource = type in a group query, the result is expected to be a list of group = resources where each group contains one or more endpoints that in turn = contain one or more resources of the resource type specified in the = query. We should specify that a group is included in the returned list = of groups if any link in any endpoint in the group contains a matching = target attribute e.g. "rt". The examples of group lookups need to be corrected. The "href" value or = string in angle brackets should contain the location path that was = returned when the group is registered. I think we also need to clarify = that registering a group with "con=3D" will set the multicast address = for the group and will be returned on group lookups as "con=3D" rather = than substituting the multicase address for the href location. (section = 6.1) I guess the description of "con" is a copy/paste from the = registration section.=20 I think the statement about using an endpoint domain attribute as a = group domain attribute may need to be removed. I think a group may = contain endpoints with different domain attribute values. > A similar question exists for the "res" query parameter. For a group, = does > this mean that the multicast address is being matched or a resource = for some > endpoint in the group is being matched?=20 >=20 "res" is resource name, and I'm not sure exactly what that refers to = elsewhere in the spec. I therefore presume it's a resource target = attribute that the resource can be registered with and queried on. If = so, we should provide an example. > You need to look at each of the items and determine what it means for = each > lookup resource type and identity it for the reader. >=20 Yes, good point. We need to enumerate more of the matrix with examples. = I believe all of the cross product of query parameters and lookup types = are legal and sensible, but will look it over again and provide some = more examples. Best regards, Michael= From nobody Mon Sep 18 00:14:20 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95E913420D; Mon, 18 Sep 2017 00:14:18 -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 iRATVJOB0UD8; Mon, 18 Sep 2017 00:14:17 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 8A42113420B; Mon, 18 Sep 2017 00:14:17 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id e189so16491626ioa.4; Mon, 18 Sep 2017 00:14:17 -0700 (PDT) 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=u0AWAzkDwXSNQPFalOIMCCJ86LdS+c5CYLiZUl8wuUM=; b=RpWaABu/lCbgFV7iPndcPIRbhx1JfnlqguE7gfoQpHKYYqHVe2fhX+As5F9gL+IzGf gv2laVBnejSJSQPb1xD6lT4CGQao7zCt9qkCLio1l/85IajILvjvDo8r2PHQeBuSHi4q ciy2XjIXcN8Dng+ST2CifnSyFKOt+E5D+uiHBcTZJZmT4i1GAcLuJ0WSV9nCA6E9YDzm ow83J6O5fP584VNLMXSKCmmqFOdylvYczudpKsYc35ihpBXzyM6V9XjScYkP8F7K9q8r Jwf4Bhmd9uR9AqBK0ByuuFN53LNWfgWNyE51igEhMft0ya95vYmTbiFiXPg7zsqS/b07 benA== 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=u0AWAzkDwXSNQPFalOIMCCJ86LdS+c5CYLiZUl8wuUM=; b=AP5pnwKD8YVNH5Vg9Oppu5vJRUUkcfMX83i3PVfTqH9or6EmrxrIhcUTtWpX7pQWLE dGs38PeUJBjfHrWlfN9RksnOTBQJzUyB/jy+LRqzegPHb7DjQhNbLgKqVg/wBiFrcea4 XxuF0SJ95dQuGkJLHWWWABRXBvAsrTmKNxYVxmbzaZv56i13dbIvVFON8VzYV9i9RnRN GSV8zO0m8/Z2Z+XxNjfxNYEPif7gLqC9eINfsVrzroYF4u3EF7hKv8WPSsDFcsAczL5y d5HkmT7/SBt/iPDAeaMM0+vot9UxhZHQeVQHkxg9KdU7FHCxTc71GCLrBHk+thIoVmCz aRIw== X-Gm-Message-State: AHPjjUifXPvWoWzf3B0apLkuxBiFVPJ0Qa/UxvXKib6mgY8S1IsiXzvS u7SJ8CMNAzXpXRZdbHU= X-Google-Smtp-Source: AOwi7QB9SrmdTr0oOhnrO2QBqxjvfzjTxs1Lph9GsAoynqcncSKGMPu/Swfkk4a4/s9s4h+BykkDqA== X-Received: by 10.202.88.137 with SMTP id m131mr1664022oib.178.1505718856922; Mon, 18 Sep 2017 00:14:16 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id y196sm8496154oia.44.2017.09.18.00.14.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 00:14:16 -0700 (PDT) From: Michael Koster Message-Id: <314E06A4-55F3-42F4-9362-F52360D9350F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3D661E66-D4BA-4767-B120-2007E4B2426A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 18 Sep 2017 00:14:14 -0700 In-Reply-To: <552EA54D-56AD-4D66-92CE-B78FF754408C@gmail.com> Cc: Jim Schaad , "draft-ietf-core-resource-directory@ietf.org" , core@ietf.org To: Michael Koster References: <018301d32c21$551bbb20$ff533160$@augustcellars.com> <552EA54D-56AD-4D66-92CE-B78FF754408C@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Resource Directory - Filters on Lookup Resources 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, 18 Sep 2017 07:14:19 -0000 --Apple-Mail=_3D661E66-D4BA-4767-B120-2007E4B2426A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry, that's resource type "core.rd-lookup-gp" > On Sep 18, 2017, at 12:12 AM, Michael Koster = wrote: >=20 > resoure rd.lookup-group) --Apple-Mail=_3D661E66-D4BA-4767-B120-2007E4B2426A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Sorry, that's resource type "core.rd-lookup-gp"

On Sep 18, 2017, at 12:12 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

resoure rd.lookup-group)

--Apple-Mail=_3D661E66-D4BA-4767-B120-2007E4B2426A-- From nobody Mon Sep 18 07:01:56 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F560134265; Mon, 18 Sep 2017 07:01:55 -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 IOxYJK8clQYv; Mon, 18 Sep 2017 07:01:54 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 A6800134249; Mon, 18 Sep 2017 07:01:52 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id k101so2310274iod.0; Mon, 18 Sep 2017 07:01:52 -0700 (PDT) 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=JCy8CPwBorx8eIWVyCstLnpJWA5nQ0xVegnAA7uQhpk=; b=ml4So4xltoshiRApgO+oY8rc07iIqA4ih/MUzoG2o4mv/PZFVjKny4WMynze/9nIdw jPtX/l2KWuqzPK8U/hI5ZCAUy6jGIY0BoYNfxt6gzDhV2OnNosGkbSDLbMdL0SCLW6kS ZTp/C5kAMIlOT9qSg+wa2LAd1RIydytZuYEo4UFuDIxT9f7Z4cvCSyLuhXj9kFHwhWQ2 vFYPoKCGG96/CadHxpCXgiOfcisQfmscYRBn4u3pZuVgLblOZzvk1Ndq8lv5a9fA7Uai eqZfupZ4VvmRZ2RZi8NdlhOZjjbDCh7ks5y/DXDsFWJtgKmEjSCMmpol9xcQ7fbAOQCJ SvJQ== 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=JCy8CPwBorx8eIWVyCstLnpJWA5nQ0xVegnAA7uQhpk=; b=JjrX1evDNM9UaeYwT75nChxid0jNpISFcfJ1yclz//cK6kmySB8mrGs+mXPp5DiDE4 xzDJWk3QkYVzIeoPGxyNXHwcXW2XCEFdNZdVjFXgZuHsFv3pkDCy3Vde2YuCcOSU4wG6 OTSMuhWQ6UPcNaaN/uI2Z8Ta5NTRjg65bWIqNMEJVD9bZCb8mRFjP/D+ENoNRKszXmVx 0bZkWduIv7V+VGzxK6ZS3PWhYbmEteVPcEV7IzNHLFaE6C3OvNvqVmtP34x+Vf86Y8ii 1kT+5T8pmGxuABetyE696ksIH4vVfoR5TWoRtZU201xZxgaxocuHSzev5rfNXj3Hfzvh DPhg== X-Gm-Message-State: AHPjjUhSOHn2z4XKsfLNGLhguOS46/eNA+tIHJmzFKmOf+B8ommS7iIx iRkS154g10AW0910CTo= X-Google-Smtp-Source: AOwi7QArcjrENqE9MsPuAapYZESOyx2tTGLEg/uh2Nkp6Eb4G76AIlrqOwA9UoYLmSigRF8LRDHATg== X-Received: by 10.202.60.196 with SMTP id j187mr17622811oia.143.1505743311848; Mon, 18 Sep 2017 07:01:51 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id m63sm486632oia.21.2017.09.18.07.01.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 07:01:50 -0700 (PDT) From: Michael Koster Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A07DDF6F-D0CD-4097-988C-3BB812B06D5E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 18 Sep 2017 07:01:48 -0700 In-Reply-To: <552EA54D-56AD-4D66-92CE-B78FF754408C@gmail.com> Cc: Jim Schaad , "draft-ietf-core-resource-directory@ietf.org" , core@ietf.org To: Michael Koster References: <018301d32c21$551bbb20$ff533160$@augustcellars.com> <552EA54D-56AD-4D66-92CE-B78FF754408C@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Resource Directory - Filters on Lookup Resources 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, 18 Sep 2017 14:01:55 -0000 --Apple-Mail=_A07DDF6F-D0CD-4097-988C-3BB812B06D5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii After a little more thought, I think we should consider to include a = table of lookup types vs. query parameters with pointers to examples.=20 Best regards, Michael > On Sep 18, 2017, at 12:12 AM, Michael Koster = wrote: >=20 > I believe all of the cross product of query parameters and lookup = types are legal and sensible, but will look it over again and provide = some more examples. --Apple-Mail=_A07DDF6F-D0CD-4097-988C-3BB812B06D5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii After a little more thought, I think we should consider to = include a table of lookup types vs. query parameters with pointers to = examples. 

Best = regards,

Michael

On Sep 18, 2017, at 12:12 AM, = Michael Koster <michaeljohnkoster@gmail.com> wrote:

I believe all of the cross = product of query parameters and lookup types are legal and sensible, but = will look it over again and provide some more examples.

= --Apple-Mail=_A07DDF6F-D0CD-4097-988C-3BB812B06D5E-- From nobody Mon Sep 18 08:19:26 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300D71342A6 for ; Mon, 18 Sep 2017 08:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lightingaad.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 4X0og5rNPfxp for ; Mon, 18 Sep 2017 08:19:20 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30072.outbound.protection.outlook.com [40.107.3.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480F4134299 for ; Mon, 18 Sep 2017 08:19:19 -0700 (PDT) Received: from AM5P121CA0002.EURP121.PROD.OUTLOOK.COM (2603:10a6:224:b::16) by DB5P121MB0024.EURP121.PROD.OUTLOOK.COM (2a01:111:e400:e2b3::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 18 Sep 2017 15:19:17 +0000 Received: from AM5EUR02FT004.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::206) by AM5P121CA0002.outlook.office365.com (2603:10a6:224:b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11 via Frontend Transport; Mon, 18 Sep 2017 15:19:17 +0000 Authentication-Results: spf=neutral (sender IP is 13.94.234.208) smtp.mailfrom=philips.com; siemens.com; dkim=fail (signature did not verify) header.d=lightingaad.onmicrosoft.com;siemens.com; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.94.234.208 is neither permitted nor denied by domain of philips.com) Received: from LIGHT-EDGE-1.lighting.com (13.94.234.208) by AM5EUR02FT004.mail.protection.outlook.com (10.152.8.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.35.14 via Frontend Transport; Mon, 18 Sep 2017 15:19:16 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (213.199.154.118) 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; Mon, 18 Sep 2017 17:18:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightingaad.onmicrosoft.com; s=selector1-lighting-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Nk85XcU4XctZ+Vvt+UlyYhZ1LOm+C7T9w7ZLpqeQoYk=; b=GDWfC3VWvamcdkL1OTisTN8smcaHCMo5EiB/v87A10N472APspsxkWAHsgbtBh60VkvMUo9axFWZQh0UDKXep5aEvuJObX0pDCCk4sR0kvI4Hgm2PdVHtwYH+8X3OWxMbpxNJ+ThxUYB8Dblbdd/UCPWfgRGlGfGUBiyGDW5E4c= Received: from VI1P121MB0015.EURP121.PROD.OUTLOOK.COM (129.75.24.214) by VI1P121MB0048.EURP121.PROD.OUTLOOK.COM (129.75.190.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 18 Sep 2017 15:18:22 +0000 Received: from VI1P121MB0015.EURP121.PROD.OUTLOOK.COM ([fe80::58da:4ab2:bc00:a5b3]) by VI1P121MB0015.EURP121.PROD.OUTLOOK.COM ([fe80::58da:4ab2:bc00:a5b3%14]) with mapi id 15.20.0056.016; Mon, 18 Sep 2017 15:18:22 +0000 From: Esko Dijk To: "Kovatsch, Matthias" , "core@ietf.org" Thread-Topic: Resource Directory vs RFC 6690 Thread-Index: AdKys6Slnkh1vPiYReSfMVxW3VUVvR9252Ww Date: Mon, 18 Sep 2017 15:18:22 +0000 Message-ID: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64@DEFTHW99EL4MSX.ww902.siemens.net> 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: [89.200.45.246] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; VI1P121MB0048; 6:PAdkk66+LGsMJ/sT2COO7kd9UCxqp+kWJxjpEUkG9k0e8FE1ek/6AkArqOiGsiUKUiZnv0bG7pWVwAKGoQyEwHHYN08Sw/aCjFkZh2wJAL3G+BWNOh6m/gEKmAJCf08azhNHMFwN9fdcnXm5mCu4uJ23hBZQsk8Am6T5ns97uAZTO/z/s6WGaxpTlAV1j/Fkytct/RyHjWXMERJk7c0oMlu4JhtvS18GtJxRqh6PgttEEqaZS8IHhYZR+K4gttiMXOm30LJjLOJ7koPw+4itsgfh/W6zV2OHZs52hkamRt4uarylzWEani3JAmZAFREmaLeZIABPc+2CcDxS9rbakQ==; 5:X996mM9cj01h3bF7+K7NNDxwpEVl5bG5ZRTpXdcG0fjfMpys2p/x66OAdSH7yeY9dVya2CWwGeboLvcLckhqFRwwOUxPu9mYGPb4e5nt8IX96FbLYZyPfDKsQmbhi58fNaJimqowrTLvcunx5VPSMg==; 24:eW6Sm6Fg39t54AXf4nt2abGcX0nZeZmmAkUppHoEE8CJu1ZctA+WBcmm6+RX6r6E5904WsExRGVV8a02IDvkWRz+YBzy1NFkrwL6D8b4mNM=; 7:w4pLJa+OoEQd7v/60ISHFA+ls6YKYw066SU50e1aZDiYDzfNkYBGxbbo+lyovuRqTerBRAP3QrFBHeH4lLg4bahSp165X6UlscDCKdi454tL+qGi4UAdGozW0FMNizOZgm56GwK/papZvupsla0gQ83n6Eh2Qg+qSaNZj3KuqrrbeqN+LnqPjS4s/8itWtJIjLf1EuW0DF1Vq1966hYfhm/RZTAn/q2f3t2PR1cBAK0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: d6cad253-33b4-409d-aa11-08d4fea8a09f X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1P121MB0048; X-MS-TrafficTypeDiagnostic: VI1P121MB0048:|DB5P121MB0024: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); UriScan:(158342451672863)(21748063052155); X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-cfa-test: =?us-ascii?Q?BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101?= =?us-ascii?Q?)(100105300095)(100000702101)(100105100095)(6040450)(2401047?= =?us-ascii?Q?)(5005006)(8121501046)(10201501046)(93006095)(93001095)(1000?= =?us-ascii?Q?00703101)(100105400095)(3002001)(6041248)(20161123558100)(20?= =?us-ascii?Q?161123564025)(201703131423075)(201702281528075)(201703061421?= =?us-ascii?Q?075)(201703061406153)(20161123560025)(20161123562025)(201611?= =?us-ascii?Q?23555025)(6072148)(201708071742011)(100000704101)(1001052000?= =?us-ascii?Q?95)(100000705101)(100105500095);SRVR:VI1P121MB0048;BCL:0;PCL?= =?us-ascii?Q?:0;RULEID:(100000800101)(100110000095)(100000801101)(1001103?= =?us-ascii?Q?00095)(100000802101)(100110100095)(100000803101)(10011040009?= =?us-ascii?Q?5)(100000804101)(100110200095)(100000805101)(100110500095);S?= =?us-ascii?Q?RVR:VI1P121MB0048;BCL:0;PCL:0;RULEID:(100000700101)(10010500?= =?us-ascii?Q?0095)(100000701101)(100105300095)(100000702101)(100105100095?= =?us-ascii?Q?)(6095135)(2401047)(5005006)(8121501046)(3002001)(1000007031?= =?us-ascii?Q?01)(100105400095)(10201501046)(93006095)(93003095)(6055026)(?= =?us-ascii?Q?6096035)(201703131430075)(201703131448075)(201703131433075)(?= =?us-ascii?Q?201703161259150)(201703151042153)(20161123556025)(2016112356?= =?us-ascii?Q?1025)(20161123563025)(20161123565025)(20161123559100)(201708?= =?us-ascii?Q?071742011)(100000704101)(100105200095)(100000705101)(1001055?= =?us-ascii?Q?00095);SRVR:DB5P121MB0024;BCL:0;PCL:0;RULEID:(100000800101)(?= =?us-ascii?Q?100110000095)(100000801101)(100110300095)(100000802101)(1001?= =?us-ascii?Q?10100095)(100000803101)(100110400095)(400006)(100000804101)(?= =?us-ascii?Q?100110200095)(100000805101)(100110500095);SRVR:DB5P121MB0024?= =?us-ascii?Q?;?= x-forefront-prvs: 04347F8039 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(39380400002)(199003)(189002)(85714005)(76104003)(189998001)(6116002)(790700001)(102836003)(3846002)(68736007)(97736004)(7696004)(478600001)(2950100002)(66066001)(25786009)(413944005)(2900100001)(53546010)(5660300001)(2501003)(14454004)(50986999)(3280700002)(55016002)(76176999)(54356999)(6246003)(7736002)(3660700001)(54896002)(6306002)(81156014)(81166006)(5250100002)(6506006)(8936002)(6436002)(8676002)(229853002)(101416001)(33656002)(316002)(9686003)(105586002)(53936002)(86362001)(74316002)(2906002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P121MB0048; H:VI1P121MB0015.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) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1P121MB0015AFC6BB829A47E2C6D0A89B630VI1P121MB0015EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0048 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131502215571830540; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR02FT004.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.94.234.208; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39380400002)(376002)(346002)(39860400002)(2980300002)(76104003)(189002)(85714005)(199003)(9686003)(2950100002)(316002)(260700001)(14454004)(16586007)(2900100001)(50986999)(8676002)(81156014)(76176999)(54356999)(81166006)(53936002)(2906002)(61614004)(6506006)(97736004)(229853002)(84326002)(6116002)(102836003)(3846002)(7696004)(5660300001)(790700001)(53546010)(66066001)(106466001)(105586002)(413944005)(74316002)(5250100002)(86362001)(356003)(68736007)(6246003)(512954002)(2501003)(33656002)(25786009)(55016002)(189998001)(956001)(7736002)(54896002)(8936002)(498600001)(6306002)(69596002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5P121MB0024; H:LIGHT-EDGE-1.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT004; 1:6BvQJ6TYKRR8t3Nlw8kdJASfeDU1jfp0vh66XLxyK4ZSrXIo8LZg8ZTr0a6OV+56SPGnaWFh91+8wbVk6HuC+YSAxI8WOuu+4EBIErmeUx3ZUu7l2FpFEtVbmP25RyuY X-DkimResult-Test: Failed X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(3002016)(300000503095)(300135400095)(2017052603199)(201703131430075)(201703131517081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5P121MB0024; X-Microsoft-Exchange-Diagnostics: 1; DB5P121MB0024; 3:eN9pJK9taeg8slmmjivpkzM/LdHoigCQhCPKiFTvTOx9NzLW9MLgxNC/JywQhqD02X9BS2SeRKpZI1moW7SvR1WZhO5SzW54J48vomrexK3E0eBlrri3mgvyPtub/sTSxiIbNxxg68nuAHfk9TsOWE+8sxkve0hx+s5yaCLyOQ7VwR57VA6lM+IkgAepbbx/laxumrN899uystBoAXS3sLkzgdDJtX/W7zu6RpGxAfWV2Eny8+IUlXPgTc1Zye/N0zvV7E2aF5QRIjNFbtZ609iojTqxZm81m6vMpITEPexdRA02qOB1N1pUI6r9LgAuP714AUh+s/JCVRvCgQ1JKp1rrcvg8gqS/K3FLNj6efM=; 25:YY6rPbhE76b/xI2AJ2SmAjJupr12a0sBG9Tlcuc/Oet+y0U61z+WYmetnSxdklAv0ydLmNkPgxROU9PCUmN/j0ImkV7C/F+YGz/4DXcykm8L3AqhFsklnfG5s2d2999+IVbVp9Euhx3h0ggk0u7A+1EtcAMSF3FnBr5tTL13NH54cNt7Gdn1uumUvDEUCNAam0yzLlEZHUehKbJ8eRezNXv7/PqtS7krEF+zFwao1kzNYx4vSD6zI++WBFQ19uG96ke+MjdgQRVA0P3bWIW84Mi0QMl2N0MU3IQrTeC1kb994NNNMh9atPP5s2GR9KXpJykaApKXuJ4Iamc3fDV7mA== X-Microsoft-Exchange-Diagnostics: 1; DB5P121MB0024; 31:RwQTqmKwoQnFawZMylyEsc7v9y+LQWWnXY6wPhLOpLta3EfeV/bHPptXzHux3JzS3irRDl2IwERcQWBdUZLIc/xR4gKeSYtef7L7E/PSN5zejpjW3cILDXX92bHZ5Th8mWN3XHnJk/K7iZ4sLu5uODc6qcWFQwlQIUDcM6EhJ/xPkwb5Y8WQ3IJsjXJ7NL/ltHe1yZT8zHWdrogFpOYnGoGYP67C3HDePVmQbIaorqI=; 4:ve2r3Y56mivh/26FVkwcLd9qX9/PnrBFjRMe05ClgJ3wNzXG94ecBLsW8RlDu/YyVi4iJ9gZKwar2/OyQhGQZJ4VbHlKBHiqkt0GIv+gmShMiFj0ThIeRnygIGCLoOnKXZUdCs0PcNjAxUU1fGNIWbvctAA+J8wcRVYrKhpCUVhtPmXKen3XrA4mCuBK1fsOIyAihNEgt3pFW2lZ2mc/Pe9F4pC3gXZDibHEK0kGa3iSjtUqsAKAW6q+kaqHwpyClxW6Uc06OIS8jKJkU8UesKih8pYRsU4s2l8vvCJns+EpuSvJv9LJgL7LqtDDw2RCnTtPYVeS5UbnHhAzxS2d9Q== X-Forefront-PRVS: 04347F8039 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5P121MB0024; 23:c4QNw4iXIL7MksOOPjZg+0G4Mvfyl8ITRZuLYS8vN?= =?us-ascii?Q?xAQdOw2xJe2PMhlhrbywRvg9fCp4Kxj2ihA8SPFsAdgJ0WaL8dnHvTFO7LId?= =?us-ascii?Q?Tf8BAvHTRxPXpopuQZbyDYhqcANS3aJPNykvtkDtY6ecpW5+ixdvj4ipyI9J?= =?us-ascii?Q?wEwlNN5BFucLYoYde0YKt7i1S6FSKy/ZakVIfATNJnIcuGzTREsgXYZNVJeX?= =?us-ascii?Q?46Dye8v1vpJCc/o9Q2uqXIuGocCvmztfh47sThrWuzfA7yAehv31DtVO5UUS?= =?us-ascii?Q?aP8MaCmmEa8dF7IZdkeUT0v2hvCmuqSceZAt2l0UxUIF9RcGB9OcQ75UcrP4?= =?us-ascii?Q?2ORd/JQsO55S0fzdRntcdossj+cZmC9b7InVYVGx8A6D11/LnzI43U8ruXik?= =?us-ascii?Q?9/Di1KFUhQPbZuBeXvwcSapgql6lll4+fL4+ZOQFC7dItL0lI25k2katWhS0?= =?us-ascii?Q?1r1a0rabQAbg2LPeztnvK0UNNWSEyivD1w1oGjlv+hZ/e3N8wJGeCfqN6j1Y?= =?us-ascii?Q?boc6Lh/vgoCRb4XyUM+2jF7Fl0CAM5wJHP4yTpJ7yE8g9AAf8jKMFTtPo4ts?= =?us-ascii?Q?BUbgmra2BYQ8ZOY9lk/O/nSdRKrwMiSbJjPIqbGpdnIGg9PAiPlCIIvTC3Ls?= =?us-ascii?Q?RHuo+Hw5xuBG0xbGL/+u4r78fIW/+7MtFhnTClX+uX44MdFtNorSU3I3YZvR?= =?us-ascii?Q?wZKzoaUM9UNxzUJn2fFz+E9DLQc3DHn6903bgGgvVPLxc67Em1xSASZD2Kls?= =?us-ascii?Q?2vf9YlRiw08Xs0J+ld6REqTHs75y+gKnnZcOWhUzUEjZFaUv/Dcjj/dnhy72?= =?us-ascii?Q?/SHgXASJcqVR1aL/zndPMBTOpdhrRLXTapCfS38EFKK4RuI+HliIBnzhOMEt?= =?us-ascii?Q?+g8lzDsKqVzVSCQ2tJpPLMGEeWsJy7I/5YxhOmk8SBf/JuQr+irq1IA8ijvM?= =?us-ascii?Q?khhhmtvqzvxa1UYlg4H9We21ScYm97OIbGfTX+WYl/ehs7VPsKUCWtoEtJMd?= =?us-ascii?Q?84X9eChqJ1ACIA41M+/rU4p/lZPe7J0sugFuHgzVRoPmZiZnLwNX3MJn0Ha2?= =?us-ascii?Q?9CiSJp+JSm50ATYzaSdiBLw9uqJE7J8uAoc1xvSOKTj168BSc/v5xBqwWEOi?= =?us-ascii?Q?Xg78ZKOQz6aVR36rw9fQD1p27Cp7NHD5Xve4i6YRh1wfG2h8Ws9VKS3DW1PI?= =?us-ascii?Q?xt2vNdcSnSvoGadOm/5+e04xQ/huaSF5ASOG8BYrF8J+GL1mm7GIb0YPEVtj?= =?us-ascii?Q?YbeHlyh9wyTfc52pbfnPoce6AvsJ8vdgM5XLw4xrm7v2ClR1eR0OPvCdjewt?= =?us-ascii?Q?V462sS8NzzvqqqG+QM/8tQZvhOVwebx26AWUgWSEkZXgGw5f+ahX9/Ubrcqg?= =?us-ascii?Q?4n0Bof+OBU+FOafzMSIGrhQ7tekvYNnc5qEFA0fl13c2mJz?= X-Microsoft-Exchange-Diagnostics: 1; DB5P121MB0024; 6:xZ6gSQYW5UyRpjxx1SNfFBJb0wC1rA0KK4dZiJsaWiQgdSNua+FeY/UMWzGjPUX3kX7fuOFjNcd9n/TiADmO0CfCG+4AU3gJQTP9eV0ulMKMwMtLcLfLk6rbWxdSfgsF3k6AXJkc8tra0whqSXdVd73RAI3rCZixDP3BjsVjKrB4ldZ/qL3dysKrpo53AV7DHXq1JR61X44qsh9BzijvjOMG33jzNsmTudz9BH2b5VOsAdooWFXML1n0caqdxdLH2HvHWB7Xah/YR8uvJFSicLLltLJul4FUrTwvmT0N+q9UHnQuO4D/h79CeyHMq3xIOfFSdh7/6ECiq4sCNTCGog==; 5:c0UdFYY7xdrjehnWoStS1v9RjQzt+wB6DQNKxnGndDrkUqaHpU+5hbVGF7krdhbR+PV6C4h0JR/DIjL1KovuOGfDYY1D7uz9bwsvpPn2iQvKeRRHTh0Qm5j/oRPsFlgjDDx8FNm2y11wIAfX6Rd59g==; 24:jtogZymoU/o5yVQaWdQ+zC5B79789iLiOwr2M+sRlgE+atjFNbhgsN47ohUlBoUqUzznB7wUENMBYChjF7v2U+y1MyYT78BjM9jES2xlDmo=; 7:tJFv4uJ0BiS7pdNowMAvXw4nuxgUFjDPVE34DAcDvIzIgi/HPq4IpZPC0MO4nh8bIxLxQYS+ac5pLlv6Fjk8rBn77aTb7uJ7W6pPvwWJigSe+8kHXZv5tIvS5MDEL9Sfr2RiVWzR7r9a/0ErJ+0eTIAKy6xtrOwcsRDBGhTXoXAGK6xqnCEj21eKh4rPplPIDp4365H0mQJ43YsASZ6Qf2y77UtU0tuCxQKNr4vcRuc= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2017 15:19:16.8080 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.94.234.208]; Helo=[LIGHT-EDGE-1.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5P121MB0024 Archived-At: Subject: Re: [core] Resource Directory vs RFC 6690 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, 18 Sep 2017 15:19:24 -0000 --_000_VI1P121MB0015AFC6BB829A47E2C6D0A89B630VI1P121MB0015EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Matthias, WG, Indeed the query formats are currently defined differently for RFC 6690 (i.= e. potentially very constrained CoAP server) and for draft-RD (i.e. typical= ly a resource-rich CoAP server). That makes sense to me; and we do not want= to inherit the very limited RFC 6690 behaviour of a single query parameter= into the RD. The RD could benefit from more powerful query expressions us= ing multiple query parameters, AND-ed together. The interoperability problems could come when people try to send multi-para= meter queries to /.well-known/core , the handling of which is currently not= specified at all in RFC 6690. In fact this industry alliance wants to supp= ort multiple query parameters *both* for RD and /.well-known/core queries ;= ) The above brings up the issue that RFC 6690 does not specify what to do wit= h a multi-parameter query on /.well-known/core. Since it does not match th= e template exactly it's out of 6690 scope it would seem. Possible behaviors= for a RFC 6690 compliant device, that supports the 1-parameter query only,= are: 1. Return full resource list (device decides "I do not support this form= of querying" and falls back to the "don't support querying" case in RFC 66= 90); 2. Return filtered list, only first parameter used (this is the "let's m= ake the best of it, it looks roughly ok" approach); 3. Return an error (4.xx or 5.xx); 4. Suppress response (only possible for multicast request); 5. Undefined - up to implementation (this is the current state I believe= ) This might be clarified as an erratum to RFC 6690. Option 2 looks good to i= n case there are additional query parameters i.e. the RFC6690 template with= a multi-element list. Option 3 looks good in case the query does not match= the template at all i.e. the server can't get a valid single query paramet= er out of it. Regards Esko From: core [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch, Matthias Sent: Tuesday, April 11, 2017 13:06 To: core@ietf.org Subject: [core] Resource Directory vs RFC 6690 Dear list, dear Michael While talking with people from an industry alliance building their standard= on CoAP, it came up that RD lookups need to support multiple query paramet= ers with an AND conjunction. draft-ietf-core-resource-directory-10, Section= 7 supports this: "Multiple query parameters MAY be included in a lookup" It might be clearer to also mention the logical AND conjunction here. The confusion for this requirement mainly arose from the Link Format RFC 66= 90, Section 4: "/.well-known/core{?search*} where the variable "search" is a 1-element list that has a single n= ame/value pair" The lookup on /.well-known/core only allows a single query parameter. This = was decided to not demand too much query processing from constrained device= s. The query feature is overall a MAY, that is, it might not be implemented= at all. That means, also links that do not match the query could be return= ed. This is in conflict with draft-ietf-core-resource-directory-10, Section 7, = where it says further: "all included parameters MUST match for a resource to be returned." I say conflict because we should have the principle of the least surprise. = RD res-lookup and /.well-known/core are very similar. The latter could also= offer the same filtering as RD based on the server's resource(=3Dlink) att= ributes. Furthermore, I think the "MUST match" is inappropriate. It must be up to th= e client to select the correct link. Just compare it to Google, where besid= es irrelevant results also ads are included in the results and it is up to = the user to decide which links to click on. While I fully understand that t= here is usually no user involved, it would make a more robust system, when = the client has the responsibility to select the appropriate link and not bl= indly the first one because it trusts the MUST in a specification. What do you think? Should we file errata for RFC 6690 and fix this? Did I miss updates from RFC 7252? Ciao Matthias ________________________________ 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_VI1P121MB0015AFC6BB829A47E2C6D0A89B630VI1P121MB0015EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Matthias, WG,

 

Indeed the query formats are currently defined diffe= rently for RFC 6690 (i.e. potentially very constrained CoAP server) and for= draft-RD (i.e. typically a resource-rich CoAP server). That makes sense to= me; and we do not want to inherit the very limited RFC 6690 behaviour of a single query parameter into the R= D.  The RD could benefit from more powerful query expressions using mu= ltiple query parameters, AND-ed together.

 

The interoperability problems could come when people= try to send multi-parameter queries to /.well-known/core , the handling of= which is currently not specified at all in RFC 6690. In fact this industry= alliance wants to support multiple query parameters *both* for RD and /.well-known/core queries ;)

 

The above brings up the issue that RFC 6690 does not= specify what to do with a multi-parameter query on /.well-known/core. = ; Since it does not match the template exactly it’s out of 6690 scope= it would seem. Possible behaviors for a RFC 6690 compliant device, that supports the 1-parameter query only, are:=

 

  1. Return full resource list (device decides “I do not support thi= s form of querying” and falls back to the “don’t support = querying” case in RFC 6690); 
  2. Return filtered list, only first parameter used (this= is the “let’s make the best of it, it looks roughly ok” = approach);  
  3. Return an error (4.xx or 5.xx); = ;
  4. Suppress response (only possible for multicast reques= t); 
  5. Undefined – up to implementation (this is the c= urrent state I believe)

 

This might be clarified as an erratum to RFC 6690. O= ption 2 looks good to in case there are additional query parameters i.e. th= e RFC6690 template with a multi-element list. Option 3 looks good in case t= he query does not match the template at all i.e. the server can’t get a valid single query parameter out = of it.

 

Regards

Esko

 

From: core [mailto:core-bounces@ietf.org] = On Behalf Of Kovatsch, Matthias
Sent: Tuesday, April 11, 2017 13:06
To: core@ietf.org
Subject: [core] Resource Directory vs RFC 6690

 

Dear list,

dear Michael

 

While talking with people from an industry alliance = building their standard on CoAP, it came up that RD lookups need to support= multiple query parameters with an AND conjunction. draft-ietf-core-resourc= e-directory-10, Section 7 supports this:

 

        “Multiple= query parameters MAY be included in a lookup”

 

It might be clearer to also mention the logical AND = conjunction here.

The confusion for this requirement mainly arose from= the Link Format RFC 6690, Section 4:

 

        “/.well-known/core{?search*}

        where the varia= ble "search" is a 1-element list that has a single name/value pai= r”

 

The lookup on /.well-known/core only allows a single= query parameter. This was decided to not demand too much query processing = from constrained devices. The query feature is overall a MAY, that is, it m= ight not be implemented at all. That means, also links that do not match the query could be returned.

 

This is in conflict with draft-ietf-core-resource-di= rectory-10, Section 7, where it says further:

 

        “all incl= uded parameters MUST match for a resource to be returned.”

 

I say conflict because we should have the principle = of the least surprise. RD res-lookup and /.well-known/core are very similar= . The latter could also offer the same filtering as RD based on the server&= #8217;s resource(=3Dlink) attributes.

 

Furthermore, I think the “MUST match” is= inappropriate. It must be up to the client to select the correct link. Jus= t compare it to Google, where besides irrelevant results also ads are inclu= ded in the results and it is up to the user to decide which links to click on. While I fully understand that there is usu= ally no user involved, it would make a more robust system, when the client = has the responsibility to select the appropriate link and not blindly the f= irst one because it trusts the MUST in a specification.

 

What do you think?

Should we file errata for RFC 6690 and fix this?

Did I miss updates from RFC 7252?

 

Ciao

Matthias

 


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_VI1P121MB0015AFC6BB829A47E2C6D0A89B630VI1P121MB0015EURP_-- From nobody Mon Sep 18 08:30:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C26134291 for ; Mon, 18 Sep 2017 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 T8NlkTF6uNiY for ; Mon, 18 Sep 2017 08:30:00 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 7C79D1342A1 for ; Mon, 18 Sep 2017 08:30:00 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id v8IFTwF7020057 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Sep 2017 17:29:58 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v8IFTwhR003529 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Sep 2017 17:29:58 +0200 Received: from DEFTHW99ERTMSX.ww902.siemens.net (139.22.70.200) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 18 Sep 2017 17:29:57 +0200 Received: from DEFTHW99EI1MSX.ww902.siemens.net ([169.254.3.141]) by DEFTHW99ERTMSX.ww902.siemens.net ([139.22.70.200]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 17:29:57 +0200 From: "Vicari, Norbert" To: Esko Dijk , "Kovatsch, Matthias" , "core@ietf.org" Thread-Topic: Resource Directory vs RFC 6690 Thread-Index: AdKys6Slnkh1vPiYReSfMVxW3VUVvR9252WwAACyLnA= Date: Mon, 18 Sep 2017 15:29:56 +0000 Message-ID: <5B1E2EAF1E0A324C8301DD0F01A090F28DE7CE@DEFTHW99EI1MSX.ww902.siemens.net> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.55] Content-Type: multipart/alternative; boundary="_000_5B1E2EAF1E0A324C8301DD0F01A090F28DE7CEDEFTHW99EI1MSXww9_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Resource Directory vs RFC 6690 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, 18 Sep 2017 15:30:04 -0000 --_000_5B1E2EAF1E0A324C8301DD0F01A090F28DE7CEDEFTHW99EI1MSXww9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Esko, from an IoT communication point of view, I would expect that a device is ab= le to determine that it cannot process a request correctly and thus will ac= t accordingly, i.e. option 3 or 4. best Norbert From: core [mailto:core-bounces@ietf.org] On Behalf Of Esko Dijk Sent: Montag, 18. September 2017 17:18 To: Kovatsch, Matthias (CT RDA NEC EMB-DE); core@ietf.org Subject: Re: [core] Resource Directory vs RFC 6690 Dear Matthias, WG, Indeed the query formats are currently defined differently for RFC 6690 (i.= e. potentially very constrained CoAP server) and for draft-RD (i.e. typical= ly a resource-rich CoAP server). That makes sense to me; and we do not want= to inherit the very limited RFC 6690 behaviour of a single query parameter= into the RD. The RD could benefit from more powerful query expressions us= ing multiple query parameters, AND-ed together. The interoperability problems could come when people try to send multi-para= meter queries to /.well-known/core , the handling of which is currently not= specified at all in RFC 6690. In fact this industry alliance wants to supp= ort multiple query parameters *both* for RD and /.well-known/core queries ;= ) The above brings up the issue that RFC 6690 does not specify what to do wit= h a multi-parameter query on /.well-known/core. Since it does not match th= e template exactly it's out of 6690 scope it would seem. Possible behaviors= for a RFC 6690 compliant device, that supports the 1-parameter query only,= are: 1. Return full resource list (device decides "I do not support this form= of querying" and falls back to the "don't support querying" case in RFC 66= 90); 2. Return filtered list, only first parameter used (this is the "let's m= ake the best of it, it looks roughly ok" approach); 3. Return an error (4.xx or 5.xx); 4. Suppress response (only possible for multicast request); 5. Undefined - up to implementation (this is the current state I believe= ) This might be clarified as an erratum to RFC 6690. Option 2 looks good to i= n case there are additional query parameters i.e. the RFC6690 template with= a multi-element list. Option 3 looks good in case the query does not match= the template at all i.e. the server can't get a valid single query paramet= er out of it. Regards Esko From: core [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch, Matthias Sent: Tuesday, April 11, 2017 13:06 To: core@ietf.org Subject: [core] Resource Directory vs RFC 6690 Dear list, dear Michael While talking with people from an industry alliance building their standard= on CoAP, it came up that RD lookups need to support multiple query paramet= ers with an AND conjunction. draft-ietf-core-resource-directory-10, Section= 7 supports this: "Multiple query parameters MAY be included in a lookup" It might be clearer to also mention the logical AND conjunction here. The confusion for this requirement mainly arose from the Link Format RFC 66= 90, Section 4: "/.well-known/core{?search*} where the variable "search" is a 1-element list that has a single n= ame/value pair" The lookup on /.well-known/core only allows a single query parameter. This = was decided to not demand too much query processing from constrained device= s. The query feature is overall a MAY, that is, it might not be implemented= at all. That means, also links that do not match the query could be return= ed. This is in conflict with draft-ietf-core-resource-directory-10, Section 7, = where it says further: "all included parameters MUST match for a resource to be returned." I say conflict because we should have the principle of the least surprise. = RD res-lookup and /.well-known/core are very similar. The latter could also= offer the same filtering as RD based on the server's resource(=3Dlink) att= ributes. Furthermore, I think the "MUST match" is inappropriate. It must be up to th= e client to select the correct link. Just compare it to Google, where besid= es irrelevant results also ads are included in the results and it is up to = the user to decide which links to click on. While I fully understand that t= here is usually no user involved, it would make a more robust system, when = the client has the responsibility to select the appropriate link and not bl= indly the first one because it trusts the MUST in a specification. What do you think? Should we file errata for RFC 6690 and fix this? Did I miss updates from RFC 7252? Ciao Matthias ________________________________ 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_5B1E2EAF1E0A324C8301DD0F01A090F28DE7CEDEFTHW99EI1MSXww9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Esko,

 

from an IoT communication p= oint of view, I would expect that a device is able to determine that it can= not process a request correctly and thus will act accordingly, i.e. option 3 or 4.

 

best

   Norbert

 

 

 

 

From: core [ma= ilto:core-bounces@ietf.org] On Behalf Of Esko Dijk
Sent: Montag, 18. September 2017 17:18
To: Kovatsch, Matthias (CT RDA NEC EMB-DE); core@ietf.org
Subject: Re: [core] Resource Directory vs RFC 6690=

 

Dear Matthias, WG,

 

Indeed the query formats are currently defined diffe= rently for RFC 6690 (i.e. potentially very constrained CoAP server) and for= draft-RD (i.e. typically a resource-rich CoAP server). That makes sense to= me; and we do not want to inherit the very limited RFC 6690 behaviour of a single query parameter into the R= D.  The RD could benefit from more powerful query expressions using mu= ltiple query parameters, AND-ed together.

 

The interoperability problems could come when people= try to send multi-parameter queries to /.well-known/core , the handling of= which is currently not specified at all in RFC 6690. In fact this industry= alliance wants to support multiple query parameters *both* for RD and /.well-known/core queries ;)

 

The above brings up the issue that RFC 6690 does not= specify what to do with a multi-parameter query on /.well-known/core. = ; Since it does not match the template exactly it’s out of 6690 scope= it would seem. Possible behaviors for a RFC 6690 compliant device, that supports the 1-parameter query only, are:=

 

  1. Return full resou= rce list (device decides “I do not support this form of querying̶= 1; and falls back to the “don’t support querying” case in= RFC 6690); 
  2. R= eturn filtered list, only first parameter used (this is the “let̵= 7;s make the best of it, it looks roughly ok” approach);  <= /o:p>
  3. Return = an error (4.xx or 5.xx); 
  4. S= uppress response (only possible for multicast request); 
  5. U= ndefined – up to implementation (this is the current state I believe)

 

This might be clarified as an erratum to RFC 6690. O= ption 2 looks good to in case there are additional query parameters i.e. th= e RFC6690 template with a multi-element list. Option 3 looks good in case t= he query does not match the template at all i.e. the server can’t get a valid single query parameter out = of it.

 

Regards

Esko

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch, Matthias
Sent: Tuesday, April 11, 2017 13:06
To: core@ietf.org
Subject: [core] Resource Directory vs RFC 6690

 

Dear list,

dear Michael

 

While talking with people from an industry alliance = building their standard on CoAP, it came up that RD lookups need to support= multiple query parameters with an AND conjunction. draft-ietf-core-resourc= e-directory-10, Section 7 supports this:

 

        “Multiple= query parameters MAY be included in a lookup”

 

It might be clearer to also mention the logical AND = conjunction here.

The confusion for this requirement mainly arose from= the Link Format RFC 6690, Section 4:

 

        “/.well-known/core{?search*}

        where the varia= ble "search" is a 1-element list that has a single name/value pai= r”

 

The lookup on /.well-known/core only allows a single= query parameter. This was decided to not demand too much query processing = from constrained devices. The query feature is overall a MAY, that is, it m= ight not be implemented at all. That means, also links that do not match the query could be returned.

 

This is in conflict with draft-ietf-core-resource-di= rectory-10, Section 7, where it says further:

 

        “all incl= uded parameters MUST match for a resource to be returned.”

 

I say conflict because we should have the principle = of the least surprise. RD res-lookup and /.well-known/core are very similar= . The latter could also offer the same filtering as RD based on the server&= #8217;s resource(=3Dlink) attributes.

 

Furthermore, I think the “MUST match” is= inappropriate. It must be up to the client to select the correct link. Jus= t compare it to Google, where besides irrelevant results also ads are inclu= ded in the results and it is up to the user to decide which links to click on. While I fully understand that there is usu= ally no user involved, it would make a more robust system, when the client = has the responsibility to select the appropriate link and not blindly the f= irst one because it trusts the MUST in a specification.

 

What do you think?

Should we file errata for RFC 6690 and fix this?

Did I miss updates from RFC 7252?

 

Ciao

Matthias

 

 

The information contained in th= is 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 prohib= ited and may be unlawful. If you are not the intended recipient, please con= tact the sender by return e-mail and destroy all copies of the original email.<= /o:p>

--_000_5B1E2EAF1E0A324C8301DD0F01A090F28DE7CEDEFTHW99EI1MSXww9_-- From nobody Wed Sep 20 01:00:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4667E132697; Wed, 20 Sep 2017 01:00:33 -0700 (PDT) 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 DxV6l0JTxb_J; Wed, 20 Sep 2017 01:00:26 -0700 (PDT) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 574AF126E64; Wed, 20 Sep 2017 01:00:25 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud9.xs4all.net with ESMTPA id uZvidq292mRxPuZvidwMUD; Wed, 20 Sep 2017 10:00:23 +0200 Received: from AMontpellier-654-1-74-119.w90-0.abo.wanadoo.fr ([90.0.169.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 20 Sep 2017 10:00:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 20 Sep 2017 10:00:22 +0200 From: peter van der Stok To: Jim Schaad Cc: consultancy@vanderstok.org, draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <00fc01d32e78$708ba6f0$51a2f4d0$@augustcellars.com> References: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> <00fc01d32e78$708ba6f0$51a2f4d0$@augustcellars.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfCZrGd/6iFpPKCAwasC6CAvF2fQbnENv0VQu8sfe4lUO1ik4wJ6CNJHSGVSmz22WK41A1Tuc1cs/1c5PCVNptU0wzYM5wWRxZudAyxFDiUO1YfMVhjr4 OQXV/sP8eD9hFa/MpFLjjnaFQ8JQQC6Dl02u/NY5vIYqPzh+YTwYRpbVt//nUfzBJm/qwMtbLBaQvLX3S6ZlpNbxA1XU8QKq5rLK/ETtFrOAY+fcKYGu/eLu oDcMlT9OgxLpsXsWaVtVDde01aoSn2WiaePhwSiP4yQ= Archived-At: Subject: Re: [core] Resource Directory - Returned items from Lookup resources 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, 20 Sep 2017 08:00:33 -0000 Hi Jim, just to check our agreement. >> > 1. I am going to assume that all attributes registered with a >> > resource are going to be returned with the resource. >> >> An attribute can have zero values. In that case (IMO) I assume nothing >> is >> returned. > > I don't understand what you mean by an attribute which has zero values. > Do > you consider presence to be a value? I.e. consider the "obs" > attribute, it > has no value but it can either be present or absent. > > This was just a statement say that if an attribute was set when it was > registered, then it should also be returned as part of the data for the > resource. I don't think this is a very exciting idea, just common > sense. > When creating a link registration, some attributes must have a value. There are attributes which may have no value. When such an attribute value has not been specified in the link registration process, the attribute has zero values in my words. I that case the lookup, query does not return anything for that attribute, not even "att=" Does that make sense? Peter From nobody Wed Sep 20 10:08:06 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE07F133052; Wed, 20 Sep 2017 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 LNjgDuXf5tx3; Wed, 20 Sep 2017 10:08:03 -0700 (PDT) Received: from mail4.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 6B489133020; Wed, 20 Sep 2017 10:08:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505927233; h=from:subject:to:date:message-id; bh=NutjfZsUANHfkk3df2UQHWb6ES3cRFlTxpOz7oXpwxM=; b=JeHVGaWv8l1iHT7UOG3/iUtG3ZnU6AUILtKcyhlgl5DqIt/MmPpvccrFGPRkyw74yT87skRsX/i ak6tC2loaTS1QxOpM5QPUOwFAQdfS+PCU3iv11RP3URBUfTkexVRfQgg0EXnUhoK+OCCLQRyZZ+uf Y3z8g1OEOcS5w7uKxn8TgrzCsAiTs7I/Tj4awEVNrTVM5oKDFPx1nMEnJ8Ogk01O1nWQkyQtr30No 9OQdWKWHF4HJpuuuLME2o40pDjiNyznLXskqlmn/8mAbtwKtIw7FZg07xcmvBLkzga1zwn2E+k0hk yyAVkUP80Ay8OWnybpK1/F2iaGUKcGhgQ1Vg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 20 Sep 2017 10:07:13 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 20 Sep 2017 10:07:13 -0700 From: Jim Schaad To: CC: , References: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> <00fc01d32e78$708ba6f0$51a2f4d0$@augustcellars.com> In-Reply-To: Date: Wed, 20 Sep 2017 10:12:25 -0700 Message-ID: <027b01d33233$a3324d20$e996e760$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFxsMKpl038uX9mtS35w8UdkYJvBwHyN3jgAgS1x9ACw6ieHqNLMH1A X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Resource Directory - Returned items from Lookup resources 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, 20 Sep 2017 17:08:05 -0000 See below. > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Wednesday, September 20, 2017 1:00 AM > To: Jim Schaad > Cc: consultancy@vanderstok.org; draft-ietf-core-resource- > directory@ietf.org; core@ietf.org > Subject: Re: [core] Resource Directory - Returned items from Lookup > resources > > Hi Jim, > > just to check our agreement. > > > > >> > 1. I am going to assume that all attributes registered with a > >> > resource are going to be returned with the resource. > >> > >> An attribute can have zero values. In that case (IMO) I assume > >> nothing is returned. > > > > I don't understand what you mean by an attribute which has zero values. > > Do > > you consider presence to be a value? I.e. consider the "obs" > > attribute, it > > has no value but it can either be present or absent. > > > > This was just a statement say that if an attribute was set when it was > > registered, then it should also be returned as part of the data for > > the resource. I don't think this is a very exciting idea, just common > > sense. > > > When creating a link registration, some attributes must have a value. > There are attributes which may have no value. > When such an attribute value has not been specified in the link registration > process, the attribute has zero values in my words. > I that case the lookup, query does not return anything for that attribute, not > even "att=" > > Does that make sense? I think that I agree with the principle, but not the words you are using. I do wonder if there are cases where an RD will synthesis attributes based on other registrations or pre-configuration. As an example, it might return the "gp" attribute on an endpoint based on known group memberships. Jim > > Peter From nobody Thu Sep 21 02:46:21 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17931346F7 for ; Thu, 21 Sep 2017 02:46:19 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 (message has been altered)" header.d=lightingaad.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 8YyodXbIw3PJ for ; Thu, 21 Sep 2017 02:46:10 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0052.outbound.protection.outlook.com [104.47.1.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F64013478A for ; Thu, 21 Sep 2017 02:42:57 -0700 (PDT) Received: from VI1P121CA0008.EURP121.PROD.OUTLOOK.COM (129.75.190.18) by HE1P121MB0043.EURP121.PROD.OUTLOOK.COM (129.75.191.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 21 Sep 2017 09:42:54 +0000 Received: from AM5EUR02FT051.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::200) by VI1P121CA0008.outlook.office365.com (2603:10a6:821:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11 via Frontend Transport; Thu, 21 Sep 2017 09:42:54 +0000 Authentication-Results: spf=neutral (sender IP is 40.115.29.120) smtp.mailfrom=philips.com; siemens.com; dkim=fail (signature did not verify) header.d=lightingaad.onmicrosoft.com;siemens.com; 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 AM5EUR02FT051.mail.protection.outlook.com (10.152.9.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.35.14 via Frontend Transport; Thu, 21 Sep 2017 09:42:54 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (213.199.154.117) 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; Thu, 21 Sep 2017 11:36:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightingaad.onmicrosoft.com; s=selector1-lighting-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Uj2K2sIGwNFLfHFpkvk94tVufuLMyVijweboy92qr9s=; b=aqWCPsvnKYn91czvi3Oh3t+Tnf9vrzZrvgoqQosd3zfBWkiQ6Q7Ryv4jd++XZ5buYD6ljZfHqG7aR/zz3SxFMNRRUkBusues1TkxuzELsdJ9OirqjX/hyIABrNgTsRdMgTEIUFYHvZrw1XLWqO+W7GrujBZaPbAwEzjgZD3O8eM= Received: from VI1P121MB0015.EURP121.PROD.OUTLOOK.COM (129.75.24.214) by VI1P121MB0014.EURP121.PROD.OUTLOOK.COM (129.75.24.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 21 Sep 2017 09:21:42 +0000 Received: from VI1P121MB0015.EURP121.PROD.OUTLOOK.COM ([fe80::58da:4ab2:bc00:a5b3]) by VI1P121MB0015.EURP121.PROD.OUTLOOK.COM ([fe80::58da:4ab2:bc00:a5b3%14]) with mapi id 15.20.0056.018; Thu, 21 Sep 2017 09:21:42 +0000 From: Esko Dijk To: "Vicari, Norbert" , "Kovatsch, Matthias" CC: "core@ietf.org" Thread-Topic: Resource Directory vs RFC 6690 Thread-Index: AdKys6Slnkh1vPiYReSfMVxW3VUVvR9252WwAACyLnAANECu0A== Date: Thu, 21 Sep 2017 09:21:42 +0000 Message-ID: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64@DEFTHW99EL4MSX.ww902.siemens.net> <5B1E2EAF1E0A324C8301DD0F01A090F28DE7CE@DEFTHW99EI1MSX.ww902.siemens.net> In-Reply-To: <5B1E2EAF1E0A324C8301DD0F01A090F28DE7CE@DEFTHW99EI1MSX.ww902.siemens.net> 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; VI1P121MB0014; 6:njBH/HYo05tz79MLzLmjPVVwZECyOl1yGiTDDDuuG8b7piSide0TZW1zBnyWgSMTqhhQhDIBwkAHqZy9vE0U4wwgqrcM6OgQs5neW5T543xgWZsZZ5eQ86ii6egxntZlSBWAN7XoRYS9kbYZPMNPvEQ62Jf5smQUBH3YBK6ld+2MpmQyuMmSJxo/TjXdCFsmCDDLBAer/uP8/OZESFlS4PTQRzIFBi4afHrh7OXsdCHc/SZsNaB6VugwkiBUnT1mKUgnTsyWxXMkqp+4GVZHN2uC9Z1m3IfiKAaxrRluPzD5j7ovCFwl3ib0Wcn/AXDPvS37qfHdt0L8nOYjXUi89Q==; 5:/KlGFY/WrBfjyNlYS885xr2FDKwys+7OJkN1H7puY9+4UTxGzZPtYG6fexRjlCJH3liJ6Wy93JJoaDv8QvjazG3hF0/s+NdzBsahvF4POOxMIA+FpKkHch8EI92ylyNs6NIh2dXVL+CTIfVH2o97qA==; 24:BxZa5IiESwQEuexNKAWZSmxWrDYVkt9AEMWi6Mk9q4oc4kXDfZDQmN3/CSpvP56jEaAPpL+wH+w0qISFaokbGMRXQzd9r3YLOshhj9PdnPM=; 7:boqih/rxSusYDVktnqbCaohcjFSmhlztGKR3eZPVZoXY8LvggTVTfciLhFNpdKlFcCxtrJqgDZroK/jWELwf2ajaXoQmh0qt2vTirwcUIi8Uqi5IC/IsGlwLzERpbWuZPMiitSZNK+TrkT8zreFWPf153OOc13Qf6ks5OgVMoY9kiRlHhu4uRF3+PyyrLOPJ8VqU4L5bz9qOvXT4VGuCSU/5wgHowKsLuK44k3tySdo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 193a3617-cbdd-4eba-fd90-08d500d52217 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1P121MB0014; X-MS-TrafficTypeDiagnostic: VI1P121MB0014:|HE1P121MB0043: x-exchange-antispam-report-test: UriScan:(158342451672863)(126837547833334)(21748063052155)(260087099026482)(33711482430040); UriScan:(158342451672863)(126837547833334)(21748063052155)(260087099026482)(33711482430040); X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-cfa-test: =?us-ascii?Q?BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101?= =?us-ascii?Q?)(100105300095)(100000702101)(100105100095)(6040450)(2401047?= =?us-ascii?Q?)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(?= =?us-ascii?Q?93006095)(93001095)(10201501046)(6041248)(20161123558100)(20?= =?us-ascii?Q?161123564025)(201703131423075)(201702281528075)(201703061421?= =?us-ascii?Q?075)(201703061406153)(20161123560025)(20161123562025)(201611?= =?us-ascii?Q?23555025)(6072148)(201708071742011)(100000704101)(1001052000?= =?us-ascii?Q?95)(100000705101)(100105500095);SRVR:VI1P121MB0014;BCL:0;PCL?= =?us-ascii?Q?:0;RULEID:(100000800101)(100110000095)(100000801101)(1001103?= =?us-ascii?Q?00095)(100000802101)(100110100095)(100000803101)(10011040009?= =?us-ascii?Q?5)(100000804101)(100110200095)(100000805101)(100110500095);S?= =?us-ascii?Q?RVR:VI1P121MB0014;BCL:0;PCL:0;RULEID:(100000700101)(10010500?= =?us-ascii?Q?0095)(100000701101)(100105300095)(100000702101)(100105100095?= =?us-ascii?Q?)(6095135)(2401047)(5005006)(8121501046)(3002001)(1020150104?= =?us-ascii?Q?6)(100000703101)(100105400095)(93006095)(93003095)(6055026)(?= =?us-ascii?Q?6096035)(20161123563025)(20161123556025)(201703131430075)(20?= =?us-ascii?Q?1703131448075)(201703131433075)(201703161259150)(20170315104?= =?us-ascii?Q?2153)(20161123559100)(20161123565025)(20161123561025)(201708?= =?us-ascii?Q?071742011)(100000704101)(100105200095)(100000705101)(1001055?= =?us-ascii?Q?00095);SRVR:HE1P121MB0043;BCL:0;PCL:0;RULEID:(100000800101)(?= =?us-ascii?Q?100110000095)(100000801101)(100110300095)(100000802101)(1001?= =?us-ascii?Q?10100095)(100000803101)(100110400095)(400006)(100000804101)(?= =?us-ascii?Q?100110200095)(100000805101)(100110500095);SRVR:HE1P121MB0043?= =?us-ascii?Q?;?= x-forefront-prvs: 04371797A5 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(199003)(85714005)(76104003)(189002)(478600001)(3846002)(106356001)(189998001)(6246003)(316002)(2900100001)(2906002)(7696004)(101416001)(50986999)(76176999)(53936002)(66066001)(3660700001)(53546010)(2950100002)(4326008)(3280700002)(105586002)(790700001)(6116002)(102836003)(74316002)(54356999)(9686003)(54896002)(236005)(6306002)(7736002)(33656002)(55016002)(6436002)(97736004)(8676002)(6506006)(81166006)(86362001)(14454004)(229853002)(81156014)(5250100002)(5660300001)(110136005)(8936002)(25786009)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P121MB0014; H:VI1P121MB0015.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) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1P121MB0015FD03E0DBE0CABB39C3C89B660VI1P121MB0015EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0014 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131504605744542794; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR02FT051.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:40.115.29.120; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(336005)(376002)(39860400002)(346002)(39380400002)(2980300002)(189002)(76104003)(85714005)(199003)(53946003)(8936002)(69596002)(2950100002)(66066001)(50986999)(54356999)(76176999)(33656002)(25786009)(260700001)(6116002)(790700001)(102836003)(3846002)(512954002)(356003)(2906002)(498600001)(54896002)(55016002)(74316002)(7736002)(229853002)(105586002)(53936002)(81156014)(81166006)(6506006)(8676002)(106466001)(6306002)(9686003)(6246003)(189998001)(236005)(68736007)(86362001)(2900100001)(4326008)(53546010)(14454004)(61614004)(16586007)(956001)(84326002)(5660300001)(316002)(110136005)(97736004)(5250100002)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P121MB0043; H:LIGHT-EDGE-1.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT051; 1:vBr9pThR2z/CAvdVpRXnSexrxjoXbRvCGte7gOTgL4kSECSIqU7GYaxsDONpbV7QpSMBuVE5CYnCklE6Sz0WvrEVG7ZgXzC68Zmbe06wVEyXe+kBaSFBBBxClwpaLPQG X-DkimResult-Test: Failed X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(3002016)(300000503095)(300135400095)(2017052603199)(201703131430075)(201703131517081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1P121MB0043; X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0043; 3:EkIa/0omntxCCy3AdNH31HBzz+WLSOjbqnbNiKJQ1+BTYbYs4XaodH8tl4j31/g0ZA6gUlH8N2eWWC+IoWPzA/bNjb5RDyTBf1NOIkV6XcifE445mOXo3AX7yI10KMOyXbp+nEguM3kf6CfVTDvyqHLclyVrLXGKcGnqG9kg0xjXJhQXEn5Xl8BJ7uiMvzfJQeIWL8/58NHdCRy3Yc6rrFJcDRJGdkF6QQKmhe4pnhLgWPKSLwjcFF3hM2TZ4QLKKcZRWSGn+Qkaqq4Ux9KjzG0l+mo66iKndNlSNuUlBXUxST081lQQ+eR09bA/ydlfm90Lm6euCmE1k8gpncbW45Qm99F/efNWufOC4GIUk2I=; 25:AjXWc9qs9Y2QlyDFQ9+BwijpTtK9NukNC19P75Aumy6Q6bk6j36Tm87UEnbPG6Ab6nW6LIa3IU+XnsQvUUVQZHnyv9s4wejeBPdN0pEYnEH7BGfIAmFwpQe5DfK0j0Km/rHIIhFfaQQeP7aLmVkkpX3lb1HaXWPzZSKtO+ZfJBuoinTuxXVSSWCIjMLl0vK+kaq0ruupN97GWoIWDHQXMxwXRunhpmX2NbIuEgEIwtXqHDJVUKGTUkfeGHc7juoP2OosmRHGyaeGaupIcUH57DljXFZz7nes1sZ6PB9Ig6s828zjMEIWm71QntmKOLAMlAMCKN4x/0KYQjefexW+FA== X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0043; 31:aRQFsbxAMsGY2VxqoKxfIRn6VTDdJ6OZJtOpH4AiCONy/uvGUUT49p9mGxAFaGOtS/dt9WRd6eZG/WHfSFQl7fkQaKPeSp5WfM5SIqTx/KTer+znOSaEPU9lSoE4Mt+BiIpfj2CwErg46tQ1jPqwktiLrB9AQzJSopcOap865X41Im/WUj+nB1hG2EOrbHSwUtfBzISahZaFyCgZuqMKJVsR66msrhQsQXXr+0HAmmI=; 4:D+gq4+1jGrip/XOXvvmTzbiShq/h/IlzXIMF32kG0gKz3J9pszR27b4RKOKC12WmxALMQWbGUZDUzRWPyNCj+DvcvRdc9U1C851/ZrZUBiv3GU3OhA6HqK1y51Tl9hKONPQo+LQV52p2MjklibeNOnQpP5Q7PhpfuTVVzXiwPkNBcDtz1gY88RREgQcUpq9pzeqy4vRCkVAEze43f2eNhuORmTMcMXyi7BidtjEEe7ZDgJr/AwXYPpwW+PzH3/U3ItI7CCW4zPl/hMwBp3QNkw7hobg4192j/JwvJXidfQR6Oj8e64klyTeCuEg1LSi5tLdgy23oGXP3V3xvY3eMABy7wJz7f00avumw0HX4nV5FqVwTTGRzjHOQUi2gp1b4sEjX3kAbg5JYh+zaavf+E4cslTGfo3SOjpZgLmc7LdkAQhwUT4NGSH/C6Z9DU6uI X-Forefront-PRVS: 04371797A5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1P121MB0043; 23:zwjCgNVqz2YsiOTwAqgCTBNhflo4SextcI9JQ4oii?= =?us-ascii?Q?DPIUeKW8RhDmPlZzDqoVFzNM4quqw6K4mJUOkPLL0PVrvQ9UaEXG/n+6h+k6?= =?us-ascii?Q?Chlg5hw5+vy20VmP8WqRS2UtplLpl9yZ1rSkzY801t++NWSS72gxVQPpx9UR?= =?us-ascii?Q?MNToRsVO+VM7svB35RvpiXOODWgry332h1YHELT4hoUlbVO3Qw3VCIEYlOwR?= =?us-ascii?Q?XlYNNgFeqkJN2lWCk9PKziHzhyJi2Xr/2JO8lojiKoPtUMgFhhpSVxoQFpZx?= =?us-ascii?Q?pVXySOAYwAPb1Xtw/KThO9ZpseS/T0lwLFhndHSqcDAESWwMZfLd0E/3O73B?= =?us-ascii?Q?L3CUDzQNGr/3GotOfX8CL1wQ3LuYsvY6U3aHBJgT/1plfnwYQAHAbyt16SI6?= =?us-ascii?Q?hfJZm1oa6fGawTpKxr/ZLT8S4/q/WobuVmhNXJnAQLhkz6YOFp1s74M5HtY2?= =?us-ascii?Q?aT5ZRHsQvntlDW3kifMwO32rFTY8maAONeM2ItDQ6P6bML52nK+z+w9HI7By?= =?us-ascii?Q?EXnSYJDH0ITuctZ+LQqMYlADZVbNDHM4EjZMFc8XfcZ+vQhSjfZ1o9Md0HZ4?= =?us-ascii?Q?gIXNQ8lEoa7LM5AVE8pS3caLwqIxUbeWnF+0RZu/vJvovAWYlKQnd/SvlziG?= =?us-ascii?Q?ISrurcE9lcWzc4Xd1z/A5UFcZewhJFbwMNFAVZ8k8Xu6gYODEzmBPyJ7KIDW?= =?us-ascii?Q?pE/VMqsG1pDu2ez2hcXTH3mzy6XLnk1+NQP2dNMdRbdoH+HQhENAFYmuKXG2?= =?us-ascii?Q?s/TSe8RMt9cYNgkXRGxcyBHWrrx4uovWGQgfrdF3qONYN8xGMCLwSVG0U7+d?= =?us-ascii?Q?bJ6mDDMTwzMDaO3RGrhiwoW0+yb1uarDnJlHuQ49n/5apj0aDuRTVDD/F0TK?= =?us-ascii?Q?qYyg7nAJgDDKl7OogFjKR9RGeAMsFxc5tLsbXdcCh2To/7IFXfCVmmcwubnq?= =?us-ascii?Q?kJogXyYU4KNNL06aIEuju8YKr/ZfHoauq/cpuWJWrBrP/KFIBahgjOjSYSjz?= =?us-ascii?Q?0ANa45GJ1JxMzsq1J0G0vGjUKhjuUaOImdsv4yOZfOc48YnNBMeNIQdVEX9s?= =?us-ascii?Q?OIYkNRcy3Om/U/Jkn9BAOVP3Nq5/J6KSIeqenapTWRSAVEl6kYE+m7n+HGrS?= =?us-ascii?Q?ySOBwQplVJors26HVDYranzQlj2SzobDt4XSA95i7c7g34p3jjxWTKgkyzR2?= =?us-ascii?Q?dzlcynpAF2k3c8C0pbvgC0zl0ku+f7UTq2MP8Vbln5cGYcFHhIO11HLffhUe?= =?us-ascii?Q?oGuUMXQecYh3ssFLvpPFNh7F/HQf2ZgA9tsr0+imIuoBspVa7Ccr3YmkMxBl?= =?us-ascii?Q?SwINqmlBxN2th0LlnvJw1f6ZI09dTfnl6NTIz4vLt0zzrWkgfx0PVBAY/6zs?= =?us-ascii?Q?LtUpQkysLnQa6Xiktl+WzKX2lD0xuWJp1txaLGPrvH6gQnUCVF/P1eQodHI2?= =?us-ascii?Q?fvoQvOgfw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0043; 6:8BlVE1qtTl/ey4rvofb+wuWkKsOUGW/aKU/kU/6a81dB5BRXUvHPAGuYhQ5EXfowzrcPL5zuA7UgEGflapDgVJ8vEFfoGt4IhVdQrcXeNLEvyNA3tjxnT8OBXnHy4TQsD7iCgkeOQkMXPjebqlvjbEFhbXzNgcRe8QBTsgreeir0F6CnmLn0nwuUKvNtysnyQC5K0+R99Hi3vZ+gZBTwE8nedounFw09+YgtFM3lapUTfDZ8va9OT+cN9TSHFenw9pkEk3vm35xRh/4xoA+zguVlYGi+PFI+eRl9JNP5lNpfY7ve64L8mJe7ljiigC+bPqMMKMSibCrJj/M6HHU71A==; 5:HSvXu/+UqWDeOz8nNsDCSNu9egVQCkRtQyhLIvhcCMsA1XnLMes4SfHRUtL82sjRug1JnWD69oRYuWOiSP1bOi11V3vwZ1pGN1luVspZjvPtRU3J3dWX7fswXJVRDI4WgY/avyJMQxgIienj5ZkhQA==; 24:fFs4M/QVMMA6ToXD0NFoRnOTbC5Vjj9Z//Si+e24jkQTUub1esUBQzmgYd+kDaG5n/dhj7CcJsYNGardB5YO1Bl1yW75kn5fwNWx3+Z8/Nw=; 7:IQ/1VGHuKEhNNyaKpg+SicEIu46Ql77uWcGI4IJ/SgY4/4UsUEKKgmFiV9EGtxkHpUY0TRnUckyNIYG4Rh0r3LhSeht2vuFdZ9SFf2zPffEp9m5QUpIy/8+JzMMqZpHV9Afs9n5mr+8W0Dm2yuv2vXf+W5q/Kpu6RTKgvQlDFlezMI59hYeHXSIQv5vVM8wkrv0UQ4HXv7Yd/VEo7DoGWVI0eu9EyUPwykrDDR0Il6I= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2017 09:42:54.2043 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[40.115.29.120]; Helo=[LIGHT-EDGE-1.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0043 Archived-At: Subject: Re: [core] Resource Directory vs RFC 6690 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, 21 Sep 2017 09:46:20 -0000 --_000_VI1P121MB0015FD03E0DBE0CABB39C3C89B660VI1P121MB0015EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Norbert After some thought - what you suggest could be even the preferred approach,= to make sure that either one of the below situations can be reliably detec= ted by a client: 1. The multi-parameter query went ok at the server (so the link-format = response is correct - only fully matching query results sent back) 1. The multi-parameter query was detected but not executed at the server= (so, an error response - no non-matching query results are sent back) 1. The query component was ignored, since the target server does not sup= port querying as per RFC 6690 (so the link format response contains all res= ources) The case 3 should be more easily detectable by a client than the case of "q= uery results are almost correct, but not quite". Also agree that in multicast case, a server can just suppress the response = in case it has nothing useful to return - as per RFC 7252 / 6690. I propose to file an erratum on RFC 6690 requesting for more detail on how = to handle the case of 'malformed queries' and queries with too many paramet= ers; and suggest the error response as appropriate. Esko From: Vicari, Norbert [mailto:norbert.vicari@siemens.com] Sent: Monday, September 18, 2017 17:30 To: Esko Dijk ; Kovatsch, Matthias ; core@ietf.org Subject: RE: Resource Directory vs RFC 6690 Dear Esko, from an IoT communication point of view, I would expect that a device is ab= le to determine that it cannot process a request correctly and thus will ac= t accordingly, i.e. option 3 or 4. best Norbert From: core [mailto:core-bounces@ietf.org] On Behalf Of Esko Dijk Sent: Montag, 18. September 2017 17:18 To: Kovatsch, Matthias (CT RDA NEC EMB-DE); core@ietf.org Subject: Re: [core] Resource Directory vs RFC 6690 Dear Matthias, WG, Indeed the query formats are currently defined differently for RFC 6690 (i.= e. potentially very constrained CoAP server) and for draft-RD (i.e. typical= ly a resource-rich CoAP server). That makes sense to me; and we do not want= to inherit the very limited RFC 6690 behaviour of a single query parameter= into the RD. The RD could benefit from more powerful query expressions us= ing multiple query parameters, AND-ed together. The interoperability problems could come when people try to send multi-para= meter queries to /.well-known/core , the handling of which is currently not= specified at all in RFC 6690. In fact this industry alliance wants to supp= ort multiple query parameters *both* for RD and /.well-known/core queries ;= ) The above brings up the issue that RFC 6690 does not specify what to do wit= h a multi-parameter query on /.well-known/core. Since it does not match th= e template exactly it's out of 6690 scope it would seem. Possible behaviors= for a RFC 6690 compliant device, that supports the 1-parameter query only,= are: 1. Return full resource list (device decides "I do not support this form= of querying" and falls back to the "don't support querying" case in RFC 66= 90); 2. Return filtered list, only first parameter used (this is the "let's m= ake the best of it, it looks roughly ok" approach); 3. Return an error (4.xx or 5.xx); 4. Suppress response (only possible for multicast request); 5. Undefined - up to implementation (this is the current state I believe= ) This might be clarified as an erratum to RFC 6690. Option 2 looks good to i= n case there are additional query parameters i.e. the RFC6690 template with= a multi-element list. Option 3 looks good in case the query does not match= the template at all i.e. the server can't get a valid single query paramet= er out of it. Regards Esko From: core [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch, Matthias Sent: Tuesday, April 11, 2017 13:06 To: core@ietf.org Subject: [core] Resource Directory vs RFC 6690 Dear list, dear Michael While talking with people from an industry alliance building their standard= on CoAP, it came up that RD lookups need to support multiple query paramet= ers with an AND conjunction. draft-ietf-core-resource-directory-10, Section= 7 supports this: "Multiple query parameters MAY be included in a lookup" It might be clearer to also mention the logical AND conjunction here. The confusion for this requirement mainly arose from the Link Format RFC 66= 90, Section 4: "/.well-known/core{?search*} where the variable "search" is a 1-element list that has a single n= ame/value pair" The lookup on /.well-known/core only allows a single query parameter. This = was decided to not demand too much query processing from constrained device= s. The query feature is overall a MAY, that is, it might not be implemented= at all. That means, also links that do not match the query could be return= ed. This is in conflict with draft-ietf-core-resource-directory-10, Section 7, = where it says further: "all included parameters MUST match for a resource to be returned." I say conflict because we should have the principle of the least surprise. = RD res-lookup and /.well-known/core are very similar. The latter could also= offer the same filtering as RD based on the server's resource(=3Dlink) att= ributes. Furthermore, I think the "MUST match" is inappropriate. It must be up to th= e client to select the correct link. Just compare it to Google, where besid= es irrelevant results also ads are included in the results and it is up to = the user to decide which links to click on. While I fully understand that t= here is usually no user involved, it would make a more robust system, when = the client has the responsibility to select the appropriate link and not bl= indly the first one because it trusts the MUST in a specification. What do you think? Should we file errata for RFC 6690 and fix this? Did I miss updates from RFC 7252? Ciao Matthias ________________________________ 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. ________________________________ 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_VI1P121MB0015FD03E0DBE0CABB39C3C89B660VI1P121MB0015EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Norbert

 

After some thought – what you suggest could be= even the preferred approach, to make sure that either one of the below sit= uations can be reliably detected by a client:

 

  1. T= he multi-parameter query went ok  at the server (so the link-format re= sponse is correct – only fully matching query results sent back)=

 

  1. T= he multi-parameter query was detected but not executed at the server (so, a= n error response – no non-matching query results are sent back)<= /o:p>

 

  1. T= he query component was ignored, since the target server does not support qu= erying as per RFC 6690 (so the link format response contains all resources)=

 

The case 3 should be more easily detectable by a cli= ent than the case of “query results are almost correct, but not quite= ”.

 

Also agree that in multicast case, a server can just= suppress the response in case it has nothing useful to return – as p= er RFC 7252 / 6690.

 

I propose to file an erratum on RFC 6690 requesting = for more detail on how to handle the case of ‘malformed queries’= ; and queries with too many parameters; and suggest the error response as a= ppropriate.

 

Esko

 

From: Vicari, Norbert [mailto:norbert.vicari@= siemens.com]
Sent: Monday, September 18, 2017 17:30
To: Esko Dijk <esko.dijk@philips.com>; Kovatsch, Matthias <= matthias.kovatsch@siemens.com>; core@ietf.org
Subject: RE: Resource Directory vs RFC 6690

 

Dear Esko,

 

from an IoT communication point of view= , I would expect that a device is able to determine that it cannot process = a request correctly and thus will act accordingly, i.e. option 3 or 4.

 

best

   Norbert<= /p>

 

 

 

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Esko Dijk
Sent: Montag, 18. September 2017 17:18
To: Kovatsch, Matthias (CT RDA NEC EMB-DE); core@ietf.org
Subject: Re: [core] Resource Directory vs RFC 6690=

 

Dear Matthias, WG,

 

Indeed the query formats are currently defined diffe= rently for RFC 6690 (i.e. potentially very constrained CoAP server) and for= draft-RD (i.e. typically a resource-rich CoAP server). That makes sense to= me; and we do not want to inherit the very limited RFC 6690 behaviour of a single query parameter into the R= D.  The RD could benefit from more powerful query expressions using mu= ltiple query parameters, AND-ed together.

 

The interoperability problems could come when people= try to send multi-parameter queries to /.well-known/core , the handling of= which is currently not specified at all in RFC 6690. In fact this industry= alliance wants to support multiple query parameters *both* for RD and /.well-known/core queries ;)

 

The above brings up the issue that RFC 6690 does not= specify what to do with a multi-parameter query on /.well-known/core. = ; Since it does not match the template exactly it’s out of 6690 scope= it would seem. Possible behaviors for a RFC 6690 compliant device, that supports the 1-parameter query only, are:=

 

  1. R= eturn full resource list (device decides “I do not support this form = of querying” and falls back to the “don’t support queryin= g” case in RFC 6690); 
  2. Return filtered list, only first parameter used (this is the= “let’s make the best of it, it looks roughly ok” approac= h);  
  3. Return an error (4.xx or 5.xx); 
  4. Suppress response (only possible for multicast request);&nbs= p;
  5. Undefined – up to implementation (this is the current = state I believe)

 

This might be clarified as an erratum to RFC 6690. O= ption 2 looks good to in case there are additional query parameters i.e. th= e RFC6690 template with a multi-element list. Option 3 looks good in case t= he query does not match the template at all i.e. the server can’t get a valid single query parameter out = of it.

 

Regards

Esko

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch, Matthias
Sent: Tuesday, April 11, 2017 13:06
To: core@ietf.org
Subject: [core] Resource Directory vs RFC 6690

 

Dear list,

dear Michael

 

While talking with people from an industry alliance = building their standard on CoAP, it came up that RD lookups need to support= multiple query parameters with an AND conjunction. draft-ietf-core-resourc= e-directory-10, Section 7 supports this:

 

        “Multiple= query parameters MAY be included in a lookup”

 

It might be clearer to also mention the logical AND = conjunction here.

The confusion for this requirement mainly arose from= the Link Format RFC 6690, Section 4:

 

        “/.well-known/core{?search*}

        where the varia= ble "search" is a 1-element list that has a single name/value pai= r”

 

The lookup on /.well-known/core only allows a single= query parameter. This was decided to not demand too much query processing = from constrained devices. The query feature is overall a MAY, that is, it m= ight not be implemented at all. That means, also links that do not match the query could be returned.

 

This is in conflict with draft-ietf-core-resource-di= rectory-10, Section 7, where it says further:

 

        “all incl= uded parameters MUST match for a resource to be returned.”

 

I say conflict because we should have the principle = of the least surprise. RD res-lookup and /.well-known/core are very similar= . The latter could also offer the same filtering as RD based on the server&= #8217;s resource(=3Dlink) attributes.

 

Furthermore, I think the “MUST match” is= inappropriate. It must be up to the client to select the correct link. Jus= t compare it to Google, where besides irrelevant results also ads are inclu= ded in the results and it is up to the user to decide which links to click on. While I fully understand that there is usu= ally no user involved, it would make a more robust system, when the client = has the responsibility to select the appropriate link and not blindly the f= irst one because it trusts the MUST in a specification.

 

What do you think?

Should we file errata for RFC 6690 and fix this?

Did I miss updates from RFC 7252?

 

Ciao

Matthias

 

 

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, forw= arding, 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.


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_VI1P121MB0015FD03E0DBE0CABB39C3C89B660VI1P121MB0015EURP_-- From nobody Thu Sep 21 03:49:16 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89D51348DF for ; Thu, 21 Sep 2017 03:49:14 -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 aCLmIvPudJj8 for ; Thu, 21 Sep 2017 03:49: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 91F5F1348DA for ; Thu, 21 Sep 2017 03:49:10 -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 v8LAn6Ep017983; Thu, 21 Sep 2017 12:49:06 +0200 (CEST) Received: from client-0201.vpn.uni-bremen.de (client-0201.vpn.uni-bremen.de [134.102.107.201]) (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 3xyYJL46YbzDLCH; Thu, 21 Sep 2017 12:49:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 21 Sep 2017 12:49:05 +0200 Cc: "Vicari, Norbert" , "Kovatsch, Matthias" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 527683745.654633-a483d0076fa7b57075a120d2e059be1a Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64@DEFTHW99EL4MSX.ww902.siemens.net> <5B1E2EAF1E0A324C8301DD0F01A090F28DE7CE@DEFTHW99EI1MSX.ww902.siemens.net> To: Esko Dijk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Resource Directory vs RFC 6690 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, 21 Sep 2017 10:49:15 -0000 On Sep 21, 2017, at 11:21, Esko Dijk wrote: >=20 > file an erratum on RFC 6690 The errata process is not really suited for technical enhancements like = this. We may indeed want to capture RFC 6690 issues at one place (there are = some other issues that may come up as a result of = 5988bis/RFC8228-to-be). I=E2=80=99m not sure this must lead to a formal = 6690bis effort right now, but ultimately that will be something we will = have to do. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Sep 21 05:01:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6951134B3F; Thu, 21 Sep 2017 05:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwXnjrhCla2s; Thu, 21 Sep 2017 05:01:29 -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 4BE741320C9; Thu, 21 Sep 2017 05:01:20 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 72F054111E; Thu, 21 Sep 2017 14:01:15 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 8A75F4F; Thu, 21 Sep 2017 14:01:12 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 548CE42; Thu, 21 Sep 2017 14:01:12 +0200 (CEST) Received: (nullmailer pid 26145 invoked by uid 1000); Thu, 21 Sep 2017 12:01:11 -0000 Date: Thu, 21 Sep 2017 14:01:11 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad , draft-silverajan-core-coap-protocol-negotiation@ietf.org Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org, Tracker issue 36 Message-ID: <20170921120110.pkuulxfux2vfusjm@hephaistos.amsuess.com> References: <007801d32694$51c49790$f54dc6b0$@augustcellars.com> <1f46d054a227bdba7dc07e5c22bd1549@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="npyaexw6morwumk6" Content-Disposition: inline In-Reply-To: <1f46d054a227bdba7dc07e5c22bd1549@xs4all.nl> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] My endpoint has two addresses 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, 21 Sep 2017 12:01:33 -0000 --npyaexw6morwumk6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, Hello Bill and Mert, On Fri, Sep 08, 2017 at 09:28:41AM +0200, peter van der Stok wrote: > For the moment, we made the model such that and extension to multiple > contexts is possible, but not yet supported by the RD, given that all the= se > extensions are still under discussion, More concretely, this is where I hope that core-coap-protocol-negotiation will take over. We're deliberately keeping multiple-base-addresses out of resource-directory (an earlier state already allowed more than one address) so this can be comprehensively specified there based on model that contains only the extension point for it. Bill and Mert, Jim the issue Jim raised is not fully covered by the protocol-negotiation draft or what we talked about in Prague, but involves the choice of an Internet layer when raw addresses are used. Will we be able to use the mechanisms introduced there in the absence of hostnames for an IPv4 and an IPv6 addresses (or multiple IPv6 addresses)? Best regards Christian --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --npyaexw6morwumk6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnDqgAACgkQOY0REtOk veFtFRAAxB8CWmu+N3zkhfgFjxYhzdkDypl6YQXdHeq9X6slgBj0Bj1jTDsQUacR W4rkox4lzB55hkIHLwQFPREF0YexwSILcBdGFKJ5jg7LriyRhXoubaIujeaUPemM LTQoo1OKqvYtula1WxiQrtirkz/gtcyIhf28Ops6om2eHcDKOhWGGqkUXZEmO4Qg wcPfrtewov+iN2vbcWT5rUmyb41xm43bsstyF0Fd+wKilyZWcTK31gF+oMOn3XRL LrW0Nyk3oBKqXl9vtK+deWOpn04EhqnHdUhOk5J6F5QRewhkhkW9QVlGoq5bN4Gf V7NGDom2JjoR/W5JcuXhEzDQj7JygD0RfDrHC1wNCz/jCXyARYDKyHFuoizpStD1 DOl5pXgA9vArweFn3Wt31tGb/Vf+cAuylAGmBKumDu1NtoAuLhBRHd7QmnxE9mfy ZnwpL/vK1+32ZgYUC720RWmmaRLRcYDRfEjehLJbX3cjiqdJC9gmJQ/vxo1KxfDs R00sKlWGkUdyHA3wSbbBgBZ5SvqafwBTafh/eQLzFaTqb1xJYPk1PuoYhq7KQJu4 AyZ42Ym9YDV2jmhcVOwgNli9cgJ73BqTr+AKYuDF1lC0pOrSKXuTPam5ul0emZjj 1dLMIHkDcn9iUyQL3djf7zWBFvwVknvP81DgxMl1hB0lLlCk4Ak= =lnan -----END PGP SIGNATURE----- --npyaexw6morwumk6-- From nobody Thu Sep 21 06:05:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D67813420E; Thu, 21 Sep 2017 06:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avdi6XwEgIj9; Thu, 21 Sep 2017 06:05:21 -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 152141342E7; Thu, 21 Sep 2017 06:05:20 -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 F111A4111E; Thu, 21 Sep 2017 15:05:16 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 475754F; Thu, 21 Sep 2017 15:05:16 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0838242; Thu, 21 Sep 2017 15:05:16 +0200 (CEST) Received: (nullmailer pid 30463 invoked by uid 1000); Thu, 21 Sep 2017 13:05:15 -0000 Date: Thu, 21 Sep 2017 15:05:15 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Issue 37 , "draft-ietf-core-resource-directory@ietf.org" Cc: core@ietf.org Message-ID: <20170921130514.om56u42zcycacckx@hephaistos.amsuess.com> References: <016801d321fc$d2820d50$778627f0$@augustcellars.com> <000401d32592$4349a870$c9dcf950$@augustcellars.com> <9D9B829F-3B73-44FE-92A2-C2B4435934E9@gmail.com> <537223E3-E2DB-4505-9E22-5829BD441DDD@gmail.com> <64ECEBB9-06D5-4A88-A89D-622B4DFB6D54@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sfs365bgict7mdhn" Content-Disposition: inline In-Reply-To: <64ECEBB9-06D5-4A88-A89D-622B4DFB6D54@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd 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, 21 Sep 2017 13:05:26 -0000 --sfs365bgict7mdhn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, Peter and Michael, sorry for being late to the party. On Fri, Sep 08, 2017 at 06:58:27AM -0700, Michael Koster wrote: > So "con" refers to the registration resource, and reflects the "con" > parameter that was supplied during registration. What is being proposed here looks an awful lot like the endpoint lookup with slightly different data. To compare, the latest example from this thread was (in RFC9960 link-format): GET /registration/?ep=3Dexample-endpoint-name ;con=3D"coap://[rdrd::12]:17072";ep=3Dexample-endpoint-name; et=3Docf-device;rt=3Dcore-rd.endpoint;ct=3D40;lt=3D600;d=3Dfloor-3 while for such a registration, the existing lookup would be GET /rd-lookup/ep?ep=3Dexample-endpoint-name ;ep=3Dexample-endpoint-name; et=3Docf-device;d=3Dfloor-3 =46rom a pure data point of view (disregarding the semantics), all that is shown (and can be queried) from the existing lookup interface is a subset of the proposed registrations interface. =46rom the semantic point of view, the former has the advantage of having an accurate rel (the implied `hosts`, in that the resource directory hosts the registration resource). Moreover, the target attributes are clearer: "endpoint type" and "d" do kind of relate to the base address, but `;ep=3Dexample-endpoint-name` is a statement about a resource too, and that is (contrary to what we say in the principles) not backed by the origin. The former form is also more painless to extend to alternative transports (protocol-negotiation could add more than one con=3D without it becoming a second-class citizen, which all those would be with the latter). As we're reworking the lookup interface anyway, can we just use the former representations in the endpoint lookup? It'd keep the registration and lookup interfaces neatly separated as they are, be more precise about target attributes and more discoverable in a hypertext sense. Best regards Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --sfs365bgict7mdhn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnDuQYACgkQOY0REtOk veHEKQ//c9GDf6zPChpWsKbK4YHRBugp5ff1A8PjR7IMg4rQVVg3oQcbJ5G6M6Zl I4YQT/3CehuZhqfSNNVU5SKFwLJBD2hkB5g2eO1dESYl7ytr+wdGDLMtz+Ai4D/b AJYhnCZIPaoeqN21HS3e1q7YHLoZlBbb0QguOkMfPGNcpTVtrdClYIL3QHyhkDcs PfpNL7GofZK1HlCyCbcY+LxuGyxel8vmhOiChaDnsN0fqxjSOcUkYkNdxvrinsIW J74Refakn8DxQque442TGQMi/X+ZFZRBNp9Bf7VRjSvampdZnKnQvuykvci34MVK rURLCERjfIilzNOPjXAbFk2lqUJWWHeII/z/gYM/Y+1mQ6Raq86tRvfW5sbbIfg6 AUQjvJqrJ/yRBQw7gbc3VTKSwcVGlqFzzWpMmLEAP7Qf3rEifw4Rf5tmoosMVIK3 lbr58RpYI1T+oLbj6Kt/atBMnRznII+HZhZiMB8ks3t8krtz6Wpr6lWWDGE7KYig AJ36uWDC08xGf2PS8X1S60mHCl44JDtN3x/FYlmqqp+xQW+m9lityTeYC8enWPoX I3YTFj5hOTk4tZBvFAiyGv08gmJxB4lAbNGFMNweCHKTWoooQ82d+ElCdpaDJwP1 4byNW4XRyJBk7HUuMZ5uCXt+xIQjTWhctMT0fZVylneTMYDoBMI= =Cta+ -----END PGP SIGNATURE----- --sfs365bgict7mdhn-- From nobody Thu Sep 21 07:19:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDE0134B59; Thu, 21 Sep 2017 07:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4csAIMQRAkf8; Thu, 21 Sep 2017 07:19:34 -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 47901134AA7; Thu, 21 Sep 2017 07:19:34 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id C8D3E4111E; Thu, 21 Sep 2017 16:19:31 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BD39A4F; Thu, 21 Sep 2017 16:19:25 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7889C42; Thu, 21 Sep 2017 16:19:25 +0200 (CEST) Received: (nullmailer pid 2416 invoked by uid 1000); Thu, 21 Sep 2017 14:19:24 -0000 Date: Thu, 21 Sep 2017 16:19:24 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad , draft-ietf-core-resource-directory@ietf.org, Issue 34 Cc: core@ietf.org Message-ID: <20170921141924.32qtnres2ndabd2w@hephaistos.amsuess.com> References: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> <00fc01d32e78$708ba6f0$51a2f4d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lli3xqbpf6uapvu2" Content-Disposition: inline In-Reply-To: <00fc01d32e78$708ba6f0$51a2f4d0$@augustcellars.com> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] Resource Directory - Returned items from Lookup resources 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, 21 Sep 2017 14:19:37 -0000 --lli3xqbpf6uapvu2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim and Peter, On Fri, Sep 15, 2017 at 04:14:51PM -0700, Jim Schaad wrote: > > > 2. I am unclear if the context is what should be returned as the > > > link address for an endpoint or if it is just the scheme + > > > authority (i.e. omit any path portion). > >=20 > > I find the concatenation of "con" and "href" values, as currently > > suggested in the examples, also difficult to understand. IMO the > > href value should be returned between <> brackets, and the con as an > > additional attribute. >=20 > I would find that logical, even if it makes the client side more difficult > to build the entire URI. as I view the resource lookup, that interface should be usable for clients without awareness of what a resource directory is. (For example, a temperature display that is used to fetch all temperatures from a given device should be able to use `coap://configued-rd/lkp/res?d=3Dmy-domain` as its configured address and, by the same rules by which it'd discover a single device's temperatures, display all the domains'). For that, and to faithfully represent not only the links but also the link relations, a lookup result should be ;rt=3D"temp.inside";anchor=3D"coap://first-device", ;rt=3D"temp.inside";anchor=3D"coap://second-device" Thus, href stays as it was registered, all attributes stay as they are (including the implied rel=3D"hosts"), but the implicit anchor=3D"coap://first-device";rel=3D"hosts" that all lines from a lookup to coap://first-device/.well-known/core would carry is made explicit where different defaults would take over otherwise. In other words, the con=3D value of the registered endpoint is expressed as anchor in the EP lookup because that precisely fits its meaning. (AFAIR this is something we've also talked about in Prague, and I should probably write a pull request that brings the examples in line). Best regards Christian --=20 There's always a bigger fish. -- Qui-Gon Jinn --lli3xqbpf6uapvu2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnDymUACgkQOY0REtOk veFzfA//RFMxZPmrcp8KbK6oO0viMylIRf+kdF44f76EuA3AuVKh0JBt047YZR8z ix9+QrGfTKBci4u4LTQHq8R7ugK12SD1WQEA4Hw3LDwbxIOzMfIpX95pCfKwsBfv +PPh+mpJK2m2ayrwhXb9sJf/3KXpjlWD/7W2MjKfLLtYbek2jbGM3DNmSnUr3ccB e8Na2emDGZ2Dd7sfev6fpzZ9sbWsBdT+bJY4Akf7FDvwSr4qxLSWFmGsp3u8Bksm 4VpUc8WRrUvdLCPR3GBYs4T8JqpPGHlJX/69iuilrBqZMKzcJrfl2Qa57y0lyaTb jAOUOEvoiIsnFgDeNsZERv8OiiVHaOBxHeTiCFbKm29eB02NZvolpsVJnQkOwQXs gS1enpq46Ot2J0QC5cR/h7dEo04Z0fDpqJNlwVR5BGizNsCOWv1HKMV4TDpcG2js 3Q7em4Na54bg6vMYqdsU+Eb89WdQgCbM6/tqpZoK170ESICfAPXzBsd1HaLGZVk/ s24OCgDekrIA7zoRjIfGPgG8sLuc0roPZogyI99UCUeabspHpAjoq0iqscULzgqF O1JiEWJc57V1ZFj7KdYaibuuFOCvJ8b9/0Wbe+SlJ+p2zdohnj2eDDofi17SLnrW tTAcN2cSGE4HrbvLEvnTurxyNkwJo8DsOm47raeqZPu1AgMUqUc= =M5dx -----END PGP SIGNATURE----- --lli3xqbpf6uapvu2-- From nobody Thu Sep 21 07:21:07 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9EF134B6B; Thu, 21 Sep 2017 07:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqf22Ph_6g_k; Thu, 21 Sep 2017 07:21: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 4858C134B6A; Thu, 21 Sep 2017 07:20:59 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D85574111E; Thu, 21 Sep 2017 16:20:57 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 52C464F; Thu, 21 Sep 2017 16:20:57 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3385142; Thu, 21 Sep 2017 16:20:57 +0200 (CEST) Received: (nullmailer pid 2664 invoked by uid 1000); Thu, 21 Sep 2017 14:20:56 -0000 Date: Thu, 21 Sep 2017 16:20:56 +0200 From: chrysn To: Jim Schaad , draft-ietf-core-resource-directory@ietf.org Cc: core@ietf.org Message-ID: <20170921142055.qwqizaexmqgres6v@hephaistos.amsuess.com> References: <000001d328e3$c21ddaa0$46598fe0$@augustcellars.com> <00fc01d32e78$708ba6f0$51a2f4d0$@augustcellars.com> <027b01d33233$a3324d20$e996e760$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="clp6zxc3ay7oyxw3" Content-Disposition: inline In-Reply-To: <027b01d33233$a3324d20$e996e760$@augustcellars.com> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] Resource Directory - Returned items from Lookup resources 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, 21 Sep 2017 14:21:05 -0000 --clp6zxc3ay7oyxw3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, hello Peter, On Wed, Sep 20, 2017 at 10:12:25AM -0700, Jim Schaad wrote: > I do wonder if there are cases where an RD will synthesis attributes > based on other registrations or pre-configuration. As an example, it > might return the "gp" attribute on an endpoint based on known group > memberships. =46rom my understanding and the current examples, no attributes are ever synthesized into resource lookups. (The anchor values from the other half of the thread are no exception here; they are not synthesized, but just defaults that need to be spellt out because otherwise the meaning would change.) As for non-resource lookups (endpoint and group), I can't answer that, but I'd assume that it's up to the implementation whether absent attributes are left absent or shown with a default or configured value. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --clp6zxc3ay7oyxw3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnDyscACgkQOY0REtOk veEorRAAwlNkieMm8/fxbrvO/Myc3fJOnuOzUbzFyqesDNkv+yi2OnBBPRvBqIPB E6Y8Pf+U43oxbCM6r9FxaKSmhJM40oW7k+0M3hSwMo5SWmrCJLc7CHMr1pQAOmsO K22wEk+3pVP40prRl0B+3bL7rC90CRcjzX6UG9mzxwGOjaIM9Lmaw5zfkqeQEDLA AjGEBc81VZcl9oRkA2HmQDiXLfKAu4Jrr+NudItLiRGTfi4yhhs1dD+Qou8H63Kg eWUutYYDXHX6bL6R1rqxEI7SB+YqXCIJTO+A+govN6mSeX97Nn5o7+/HUG8MzxXg cvnLBFjrSEZqiSzDzzsNTeEQSi+j5SBO4GvaANEt3NRFbX5JByauoadL9osGGnZW MB7RV+KIBtMv13iGVNZPNA3ekv5b1Vjv66e0hngSwF41Duxb+vwZPvldVgUMX4qj 2N1x+NduDbCxZKF+3O1+q8vA0LdmptM7BS26ULQYSuYZKnworwIIAUOTYn4Ny9A5 j/3Cb1pfupIWvfRxCReI53CMPuwE5UfboQxGVYCYtA0o73/+W+i/12U/NG3yPr0f 2dcJVZarUco/wq5zwiut3DG+SGgAZCysafzv+yrAuUugp36gzmGDiBo5Jxzv5l+6 nACagQw9oPPb6iYKaQMRriLCtKqxLJYl5xwQBYAV4dNspYZdq68= =bpQB -----END PGP SIGNATURE----- --clp6zxc3ay7oyxw3-- From nobody Fri Sep 22 00:29:59 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258FC1342CC for ; Fri, 22 Sep 2017 00:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 rwdqJo7_Ph4A for ; Fri, 22 Sep 2017 00:29:55 -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 4409E1342AC for ; Fri, 22 Sep 2017 00:29:54 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-6f-59c4bbf1a09a Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1D.F3.20899.1FBB4C95; Fri, 22 Sep 2017 09:29:53 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 22 Sep 2017 09:29:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nkADltwPAJkMH73Muv/aDZnR9LiSMG23jbhA+rLPjgo=; b=WNTxMk9zZS8HxZC2mPm5MgStHARKCDVDr0/t6i78oiADCUyD/hxgW6s9BF3y+v/hugJERl2/mMkdtqO9vQEbuesD7PucElK/0W4lOERw5oO1cJQFv0CoXkZFko1cD45yai3AfdAdFTBMpEXhJCMzMrFvAVtBHCGMgUEeMGgQXs8= Received: from [192.168.1.4] (37.33.219.72) by DB3PR07MB0636.eurprd07.prod.outlook.com (2a01:111:e400:943c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 22 Sep 2017 07:29:13 +0000 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG" CC: Carsten Bormann , "draft-ietf-core-coap-senml@ietf.org" References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> From: Gonzalo Camarillo Message-ID: Date: Fri, 22 Sep 2017 10:29:06 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [37.33.219.72] X-ClientProxiedBy: HE1PR0202CA0004.eurprd02.prod.outlook.com (2603:10a6:3:8c::14) To DB3PR07MB0636.eurprd07.prod.outlook.com (2a01:111:e400:943c::26) X-MS-Office365-Filtering-Correlation-Id: 2a0423bc-a359-486e-ef21-08d5018ba04e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR07MB0636; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0636; 3:JDWtijnAgps5QVEnh+Gl3K9rDaEFHMd+ybu7ugIQj1luqKzP9ybFOaCOLoo12gt2/an4XVXBk7VJJP1lwb/IdYrqdEQ80p4ndAmxIdg6YGB3eT2r0utUIk3e+Rgquz3YJJkqWx52COG3xf3kF+jq6q10KNbZu1ljQr8MH6S34EIXEABJnih5L3kpGF5OQ7xPSXXmceFoGg+rJT3Mtn5O0oVbrHGEV5jVPRx/vSgdC0fscR0P/p79br0EA0t+j15P; 25:Rjw9fLiaoSL0PmIIJL7uFrG4ZRePLlFTw+EsOzRc6WqSAgnIRn1TwdQ/K3+vnuUaYk5WfPsI9hiDAPE7oh46UgMrNcUfcggxX8JDXO2561dM8HyvDGiQMPWp2YK5v7YfmgrWRIhnjQjhVta5wND3kLlb/An+lvKkFJYsG62yktye83Q+K/Y/Udor70A/N/qoK5o4tawXc4O0i5rUhKIT204IOU4vfxCxgSqF1Pj+ZUGE1g0id2MG18D67t0wkboEjnx1LQoiVeie2VfSVoDPNGo08QZlcrVHugmhh2S8aJSzdqastjsHduetBEo9Kp1K5/E/uk24vyvNWHjNkAkAlg==; 31:d7OZPRhoPEdZvioYwoUxg7ZxAVM4bG9RAzB4OfYIu/+qfxHsLKJ9EhOn1u4c5EfETDUCrLEVHreaTYPU/DYfL0ucrMOZ9lZHgWCZoSwC6p0tuMt4N8qyu476hoUsj2Z3U39coSweSCrD9JkwE6RqkGP9kvzBY1AygDP9r3zcOzoBsVL80ck9djOFhfImXo1rvg3S7NoExKXWUPcxH17ybBeHpJC92uS8Q3tvunMVlQ8= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR07MB0636: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0636; 20:aC+knT1ZhJI6OQnWapKmjtskleDGJWk8WyEAq2r3xaAndb6qjsiYuGxDhOxxOyWHaGGG3pkO5Uaysf8H3OAADZios1FfzgAO6+KMnPFIM/wCxNzTqTQHTBpTtM6Uo1C49txFQKXXRj1p+z1a8e+ZwX9Yefr/M4mYR6pa5Yr935vasVcd3ScWl0nygzxj8Z90mAjMoP4FyvO9sd5BgBPUNHbmRCJoEDaeOMJRItxcAl/1cDw58qWsXzZ/JJBw14CugSOLoALogZAbK2WnlCASgR3MQypgHvI+rbSl+Q3StMKHqnwr92E2Fn4zsEK6H7FGgps+30mCUhYGzx8g1N6weaeIuCKSRiWfhBK5RCtWLSpC99lilbqIR3/EzgT3CyWXazJR3BZQ0qFK4fM4IRzKOoEFU1tEq1DU8ZVvSIYISKy8JW0iyDXxdvHYta/qqs2ER72WSlsDBgzZFGd283LRj1wktavjyb/i0uFUb0JR0otYkqzsWZh4XzvUePGYQfrj; 4:uDjOJI0NjaOtWRuif0ZvStvpSWqbcKr6rm8CKd/0KvMtp85Di3aNAaLpNrekdBd+mhuYlIvTy7B3FNOMIFaanxzkzJCysg6EYQYoPE2S18Hhwx87gc5GwLSUIJRHIKvUfFQoEiOV4Igx+pd78mbpV7RnHwIDS4+iWKcd1/kliFhP+unrVG0g0k9H5tOxIfwBaQCv7mQLtvFMa3XzBKyXxOO+/cU4ZipAN923ajdr9+ttC38DNpXs4ef8Jef/onQs X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR07MB0636; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR07MB0636; X-Forefront-PRVS: 0438F90F17 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(39860400002)(346002)(376002)(24454002)(377454003)(199003)(189002)(101416001)(31696002)(6666003)(189998001)(23676002)(36756003)(6306002)(230783001)(3846002)(5660300001)(31686004)(65826007)(6116002)(76176999)(50986999)(54356999)(2950100002)(7736002)(305945005)(8936002)(81166006)(81156014)(64126003)(105586002)(106356001)(65806001)(33646002)(53936002)(65956001)(66066001)(2870700001)(229383001)(50466002)(47776003)(478600001)(77096006)(6486002)(229853002)(25786009)(6246003)(4326008)(16526017)(110136005)(97736004)(16576012)(58126008)(53546010)(54906003)(2906002)(68736007)(316002)(117156002)(966005)(86362001)(83506001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB0636; H:[192.168.1.4]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNjM2OzIzOmhxWFdaQWppeWt2K0JLejgzL1p4eXZoM2ky?= =?utf-8?B?a1RBN000V0l4VWFPSjF3MTRuZHR3QU5NeHkrYVlYS20yTGJqNTNYRG9JWXhu?= =?utf-8?B?Zjh0TFlkbWRlODIwVHBxQklDMGlIb1RRL1RHRUJkRkdDazAvcFUvSFdFNFFJ?= =?utf-8?B?S1p1eDdWUXRIRTVmTTBmUlJnNi8yam1uQ1h4bDF4c25oUFBpU093bGo4ZHUx?= =?utf-8?B?ODBQUzdMTFpOWGVsMVpmVy9ZSElIbVUyK21EbEtvQm81WFdyMzNLaHFJMzdV?= =?utf-8?B?R3pDWFpEL3ZJRUhycTNhWFlaemlNS1FQLzV1ZnlhSnBmU3ljU0JQdTA2ak1p?= =?utf-8?B?ZklwVTllTmZSZGFjOEZnRDJhNW9scE44d2dJTnI4SGtKWFdZRE1XSjRYeFNl?= =?utf-8?B?R1hHanEzZHNiSkZMemNnMHpVTTkxUUZFeFBiWm5VZmNQZ2NXYldhNksxMU5h?= =?utf-8?B?ZkxtaHpKT1RlNmVjSXc3aTdtZnFQQjFVMmkrVjlJT2pYeVpRRE1mRzJxbWl6?= =?utf-8?B?Q245bk5aSVJ2bklGbk5WMk40ekdZaTZPRXloc0FBU0RROUsvRlZ0OW1yVzBo?= =?utf-8?B?VGtmTnFPL0R0T0REU2RUZHdzWE8yaGVQRlR4YjYwVU1hTXdWclN4MGxhbm9O?= =?utf-8?B?RmVyRy9tNHBkeklNeFkwYldPWlFuV1VYVjV2elI5TFlxWGVhN1Fwd0ExbXJp?= =?utf-8?B?N1ZPWmtxYmlOSE9tOHJQS0Raa2pKbDF0c2hSRVR1UlRLeWNtdHJPQW5namJ2?= =?utf-8?B?SmxTNnk0KzI3WFJPRkVubGtYQm5TVXJySmF1NEF2YWp0VStXa0ZWTVRCK3NU?= =?utf-8?B?QmhQYUxlVHRtQ0s1RXRITldGVnhlYWpJNyt5OG9VWWN1TTIzd1ozRHEzN3hV?= =?utf-8?B?Rm55Zk9ZS3RuRERMUG5rWldRNVJkSHdTNE04WEtGeSthZ0djb3A3N0hVV2NK?= =?utf-8?B?d2UwQndyS25OWURqODBYL3lrdWpHbFBLdG1EbDA5elErT1paQkZIWUxGY2ZH?= =?utf-8?B?eWtnSDl3V2JjYm1kWURULzlrVkFXRlNncXZLcmM5cE83QTJHVFdqTUxEby9j?= =?utf-8?B?R2hoYUpwZGEwRGQ0MDQ1QTk2NldyeEJzcEo2S3dFMkdJdFAyYkJ2VzZQaTRL?= =?utf-8?B?ckdWK1hzWDV2TWRRVHZFQTVjN0RkdUNGVkVhMy95WEF6TTFQN2JFS2o1R0xr?= =?utf-8?B?SjVlYlJPVXBHWXZPTWdkK3dWWXA2aGdtSC8rZG9vRkpzSXZ4SmJZQ3BPcm9G?= =?utf-8?B?bEhZR1RycnZiNTN6bHYyYzA5elFYeWVHbHRka1I2eWs0S1ozcHVralhMUktk?= =?utf-8?B?MUdGTGp2ZmR2K0QrTnFvSnZFZ25pTXFWTUtGdVhKVjFNUHpZaVJNcU1VK2lV?= =?utf-8?B?Nm5jakUxZmdxTTN5RjBEOXFUaFRUYTFKSjBOWnNpYW1NT0xIL2VWbWZFZHNZ?= =?utf-8?B?SHFkQU5xU0NCTmhjUXNNMDBwcjRsdnBzMmViQlJoV3VlNm5Fb3dSWlZveWEx?= =?utf-8?B?bWd3cmhPdDJVUlpMMlFkK3JtZWFCZDVUZ3ZnVmZORFdzTm5ZNVU3VHQrTlcz?= =?utf-8?B?MnIrZWl6c0FrUEw5NmVJb05vb0RaY0M4a0kwRGN2OSt4NEpVdW5OeXZna2ow?= =?utf-8?B?bW8ydE9NbE9na2pmMFA4ZFM4WWZxK0IrRlVWM1J1QXFqT1JIRGkzZlM2WmNG?= =?utf-8?B?TXZVdjh0MW5CN3NndCtibU55dEZBMTVFeDlPS2F6T0pmbVBWSHZOL0tVaHBT?= =?utf-8?B?SUo2MEN2ZHR0dDB1SHovZEoyaHlGY2F0TmU4eU42REZqSjJjOVhJT3F2eUFO?= =?utf-8?B?TGNnTlk5TGQ2bUtZRmhEejZLcGJCUUQ5amVpcDM0Zit3VmNIQTlDYW5jQ2xx?= =?utf-8?B?akxlb1p4YkR1NXpZWWVmdXpnRTB6T1lRRkphSmhBNmVCUjJnZXhtRWV1d3JV?= =?utf-8?B?cVR1YU9aQ29OOVdzeUJPM1BzSXZjRmJmOHZjYmRRL24yTm1xVUNJWmFMS1Rv?= =?utf-8?Q?4qRobH?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0636; 6:v59vQ2dRbIggdYuPXTsuvjnY5JkCn73QuSBO/50bTwWC2iv+41i9ky5j8jyiWpQIkQHQw6zaKBkkRKT/hQ5N9Dp0efLSeSMShoYWrN5ptbtfYl4WK3032QaosjYm+fgLD5yU8fQ2s+sh8u31oGXKFHRGlV101AutHRtIyInHVgtDyeRpGDIeoNpZsl+/J4SoQo+yix/eWWN9kxVkym1UfrzS+0GN9P1HkTZ/fbpEZvVBVIHlAprUkX0A7pNZCXMKd9p3yiHRoN3h18dhRjOkUoS11oIYVVSzrlMGvE3jcZSr+P1H9lKtwNpg0Zk4BuWEZTVsogBv3eQkmDcVtXYNFw==; 5:2IhDmvJ8AE4FyzbpCDMLhr4JauYYORFi6PBKlUm/OgZopn7/CufPXx4/AZ+jYduTSSYoR5t3ZM1MaSGTWW7Qfq49XwTJO8cUZtgXsRqBEQjCAfMSC7vZU0BEskxxMNrkkvKlFExJk68PMjzIQATdgQ==; 24:QQot5N1kDDlPk8dAgROZJyg5KikRNWzOYXSuh5C0cuejM02L9dpEXRzxTuSx+XaovLCm+/WGkSQ4UO/Rbel03wqAMCq/fzD0Xjua/j1mys8=; 7:dG0Tm4sxANiG03qY++1EEq0JEw45uNDAFZwMTmv1KRuFVWcQ7yQbHtl77jhAMm6iHxBNf0YEPpKII3D4EM8LD1fi9Ocsz02wlcuDvmL1LJyvsJZtQLkmKbEz8b34JcuWADhsCHaeDR5oqQUbLky/52+hL0Syn8AGFaKxGH0v3GW6rAyPeyIzB0wGmUQLjz3CMfuuxFhxNz8oLc7kLXJhgeSjsgr1KOI/IHAgCn0QEiY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2017 07:29:13.9402 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0636 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42KZGbHdT/fj7iORBie7hSyOTLnLarHv7Xpm i6/vfrI7MHssWfKTyWPaoswApigum5TUnMyy1CJ9uwSujC9/JjIWbOGv6Lj+l6mBcT1PFyMn h4SAicSzeeuYuhi5OIQEjjBKtD8/ygbhnGCU+PthFwuIwyLQyyzx+848qEwrk8Sn/yfZQfqF BeIktk6eywpiiwikSuxfeJQJxGYWKJRYv/E3WI2QgL3E893/2EBsNgELiS237rOA2LxA8bdH GsFqWARUJd7f+A82R1QgRuLnpUdQNYISJ2c+AbM5BRwkjq29C2RzAM3XlFi/Sx9ilbjErSfz odbKSzRvnc0MUiIhoCBx/VIpyMkSAjMZJb59aGWEOEdbYvmzFhaI930l/l2bzARR9IhJYtu/ ZawQTgO7RE/TP6gqWYmjZ+dA2VoS2x8+BNvGKJAo8ffeWzaIhh1sEhvX3IYrWnf1IzOEnS0x +/Fmdgj7NKvEu1nZEOfJSPz9yzKBUXsWkj9nIfw2C8lvs5D8toCRZRWjaHFqcXFuupGRXmpR ZnJxcX6eXl5qySZGYPI4uOW31Q7Gg88dDzEKcDAq8fB+XnAkUog1say4MvcQowQHs5IIb/lS oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2MznHKc140 uz+8McmVR6dEZ1nP+4CK2A36wmejzv9fqb932ZSEB8Vak1pnuC/QOjB3tUrlfJ1Fv84G7doT 1rLidNi6wz8Y1k1SWSMx2ddcTjhSVcOfzUTN5UFOjZXtnxN7H/ZHflFQ/LFeZLXlzNiZl43D 6l8I3k5XTF71bEVDp7R318WD+5SVlFiKMxINtZiLihMB9USuxBoDAAA= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= 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, 22 Sep 2017 07:29:57 -0000 Hi, I was just having a quick look at the draft and have a couple of questions: At the bottom of page 11: https://tools.ietf.org/html/draft-ietf-core-senml-10#page-11 > SenML defines a > separate media type to indicate Sensor Streaming Measurement Lists > (SensML) for this usage (see Section 12.3.1). Wouldn't it be better to reference Section 12.3.2 instead? On pages 5 and 8 positive t values are described as carrying absolute times while negative values are described as carrying relative times: https://tools.ietf.org/html/draft-ietf-core-senml-10#page-5 > Time is represented in floating point > as seconds and values greater than zero represent an absolute time > relative to the Unix epoch while values of 0 or less represent a > relative time in the past from the current time. https://tools.ietf.org/html/draft-ietf-core-senml-10#page-8 > A time of zero > indicates that the sensor does not know the absolute time and the > measurement was made roughly "now". A negative value is used to > indicate seconds in the past from roughly "now". A positive value is > used to indicate the number of seconds, excluding leap seconds, since > the start of the year 1970 in UTC. Nevertheless, Sections 5.1.2, 5.1.3, and 5.1.7 seem to contain positive t times that are relative times. For example, on Section 5.1.2 (top of page 12): https://tools.ietf.org/html/draft-ietf-core-senml-10#page-12 > {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, > "bu":"%RH","v":21.2}, > {"t":10,"v":21.3}, > {"t":20,"v":21.4} Am I missing something? Cheers, Gonzalo On 05/07/2017 2:23 PM, Jaime Jiménez wrote: > > Dear CoRE WG, > > The core-senml draft has gotten to a state that the authors feel is in > good shape for WGLC.  > We will do a 2 week WGLC before next IETF.  > > _https://tools.ietf.org/html/draft-ietf-core-senml-10_ > > Best Regards, > - - Jaime Jiménez From nobody Fri Sep 22 22:25:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE91321DF; Fri, 22 Sep 2017 22:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 M36ybxzruc5n; Fri, 22 Sep 2017 22:25:01 -0700 (PDT) Received: from mail4.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 41F0A126DD9; Fri, 22 Sep 2017 22:25:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1506144255; h=from:subject:to:date:message-id; bh=xe1sYuwaZDRS+/7jzYaRbl8ZPCKHYSex3Ti80X7B82U=; b=L3NMX1+tByOZKTqkJoVp+VtZMTwINNQ1lcrbJpb3RDiLChYPyFs1cXbJbP8OsKHxrAI7YCkuSKE 1/qy16cY8Tzddp07+MUpZorjXaMlhWkOpsJnkbkjVePEFcptWQVMFLafCyDT1KuHoHNx2ll6ufY3Z 3+4XMMPUAbJJtyfKNJ2u2iTITpRECduTkp/DRYeX6i+hiB/vDY5Th6ccMMkdI3TfTWfB73xdy3QK4 3uyYqROPv/UVqhoj6vCjJiJfJmt4Pus9eOdyWU4MhB+nq60Ag27lnyNb50C+RC6Y1e9HPWVnTtaQ7 Ry6Ve6fKvaYbrSo1V4ljWLQG7pN+nenc6k0A== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 22 Sep 2017 22:24:14 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 22 Sep 2017 22:24:10 -0700 From: Jim Schaad To: CC: Date: Fri, 22 Sep 2017 22:24:51 -0700 Message-ID: <004701d3342c$49dcaa40$dd95fec0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdM0KFeJbiwpO4JKRpGarGSVA2iHYw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] draft-ietf-core-senml - Last Call comments 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, 23 Sep 2017 05:25:02 -0000 I believe that this document is ready to proceed with some nits. I am not really setup to do a competent review on the technical aspects of the document, however they seem to be clear to me. * Section 4.2 - Update Time: I suggest that the sentence starts w/ "An optional value in sections that represents the maximum time". The time after optional confused me as I initially read this as a time not as a delta time. There may also be a requirement here that an actual time value exist somewhere so that one can compute the absolute time that an update should occur by. * Section 4.4 - It is not clear to me that all of the base values in section 4.1 provide all of the information needed in order to resolve. While I can infer most of them, I am unclear what to do with Version. * Section 4.4 - It may be a good idea to indicate in this section that all base values are to start with the letter b so that if a new base value is found by a resolver it will know that it has a problem. * Section 6 - I am sad, but I understand the reasons for the decision, that Octets are not encoded as binary values. * Section 6 - It might be a good idea to also provide the example in CBOR Diagnostic notation. That is easier to read and gives a better idea of what the content structure is. * Section 9 - I have a problem here because in CoAP fragments are not currently transmitted thus the example in 9.1 is probably not a useful item if you are trying to reduce the transmission size. Do you just want to use a query parameter instead? If not then you need to provide some additional explanation. * Section 12.1 - You might want to include a note for the RFC editor to reverse the order of note 1 and note 2 as they do not appear in that order in the table. * Section 12.2 - I am not clear that the column "XML Type" should refer to XML. I assume that this is also the type used for JSON and CBOR. * Section 14 - You might want to re-iterate the Privacy consideration that you noted in Section 4.3 when dealing with name assignment. The section you are dealing with has a reference for dealing with IPv6, but not for the other recommended name times. Jim From nobody Fri Sep 22 22:58:32 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7299133039 for ; Fri, 22 Sep 2017 22:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 NGNP43DR9CvW for ; Fri, 22 Sep 2017 22:58:30 -0700 (PDT) Received: from mail4.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 2FF4F126DD9 for ; Fri, 22 Sep 2017 22:58:30 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1506146265; h=from:subject:to:date:message-id; bh=0GafrH9rMx6LScIvqtfFmudK0Salah2immPPwIm97M0=; b=SvSU70h0OicMFLkdCZio8q/i3ItcMFHnH13CktkKxrOGd+XIwE3rUL+KkiG5+dgINvtTjGYtW9r aiBJz6p+QiwYZVxIFtbK5FHFcOg/+YynAO7BBP5eAfzoD44zZWoCvJOw4dLrjtf1bhldldW+CA4G2 foICm8pChOnKEn4P5jASQVJ/eLNpPTiboGJwnSbCn1FuR+cr8G7I/Q3kHB6h7GtSc9F1uFa1+M1Cx ZAszPEGKVv9gh2ALx9AMoUks28Ndgc4gS6AEEVTqikMqwzywDDJjj/raUlq346YPhl/HC0iTwg0g2 VVwoy4WDL8CR8MunWROo+IUDrsa+g38mzlgg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 22 Sep 2017 22:57:43 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 22 Sep 2017 22:57:38 -0700 From: Jim Schaad To: 'Gonzalo Camarillo' , =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= , CC: References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> In-Reply-To: Date: Fri, 22 Sep 2017 22:58:19 -0700 Message-ID: <004a01d33430$f6f2faf0$e4d8f0d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLhjX+UyWjbSW8rvvt5oU31p5PbYwKP5hCJoJDHnWA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= 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, 23 Sep 2017 05:58:32 -0000 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Gonzalo = Camarillo > Sent: Friday, September 22, 2017 12:29 AM > To: Jaime Jim=C3=A9nez ; core@ietf.org WG > > Cc: draft-ietf-core-coap-senml@ietf.org > Subject: Re: [core] =F0=9F=94=94 WGLC on draft-ietf-core-coap-senml >=20 > Hi, >=20 > I was just having a quick look at the draft and have a couple of = questions: >=20 > At the bottom of page 11: >=20 > https://tools.ietf.org/html/draft-ietf-core-senml-10#page-11 >=20 > > SenML defines a > > separate media type to indicate Sensor Streaming Measurement Lists > > (SensML) for this usage (see Section 12.3.1). >=20 > Wouldn't it be better to reference Section 12.3.2 instead? >=20 > On pages 5 and 8 positive t values are described as carrying absolute = times > while negative values are described as carrying relative times: >=20 > https://tools.ietf.org/html/draft-ietf-core-senml-10#page-5 >=20 > > Time is represented in floating point > > as seconds and values greater than zero represent an absolute time > > relative to the Unix epoch while values of 0 or less represent a > > relative time in the past from the current time. >=20 > https://tools.ietf.org/html/draft-ietf-core-senml-10#page-8 >=20 > > A time of zero > > indicates that the sensor does not know the absolute time and the > > measurement was made roughly "now". A negative value is used to > > indicate seconds in the past from roughly "now". A positive value = is > > used to indicate the number of seconds, excluding leap seconds, = since > > the start of the year 1970 in UTC. >=20 >=20 > Nevertheless, Sections 5.1.2, 5.1.3, and 5.1.7 seem to contain = positive t times > that are relative times. For example, on Section 5.1.2 (top of page = 12): >=20 > https://tools.ietf.org/html/draft-ietf-core-senml-10#page-12 >=20 > > {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, > > "bu":"%RH","v":21.2}, > > {"t":10,"v":21.3}, > > {"t":20,"v":21.4} >=20 > Am I missing something? You are missing the behavior that occurs when the "bt" time field is = present. Jim >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > On 05/07/2017 2:23 PM, Jaime Jim=C3=A9nez wrote: > > > > Dear CoRE WG, > > > > The core-senml draft has gotten to a state that the authors feel is = in > > good shape for WGLC. > > We will do a 2 week WGLC before next IETF. > > > > _https://tools.ietf.org/html/draft-ietf-core-senml-10_ > > > > Best Regards, > > - - Jaime Jim=C3=A9nez >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Sep 22 23:07:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9112133039 for ; Fri, 22 Sep 2017 23:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 HuWW4aUAlh2I for ; Fri, 22 Sep 2017 23:07:07 -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 2871E126DD9 for ; Fri, 22 Sep 2017 23:07:06 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-ed-59c5fa0891ca Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.FC.20899.80AF5C95; Sat, 23 Sep 2017 08:07:05 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sat, 23 Sep 2017 08:07:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JE0JKvsYeNXbSfj0byxHCy4up+/02tJhfR93cy4luDw=; b=N1UVCiPDVJzEk778aSDsvp7KCQ2CnbdqEtQk8k5sWsz3TvrGe/EDpHq42m/DvQeTIayvX2x7k49cYR/E0BoNoibzLRhnsXm0VX8PZ/KsUPJz6R/AGLDDxWLf33rdi0o9u5H8z0j9u6vapf446vF8BqGqeknK7bNoPZL94LNNYLQ= Received: from [192.168.1.4] (37.33.54.234) by DB3PR07MB0635.eurprd07.prod.outlook.com (2a01:111:e400:943c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Sat, 23 Sep 2017 06:07:02 +0000 To: Jim Schaad , =?UTF-8?Q?'Jaime_Jim=c3=a9nez'?= , CC: References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <004a01d33430$f6f2faf0$e4d8f0d0$@augustcellars.com> From: Gonzalo Camarillo Message-ID: Date: Sat, 23 Sep 2017 09:06:54 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <004a01d33430$f6f2faf0$e4d8f0d0$@augustcellars.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [37.33.54.234] X-ClientProxiedBy: HE1PR0802CA0006.eurprd08.prod.outlook.com (2603:10a6:3:bd::16) To DB3PR07MB0635.eurprd07.prod.outlook.com (2a01:111:e400:943c::25) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2cce3668-3246-49c5-ad1f-08d502494fbe X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR07MB0635; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0635; 3:toGdXDMXFi6+VaqdySY87S77kCgHx0N0mFHNWZWf3ewMZwmyfSlbUlm26lgcQKIpFus373zdzqELXjACuCU27GxiM+66EmVqVbu/CI6hsvCzYfHOvgR6vC4wr9FZNbAmKB8ERTjRUn3JPtD8xWDMT45RMTY0XUsn2m31BTtcZUbti6tK9OIAKE35U8JcS5SJKTObltA38uYGhD/AR/f3SODbw+lTmFI10hK1lonCXmuiFjdrYoGe6aEQrwoGAVr7; 25:7eim2MyiRWekGVuzzBsws07DsddEVDm8KOC8vTzsMjeJS0llCDbEukQ7fH5XR7FqgXnLg384VrEinfa6zD6AAu5u7nwpAvw4IITp8nb+SY0TOjrmcoAfUVm4GU0hom7fP62otAMkYufcoJrLdyAeBVa0GdyRHX25FKh8+FVFZ9ZY/sEMWk9hN/Zwr3cyvnhTXZPPWgnqXejFXz+lWhj2eAKdCL7Zf40lS9xRqIrzrFiLhGOhAfeZHClWHuKT9vDgIP2NEyldTUXp4nu+BP1ffKv+tCKBcnP48vnrFlbzxzybR57QWB5l4x2ZURBJIed+txLv5NncFoC4QGW3bxtwMA==; 31:GcuBnVe33H9FM2ybQSpLYMU4cf7WE/mtD9NrBXP5h6X4aNGdGBfkmXnu3g2O6VJNQH5TBUJS6HR7iQpjZbQG7AzDVaycCU8XDvcmEQGntjAgI5pN/hG/5JQ4Mm2hoZehFSBBppWJN39UJmeiQG2REbNqO7hHFdcpM5UZXRxItdd5MjuH3/zA1UynVuTmFz5sMVxH9hw3lrc1tXAjAt8xw/YX/nLKQ7B1lfYAKZ/Hz44= X-MS-TrafficTypeDiagnostic: DB3PR07MB0635: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0635; 20:lF4JUjjXPN5h+R4FId61fnOWvija57PG1rPj7ZHWH/+nSeObiy+d/2sYZdxgnl4sZdWH0g6yqLGUw0ygD+Y2uTOnVqb+NgcmTUNjcdq6sWIZgWg0wFDcGyVZeOCAw0o5Uu99CKCKboALYOano7Jaf4eya3EV1hyYn1VXAk+p4Uta9yiwx+A03SuS94F3mo1cRgFYqvztCdUSw2NDGVq//YXl3RLOvHrR8kKowvJEzuUkcgC/3tXao1QnfwVLpJBid5aLALtLh6mvQ1rxqKotLcU8oH9mA3H8qYU6yMtGx1PnMZP+/2Ck19FR/SzyhKxynvbHehM4oS2yb3Vgp+gxBY854XQt9jc/6p3Ml0uvWxxA4E/NvBAMgugUYm8iEsiEYu5FIsIEQgEzLsfxl6lxxumXs83anpeDSACohHeyhOdZXkDcfuEuGxHYQE767nK6VUt3pXSxJ4MPUr7PntjHBAkps2b5XDQQiLhou5e8oqYYnGyiJF5+1fjZyDFTnbE+; 4:Syg/M20P6AIqXx5kWVGpTWVAMUjtsCnUYoiHkg/M/ATpcsM7DAkYzsqzPofMFNZH4Q/AwXIo9D7qFly5u2zY88OMD7r2Ta6QElYMAU8blM1EgqLQoKUnLdjSt9fWzfzXceCoHfl2xrnmL6X9a4HgVxga52AP9LOEnjddLoCJfkNWHRJoxmZhMdccas5qPDcPMggWpStnui7cZKBKSNH2+BYx7D6bbihUcWh4V7W8e3icDGAbeAwOTRE2jKWQEX3s X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR07MB0635; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR07MB0635; X-Forefront-PRVS: 0439571D1D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(6009001)(376002)(346002)(189002)(199003)(4326008)(230700001)(105586002)(64126003)(8936002)(25786009)(76176999)(229383001)(58126008)(101416001)(33646002)(97736004)(117156002)(50986999)(106356001)(5660300001)(54356999)(65826007)(6116002)(65806001)(110136005)(478600001)(66066001)(36756003)(16576012)(316002)(3846002)(16526017)(47776003)(65956001)(558084003)(81166006)(2906002)(31686004)(2950100002)(189998001)(6666003)(50466002)(31696002)(6246003)(81156014)(23676002)(230783001)(6486002)(77096006)(83506001)(229853002)(7736002)(305945005)(68736007)(53936002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB0635; H:[192.168.1.4]; 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) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNjM1OzIzOk9YWmxIc2tZdGd3NTBGY3JyYlZLdGNBZElX?= =?utf-8?B?UzFVdlNxSFZTdXVUMTEzYlBmdzVKOTd3bHl4akRkSkttWlZNS0FUU0tDdksw?= =?utf-8?B?Q0VkaDhhWTFVUlRLWlc4VUQ2VXFlZytuL3d1aXRRTmhCSzBDZ21wb2lWS3h4?= =?utf-8?B?aUEzWi9Cd0dVSjAzNTZjOExyZmlXaEJtRFFsTVBpVWdrY1lnYnppTW5BMFFq?= =?utf-8?B?aGtwOXJ0Ui9pcDEydUJDd0Y3Z0lqUUxTSDdMYkcxMTZRcnZLR2NEQ1daekNK?= =?utf-8?B?SlJRcTVseTZCcC9GRVFlT1VIZ0ZFbmJqTUFibkxLaGlOQ3lKMlV2VHdydUhB?= =?utf-8?B?SlI2aWNYZFloaG80SU50MDg4NFZ0VDJVemp0SjhLZEF4Z1dLNmRjUHRwWUlp?= =?utf-8?B?MVM0TWpSUXFlY2o2RlRvWFBXVEFySkpRUXB3Q1VkNFlldGZkNkFNM1JlWDRo?= =?utf-8?B?SlFDenMrWTY5eGpiTDJ5TTc5aUhlVGsxNnVzRmJqV2w2V09sZ3hLY0dTaTVU?= =?utf-8?B?TncxZmVnZFlMdkp1THNVM0hkTnl3OUxkQ2VBTnkvUzYrL3ZwZVhla0JLVHcw?= =?utf-8?B?T3cxdnRsSzVUay9IYWk2eUZ1Y2UwVStYU1FyWEo4R3hwOTdpVGp4dkhicVJo?= =?utf-8?B?WitXbTBIZllocXpmcEJ6cHdnQmZDU1liTnJ5ZDZrcldLNEJZS25JSVFyaWxu?= =?utf-8?B?V2NpdlpoTGNOQXRnQ3FWS1I2S0NpYUdMK1NXQnJHQ2dIRzVmN2lnZlhSL2R4?= =?utf-8?B?Rzl6RHJ3M1p1UTJSYnZ1d2J5YjduY2FRV2FJbW45amNQNkVSYUU0RzZXWU43?= =?utf-8?B?OE1BVkRMTGVMU1hVUWpqL2lzSjdjUnliY1RVaVoxYjY2OHdFZTBoNlgzSHAy?= =?utf-8?B?QkZxUGIvRDRpMWgzRHBrdTRlOE5oYTdFUGFKMHI2dEFlUFhJM1lrQTFPOHZV?= =?utf-8?B?TmdDVzhjd1A5a3lRaUtycW8wNk8zYy9VclVSekxDOERxZXNBSkk0QkRkY0dB?= =?utf-8?B?MmN3M3MwK2VaMHV6WWpDVGhzdVFOamw0aEFMUTBpQXV1WEhxU1UzdU5FVVVq?= =?utf-8?B?ay95SHFxL0xxRTF4NVVKN2I3K3pRWWNzejlEYTZidGhpOElXblhxbDhYMExU?= =?utf-8?B?NHF3SHlIa0t2T0pJQjhwdTNkLytmbWllWVVrMHJaL1JJT0RIb2hZUlZqS25V?= =?utf-8?B?U0FiS0VLWktTYWtYVmhHWDNVdkxES2lWYWExU3R4Z1pNQXpNZTlmNVhid0ps?= =?utf-8?B?VmJqOVozZUtOSEUvVi92amNFSFNEWDZPNkpuSmkvcjJWM3VLc0dQOXJpbXpj?= =?utf-8?B?eVNkcTU1a3IrYTZaZXRlZVVxaU01bXJPV1FnRml1UzlxL2Z1dlhJVVRRUEJ2?= =?utf-8?B?YnVOM1hCc1RDSjJCeEU4RjhyVDRMcWN6cHpMZzJYaUJtdithU00wUTgvVkFq?= =?utf-8?B?OVE3bS91REQvSytEUGRWbm1RLzQrOFBUaVhPSnhWZ1RST3o0NERQemZOU0t1?= =?utf-8?B?dVBFQ3hnZ0VkQjhYaUNhS1NhQjlYM1Q0OTc0KzAvZFN4TVN6cHhIQ0NEUGRX?= =?utf-8?B?UEdLWnE4bGhmOWJRSUIyeGdPbDVZeUZ6b1FuMkVFMXQzV2xTcnAzRHhSUkJE?= =?utf-8?B?L3BKekpuVzhQeklNMzJWZ0FnRVRsd1JKSmdjM3ZPOWVyV1NMUzRuWGdncWxq?= =?utf-8?B?QVJ0OGJ6eWdJeGZpbERWMlZtMHBnL01DZU1VdzRBWW15anNGcnhpUDB5NFJW?= =?utf-8?B?cTNFZXhBYitabGYzRVVnS2d4VmJzYVluT0VObW5jazNQa1QrRFE1MmNEWW1J?= =?utf-8?Q?cbhivgti4Ni0o?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0635; 6:qLo2yL5Q8ho29mwzL4qA4Dk9AYbnVlP72za8pOg0fGhwAGaa6x/M9+2ztbnCjjXgT7Hgbyz7eIR45yaGgM/V/qxrvX0DgAvpPicLEws+6AEMiqsIx1j+awwm+uE3oQu33xAVvaL+QRPb6bnScbRiTzMA+SyiGMiEKikYmwFlnSGjqd7dbkXKnbdYvaydJSxNqOf8VO2mY/xyXsWsb/wXqJDcF6eTmhY2tsXykX+O/hF6Z1UW+mjdbUsgC/tokrSBiHZJB/FtxkmZUlXLbb9NkmaMOBHDIk7LBAaXtQhb0Ez+k2dlHF+Qlvzo0iU1tQaeN8GhAabRbc2pS6f+rYIm2w==; 5:QdefGo6uI6NTliGmosPZL6Jm3YHbY5X3W27PjbfOHrc3mki5o+s27YemfhBK4eZVosuqZ28CztkY7aQmBIXyzYPjzgCLFZ2IAxuNZcFJ2R9sJ9ddh+eU6po9+gddrwe/xPxFv9nv70yxyvt07WcBdg==; 24:0RoJMgt/bbMymnj1W4cGmf3hJtfu7KTqOfn4RMtM+//Zt6efIBJwL0p53sW5s8WltO0751hQOx01VWkaOmJ6kMptZvEh4rZWxoyXHbhCcBE=; 7:pxDDtOxNFSz8tE0+rOeSxtNUbPcclJoH4UrqIdEYN+qihFdWet5kG+cV/7ZsXWG59E9zoYii+bkcVX5MMFZrGbDT1WeIun2F0s6BtkLNNZ90VPwLysGO+1IsvJyxXwmkgm2zUSzQHwXaj+uM5s8+Z5bGC77o6RVPk6/xuYhHgL4WzXoEXFPvSWoM9eRu6umOrehQrTP4uPGCtwRP5b7Fl9FepELJI66cE58gWGJWCKw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2017 06:07:02.7651 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0635 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42KZGbHdT5fz19FIg+Vb2S32vV3PbPH13U92 i9XTv7M5MHtsnDOdzWPJkp9MAUxRXDYpqTmZZalF+nYJXBlf/uUWvGCs2NX5mrmBcSNjFyMn h4SAicTJHQ9YQGwhgSOMEse3mEPYJxgl1vQVdjFycbAI9DJLLHv1m72LkQMo0cokcdQUpEZY IE5i6+S5rCC2iEClRM/m2ewgNrOApsT9zumsIL1CAqsZJR6tuQdWxCZgIbHl1n2wZbwC9hKv P38Fi7MIqEo0XfwI1iwqECPx89IjqBpBiZMzn4DZnAIOEu//fGQCuQFkwfpd+hC7xCVuPZnP BGHLS2x/O4cZ4i8FiS+L5rCA3CAhMJNRYuKHPVBPakssf9bCAlEkK3H07Bwo21fi+pOjUA2P mCR+H7vPBuE0sEvsXfCdCaJKS+JE10+wSxkFEiX+3nsLVbSDTeLf+nlsMEXrrn6EuiNbYu+T DYwQRadZJR4+OAVVJCOxZssNtgmM2rOQvDoL4b1ZSN6bheS9BYwsqxhFi1OLi3PTjYz0Uosy k4uL8/P08lJLNjECk8fBLb+tdjAefO54iFGAg1GJh3fr3aORQqyJZcWVuYcYJTiYlUR4E38A hXhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamC0NlJauOLa gl6+izl26U9yt0/V9M4NX8zn1mCuKrNPcLvbVObkFXNWH3z++rzYX0XbirmGN15NYzE263nm 1l2xf//fejHF8ttBR7aFaj+wfDQ7Quy/4ebwIL+0fW8WXI4vmshxzfIy74TmSfmLU9QtQuQq Duf8YNo/gelsPh8fs4uN+3nRacuUWIozEg21mIuKEwHaastyGgMAAA== Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= 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, 23 Sep 2017 06:07:09 -0000 Hi Jim, > You are missing the behavior that occurs when the "bt" time field is present. where exactly is it defined in the draft how the presence of the bt field modifies the meaning of the time field? Thanks, Gonzalo From nobody Mon Sep 25 07:56:20 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C4A13432C for ; Mon, 25 Sep 2017 07:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2laCoqPmeWTC for ; Mon, 25 Sep 2017 07:56:18 -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 B3343133087 for ; Mon, 25 Sep 2017 07:56:17 -0700 (PDT) X-AuditID: c1b4fb2d-a65ff700000019be-ff-59c915894838 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 33.A1.06590.98519C95; Mon, 25 Sep 2017 16:41:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 16:41:13 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Gonzalo Camarillo CC: Jim Schaad , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , core , "draft-ietf-core-coap-senml@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb24gZHJhZnQtaWV0Zi1jb3JlLWNvYXAtc2Vu?= =?utf-8?Q?ml?= Thread-Index: AQHS9YEpx1mKBvRbS0erW9/y34h5MaLA3GgAgAF494CAAAJmAIADtFsA Date: Mon, 25 Sep 2017 14:41:13 +0000 Message-ID: <3B8A7E04-AA11-48C7-8AB0-E408214E7E75@ericsson.com> References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <004a01d33430$f6f2faf0$e4d8f0d0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7qG6X6MlIg7NNbBb73q5ntvj67ie7 xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsErow1c90LnnBXNH7/ytbAuIe7i5GT Q0LARGJS00W2LkYuDiGBI4wSX972sUA4ixgl+lqXsIJUsQnYSjxp3QdmiwiYSSxuW8MEUsQs cJZR4sHtMywgCWGBNIk7N+8CjeIAKkqX+HWoBqLeTWLCxUdMIDaLgKpE95ufzCA2r4C9xL+n V5kglj1klFjX/YodJMEp4CDx5NoBNhCbUUBM4vupNWDNzALiEreezGeCOFtAYsme88wQtqjE y8f/WCFsJYlFtz8zgdzALKApsX6XPoRpLfH1kTnEFEWJKd0P2SFOEJQ4OfMJywRGsVlIFsxC aJ6F0DwLSfMsJM0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG1sEtv3V3MK5+7XiI UYCDUYmHV57lZKQQa2JZcWXuIUYJDmYlEd7rnEAh3pTEyqrUovz4otKc1OJDjNIcLErivA77 LkQICaQnlqRmp6YWpBbBZJk4OKUaGOuN91+zb1EpSNLbEpzWov5mZ6PVh/snWwx/Pfn4p6Ls n4PbP++Qo6W/ta99XvZGm2fqGsOFG6dpbGTVEnui8vvTkU3NR1k6fa8v9zI4yjDpb+wj63xW 3Y5V115baxs1zno71Su44fCthENPGu6zP1/tzdB5VVz5cZh+bOMyBcvJ9swLlz0PeKTEUpyR aKjFXFScCABEDZE2qQIAAA== Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= 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, 25 Sep 2017 14:56:20 -0000 SGkgR29uemFsbywNCg0KPiBPbiAyMyBTZXAgMjAxNywgYXQgOS4wNiwgR29uemFsbyBDYW1hcmls bG8gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBKaW0s DQo+IA0KPj4gWW91IGFyZSBtaXNzaW5nIHRoZSBiZWhhdmlvciB0aGF0IG9jY3VycyB3aGVuIHRo ZSAiYnQiIHRpbWUgZmllbGQgaXMgcHJlc2VudC4NCj4gDQo+IHdoZXJlIGV4YWN0bHkgaXMgaXQg ZGVmaW5lZCBpbiB0aGUgZHJhZnQgaG93IHRoZSBwcmVzZW5jZSBvZiB0aGUgYnQNCj4gZmllbGQg bW9kaWZpZXMgdGhlIG1lYW5pbmcgb2YgdGhlIHRpbWUgZmllbGQ/DQoNClRoYXQncyBkZWZpbmVk IGluIHNlY3Rpb24gNC4zIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLXNlbm1sLTEwI3BhZ2UtOCk6DQoNCj4gICAgSWYgZWl0aGVyIHRoZSBCYXNlIFRpbWUgb3Ig VGltZSB2YWx1ZSBpcyBtaXNzaW5nLCB0aGUgbWlzc2luZyBmaWVsZA0KPiAgICBpcyBjb25zaWRl cmVkIHRvIGhhdmUgYSB2YWx1ZSBvZiB6ZXJvLiAgVGhlIEJhc2UgVGltZSBhbmQgVGltZSB2YWx1 ZXMNCj4gICAgYXJlIGFkZGVkIHRvZ2V0aGVyIHRvIGdldCB0aGUgdGltZSBvZiBtZWFzdXJlbWVu dC4gIEEgdGltZSBvZiB6ZXJvDQo+ICAgIGluZGljYXRlcyB0aGF0IHRoZSBzZW5zb3IgZG9lcyBu b3Qga25vdyB0aGUgYWJzb2x1dGUgdGltZSBhbmQgdGhlDQo+ICAgIG1lYXN1cmVtZW50IHdhcyBt YWRlIHJvdWdobHkgIm5vdyIuICBBIG5lZ2F0aXZlIHZhbHVlIGlzIHVzZWQgdG8NCj4gICAgaW5k aWNhdGUgc2Vjb25kcyBpbiB0aGUgcGFzdCBmcm9tIHJvdWdobHkgIm5vdyIuICBBIHBvc2l0aXZl IHZhbHVlIGlzDQo+ICAgIHVzZWQgdG8gaW5kaWNhdGUgdGhlIG51bWJlciBvZiBzZWNvbmRzLCBl eGNsdWRpbmcgbGVhcCBzZWNvbmRzLCBzaW5jZQ0KPiAgICB0aGUgc3RhcnQgb2YgdGhlIHllYXIg MTk3MCBpbiBVVEMuDQoNCg0KDQpBbmQgZ29vZCBjYXRjaCB3aXRoIHRoZSBTZW5zTUwgc2VjdGlv biBjcm9zcy1yZWZlcmVuY2U7IEknbGwgZml4IHRoYXQgZm9yIHRoZSBuZXh0IHJldmlzaW9uLg0K DQoNCkNoZWVycywNCkFyaQ== From nobody Tue Sep 26 14:10:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DC913447E for ; Tue, 26 Sep 2017 14:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 dWgv1BqL15sp for ; Tue, 26 Sep 2017 14:10:01 -0700 (PDT) Received: from mail4.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 C967A134478 for ; Tue, 26 Sep 2017 14:10:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1506460154; h=from:subject:to:date:message-id; bh=H0WTeSmhBZ2BCsQUPqpgbxHsI00ej8I2Qr+BJJ2Fh9g=; b=CUPWb+9eqhcMhEvzOM/NCIcdrb92KEqiEjwlt5RdwrNHCuKq8X4tUZzmlUB5CH/wOnmEjW4uQGW ydSuBF3NBodICTBxtK7jLupEM78AuhZXH5KKMP0TG8LhDhcAKDKJ7zgrpewJWc2Mx4g5psucgtN2q wvEW/Pa8cdkCuD1pSPjFRVM3z4uqoc5b6n1ssMyDnGX+F2GdNEDS9kt00BcD19ijONSNua+0vToTo /xYNJlJ+Ztr/Lvgw4vHEJ5sHDNdvCjZQqRYMz6rogURi1i3LnF3l3LzifU1cSaYH3HQzuU1rxKCsA 2V5VQGF6JhN5t+HTCNges9qHrwGMUVMrokEw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 26 Sep 2017 14:09:14 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 26 Sep 2017 14:09:09 -0700 From: Jim Schaad To: Date: Tue, 26 Sep 2017 14:09:52 -0700 Message-ID: <01c801d3370b$cd08f2c0$671ad840$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdM3CyfNZu89zPpDRpewjIjTTFzM5A== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Max-Age question 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, 26 Sep 2017 21:10:03 -0000 I am trying to figure out the correct behavior for a Pub-Sub server with respect to the Max-Age value and I cannot find what I think of as good guidance in RFC 7252. If I specify a Max-Age value, then the client can assume that the response is good for that long. If I specify a Max-Age value of 0, then I am telling an intermediary not to cache the value, but I am not making a statement that the value is "stale" in some way (maybe). If I return a value for Ma-Age of 0, should the client assume that the value is stale and potentially ignore it? If I return an error, not sure what error would be appropriate, this seems to be a bad choice as intermediaries might decide to unsubscribe people from the resource. The question is, if a server sees a resource as stale, specifically a pub-sub resource where it was told a Max-Age, what should the server do when queried? Jim From nobody Tue Sep 26 14:17:45 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C34134476 for ; Tue, 26 Sep 2017 14:17:43 -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 zfqFW6jmFXoe for ; Tue, 26 Sep 2017 14:17:42 -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 66957133083 for ; Tue, 26 Sep 2017 14:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8QLHAIc000249; Tue, 26 Sep 2017 23:17:10 +0200 (CEST) Received: from [172.20.10.9] (ip-109-45-2-182.web.vodafone.de [109.45.2.182]) (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 3y1v0k44bTzDLTm; Tue, 26 Sep 2017 23:17:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <01c801d3370b$cd08f2c0$671ad840$@augustcellars.com> Date: Tue, 26 Sep 2017 23:17:09 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 528153429.746078-991429b76b255229bd12e1cc1b666c47 Content-Transfer-Encoding: quoted-printable Message-Id: <10B8B2B8-090D-4BF5-A6E6-73FDEEF88E6F@tzi.org> References: <01c801d3370b$cd08f2c0$671ad840$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Max-Age question 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, 26 Sep 2017 21:17:43 -0000 On Sep 26, 2017, at 23:09, Jim Schaad wrote: >=20 > I am trying to figure out the correct behavior for a Pub-Sub server = with > respect to the Max-Age value and I cannot find what I think of as good > guidance in RFC 7252. >=20 > If I specify a Max-Age value, then the client can assume that the = response > is good for that long. Right. (And there is a default value for Max-Age, so you cannot not = specify a value.) > If I specify a Max-Age value of 0, then I am telling an intermediary = not to > cache the value, but I am not making a statement that the value is = "stale" > in some way (maybe). Right. > If I return a value for Ma-Age of 0, should the client assume that the = value > is stale and potentially ignore it? Who is I? Max-Age 0 means =E2=80=9Cvalid now, but no guarantees for the = future=E2=80=9D. The =E2=80=9Cnow=E2=80=9D obviously includes a tolerance for transfer = times (which can vary considerably). > If I return an error, not sure what error would be appropriate, this = seems > to be a bad choice as intermediaries might decide to unsubscribe = people from > the resource. Right. > The question is, if a server sees a resource as stale, specifically a > pub-sub resource where it was told a Max-Age, what should the server = do when > queried? It may sometimes be better to have a stale value than no value at all, = at least if you know the value is stale. Unfortunately, we haven=E2=80=99t created a way to *transfer* such a = value (but a cache can *hold* such a value and make it available as = stale locally). [A negative max-age might be appropriate here, except that CoAP=E2=80=99s = option type system doesn=E2=80=99t have negative numbers so far. Maybe = a stale-for option should be added to hold the absolute...] Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Sep 26 15:17:55 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75521344B9 for ; Tue, 26 Sep 2017 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 oM4ImZ11fxLd for ; Tue, 26 Sep 2017 15:17:52 -0700 (PDT) Received: from mail4.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 A9BA71344B3 for ; Tue, 26 Sep 2017 15:17:52 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1506464226; h=from:subject:to:date:message-id; bh=lu4e6JFRsAcepk1Nok4OgHsVlbe0jUmdCpWCKwUndLU=; b=Mw480x8jqJ6QwIHVI6rhum9AcEIAiPubQpVal/DZ4WG3yqmZWPaUz6Qzf9LCf8/rqsjJKHotTKV QY5CdyAODr3CxEcYKeL/In3+MnmJr/P5iFyFxC/eURjRKozln0OzPbTfOfuy4bsf+TvuV76Pv07jY CDoabWXa3Av7BFg9j6VGEhG/qE+ndq8QTf3BGbCzFhmjPizRUKmviwY1xuHfxhTiRuzE4WEIqd8L3 UUsd2Va7v+oxsVHlrMk2f58roTrHiLbqz+WVRer8C6LRqfqT8jGEPvsIsYYUWjj+Y2EMsQZOGDuiD MJvYN9zL9spobfyIUJ2jKeUdE7l9HSqUPl5Q== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 26 Sep 2017 15:17:05 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 26 Sep 2017 15:17:01 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <01c801d3370b$cd08f2c0$671ad840$@augustcellars.com> <10B8B2B8-090D-4BF5-A6E6-73FDEEF88E6F@tzi.org> In-Reply-To: <10B8B2B8-090D-4BF5-A6E6-73FDEEF88E6F@tzi.org> Date: Tue, 26 Sep 2017 15:17:44 -0700 Message-ID: <01d401d33715$48461630$d8d24290$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJawMQJheHiwrpTlp2lGFGaTw7wowGTK7ojoawPYLA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Max-Age question 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, 26 Sep 2017 22:17:54 -0000 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Tuesday, September 26, 2017 2:17 PM > To: Jim Schaad > Cc: core@ietf.org > Subject: Re: [core] Max-Age question >=20 > On Sep 26, 2017, at 23:09, Jim Schaad wrote: > > > > I am trying to figure out the correct behavior for a Pub-Sub server > > with respect to the Max-Age value and I cannot find what I think of = as > > good guidance in RFC 7252. > > > > If I specify a Max-Age value, then the client can assume that the > > response is good for that long. >=20 > Right. (And there is a default value for Max-Age, so you cannot not = specify a > value.) >=20 > > If I specify a Max-Age value of 0, then I am telling an intermediary > > not to cache the value, but I am not making a statement that the = value is > "stale" > > in some way (maybe). >=20 > Right. >=20 > > If I return a value for Ma-Age of 0, should the client assume that = the > > value is stale and potentially ignore it? >=20 > Who is I? Max-Age 0 means =E2=80=9Cvalid now, but no guarantees for = the future=E2=80=9D. > The =E2=80=9Cnow=E2=80=9D obviously includes a tolerance for transfer = times (which can vary > considerably). >=20 > > If I return an error, not sure what error would be appropriate, this > > seems to be a bad choice as intermediaries might decide to = unsubscribe > > people from the resource. >=20 > Right. >=20 > > The question is, if a server sees a resource as stale, specifically = a > > pub-sub resource where it was told a Max-Age, what should the server > > do when queried? >=20 > It may sometimes be better to have a stale value than no value at all, = at least if > you know the value is stale. > Unfortunately, we haven=E2=80=99t created a way to *transfer* such a = value (but a > cache can *hold* such a value and make it available as stale locally). > [A negative max-age might be appropriate here, except that = CoAP=E2=80=99s option > type system doesn=E2=80=99t have negative numbers so far. Maybe a = stale-for option > should be added to hold the absolute...] This is what I was looking for as an answer - either that or an error = which says "My content is stale - but here it is" For now, I guess I will just use a Max-Age of 0. Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Sep 29 06:11:27 2017 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 33E1F13451E; Fri, 29 Sep 2017 06:11:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150669068216.13960.3827713803247431470.idtracker@ietfa.amsl.com> Date: Fri, 29 Sep 2017 06:11:22 -0700 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 100 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, 29 Sep 2017 13:11:26 -0000 A new meeting session request has just been submitted by Carsten Bormann, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor httpbis artarea t2trg ace lpwan 6lo roll teep fud Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm dinrg Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Please also avoid any IoT related BOFs that might come up. *Preferred* pairing: Tue/Thu or other space between; Friday is also no problem. --------------------------------------------------------- From nobody Fri Sep 29 10:52:27 2017 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 51B3613420B; Fri, 29 Sep 2017 10:52:24 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150670754430.24529.18242169060275112154@ietfa.amsl.com> Date: Fri, 29 Sep 2017 10:52:24 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-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: Fri, 29 Sep 2017 17:52:24 -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-05.txt Pages : 45 Date : 2017-09-29 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 encryption, integrity and replay protection, as well as a secure message binding. OSCORE is designed for constrained nodes and networks and can be used over any layer and across intermediaries, and also with HTTP. OSCORE may be used to protect group communications as is specified in a separate draft. 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-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 Fri Sep 29 11:04:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B911313321F for ; Fri, 29 Sep 2017 11:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtcrVGteH_UB for ; Fri, 29 Sep 2017 11:04:40 -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 941E3126BF3 for ; Fri, 29 Sep 2017 11:04:40 -0700 (PDT) X-AuditID: c1b4fb25-a5fff700000060a2-06-59ce8b3652d0 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 96.79.24738.63B8EC95; Fri, 29 Sep 2017 20:04:38 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.166]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Fri, 29 Sep 2017 20:04:37 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: New version of OSCOAP/OSCORE Thread-Index: AQHTOU1qVElPoZj890mb4qlA/lhefQ== Date: Fri, 29 Sep 2017 18:04:37 +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+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7ma5Z97lIg0vPpS32vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLW7ZzAVNGhWfH76mbmB8Yd6FyMnh4SAicThHW3MXYxcHEIC Rxgl/nz6ywThLGGU+PbvCQtIFZuAi8SDhkdMILaIgLLE5jOvGUFsYQE1id+v97NAxLUlTv4+ zw5h60ks/nuUrYuRg4NFQFVixgtlEJNXwEJiRnMxSAWjgJjE91NrwCYyC4hL3HoynwniHgGJ JXvOM0PYohIvH/9jBbFFgSbu7Wlng4grSnx8tY8RZCSzgKbE+l36EGOsJd7d28QKYStKTOl+ CHYMr4CgxMmZT1gmMIrMQrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGxXmpRZnJxcX6e Xl5qySZGYDQc3PJbdQfj5TeOhxgFOBiVeHjnlp+LFGJNLCuuzD3EKMHBrCTCy1YPFOJNSays Si3Kjy8qzUktPsQozcGiJM7ruO9ChJBAemJJanZqakFqEUyWiYNTqoEx8ceb2FshSjwzRDdf ed3za/v1ayJbuTbfnxf+0zRP6PLLDMXPKR+Yvucos9X8iFlhx8x3fo5t4HeX9r2pbj0njBQW 6z6siRL+JpBUdHqdOPPaHtF3PI7JO1W/zLj+5VGfcsXi4M8zoicca58lExzfnmh5fO2tTVdi i1h+nvrpdaC69sapdVJLlFiKMxINtZiLihMBqogUr4ICAAA= Archived-At: Subject: [core] New version of OSCOAP/OSCORE 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, 29 Sep 2017 18:04:42 -0000 DQpIaSwNCg0KSGVyZSBpcyB2ZXJzaW9uIC0wNSBvZiB0aGUgcHJvdG9jb2wgZm9ybWVybHkga25v d24gYXMgT1NDT0FQLiBNb3JlIGFib3V0DQp0aGUgbmFtZSBiZWxvdy4NCg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDUNCg0KDQpU aGlzIHZlcnNpb24gaXMgYmFzZWQgb24gYSBudW1iZXIgb2YgaW5wdXRzIGFuZCBjaGFuZ2UgcHJv cG9zYWxzIHNpbmNlDQooYW5kIGluY2x1ZGluZykgdGhlIFByYWd1ZSBGMkYgbWVldGluZywgYW5k IGFsc28gY2xvc2VkIG1vc3Qgb2xkIGlzc3Vlcy4NCkl0IHRvb2sgbG9uZ2VyIHRoYW4gZXhwZWN0 ZWQsIHNvcnJ5IGZvciB0aGUgZGVsYXkuIFRoZSBtYWluIGNoYW5nZXMgYXJlOg0KDQotIENvQVAg Q29kZSBpcyBub3cgZW5jcnlwdGVkDQotIFN1cHBvcnQgZm9yIGVuZC10by1lbmQgUkVTVA0KLSBB IG5ldyBwcm94eSBzZWN0aW9uIGRpc2N1c3NpbmcgQ29BUC1Db0FQLCBIVFRQLUNvQVAgYW5kIENv QVAtSFRUUA0KLSBTaW1wbGlmaWVkIGRlc2NyaXB0aW9uIG9mIE9wdGlvbiBwcm9jZXNzaW5nDQot IFNpbXBsaWZpZWQgbm9uY2UgY29uc3RydWN0aW9uIGFsc28gcmVkdWNpbmcgdGhlIHNpemUgb2Yg dGhlIHNlY3VyaXR5DQpjb250ZXh0DQotIE9wdGltaXplZCBDT1NFIGNvbXByZXNzaW9uDQotIE9w dGlvbmFsIGNvbnRleHQgaGludCBmb3Igc2ltcGxpZnlpbmcgcmV0cmlldmFsIG9mIHNlY3VyaXR5 IGNvbnRleHQNCi0gTW9yZSBkZXRhaWxlZCBlcnJvciBwcm9jZXNzaW5nDQotIE5hbWUgY2hhbmdl ZCB0byBPU0NPUkUNCg0KU2V2ZXJhbCBvdGhlciBtaW5vciB1cGRhdGVzIGFuZCBjbGFyaWZpY2F0 aW9ucyB3ZXJlIG1hZGUsIHNlZSBDb1JF4oCZcw0KR2l0aHViIGZvciBkZXRhaWxzIFsxXS4NCg0K QW5kIG5vdyBmb3IgdGhlIG5hbWUuIE9DRiB3YXMgcmV2aWV3aW5nIE9TQ09BUCBkdXJpbmcgdGhl IHNwcmluZyBhbmQNCnJlcXVlc3RlZCAoY2hhbm5lbGxlZCB0aHJvdWdoIERhdmUgVGhhbGVyKSB0 aGF0IHRoZSBwcm90b2NvbCBzaG91bGQgYmUNCnNwZWNpZmllZCB0byBoYW5kbGUgdHJhbnNsYXRp b24gYmV0d2VlbiBDb0FQIGFuZCBIVFRQIHdoaWxlIG1haW50YWluaW5nDQplbmQtdG8tZW5kIHNl Y3VyaXR5IG9mIHRoZSBSRVNUZnVsIGV4Y2hhbmdlLiBUaGlzIHR1cm5lZCBvdXQgdG8gbm90DQpy ZXF1aXJlIHRvbyBtYW55IGNoYW5nZXMgYW5kIERhdmUga2luZGx5IG1hZGUgYSByZXdyaXRlIG9m IHRoZSBkb2N1bWVudCBpbg0KdGhpcyByZWdhcmQuIFNpbmNlIHRoZSBwcm90b2NvbCBpcyBubyBs b25nZXIgbGltaXRlZCB0byBDb0FQLCBEYXZlIGFsc28NCnByb3Bvc2VkIGEgbmFtZSBjaGFuZ2Ug dG8gT2JqZWN0IFNlY3VyaXR5IGZvciBDb25zdHJhaW5lZCBSZXN0ZnVsDQpFbnZpcm9ubWVudHMg KE9TQ09SRSkuDQoNCldlIGRlY2lkZWQgdG8gaW5jbHVkZSBhbGwgY2hhbmdlcyBpbnRvIG9uZSB2 ZXJzaW9uIHRvIHNpbXBsaWZ5IHRoZQ0KZGlzY3Vzc2lvbi4gVGhlIGRvY3VtZW50IGlzIG5vdyBy ZWFkeSBmb3IgcmV2aWV3Lg0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUhDQoNCkfDtnJhbiBv biBiZWhhbGYgb2YgdGhlIGVkaXRpbmcgdGVhbQ0KDQoNClsxXSBodHRwczovL2dpdGh1Yi5jb20v Y29yZS13Zy9vc2NvYXANCg0KDQoNCg0KDQpPbiAyMDE3LTA5LTI5IDE5OjUyLCAiY29yZSBvbiBi ZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPGNvcmUtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cw0KPmRpcmVjdG9yaWVzLg0KPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IENvbnN0cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzIFdHIG9mDQo+dGhlIElFVEYuDQo+DQo+ ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBPYmplY3QgU2VjdXJpdHkgZm9yIENvbnN0cmFpbmVk IFJFU1RmdWwNCj5FbnZpcm9ubWVudHMgKE9TQ09SRSkNCj4gICAgICAgIEF1dGhvcnMgICAgICAg ICA6IEfDtnJhbiBTZWxhbmRlcg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgSm9obiBNYXR0 c3Nvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgRnJhbmNlc2NhIFBhbG9tYmluaQ0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgTHVkd2lnIFNlaXR6DQo+CUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDUudHh0DQo+CVBhZ2VzICAgICAgICAg ICA6IDQ1DQo+CURhdGUgICAgICAgICAgICA6IDIwMTctMDktMjkNCj4NCj5BYnN0cmFjdDoNCj4g ICBUaGlzIGRvY3VtZW50IGRlZmluZXMgT2JqZWN0IFNlY3VyaXR5IGZvciBDb25zdHJhaW5lZCBS RVNUZnVsDQo+ICAgRW52aXJvbm1lbnRzIChPU0NPUkUpLCBhIG1ldGhvZCBmb3IgYXBwbGljYXRp b24tbGF5ZXIgcHJvdGVjdGlvbiBvZg0KPiAgIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQ cm90b2NvbCAoQ29BUCksIHVzaW5nIENCT1IgT2JqZWN0DQo+ICAgU2lnbmluZyBhbmQgRW5jcnlw dGlvbiAoQ09TRSkuICBPU0NPUkUgcHJvdmlkZXMgZW5kLXRvLWVuZA0KPiAgIGVuY3J5cHRpb24s IGludGVncml0eSBhbmQgcmVwbGF5IHByb3RlY3Rpb24sIGFzIHdlbGwgYXMgYSBzZWN1cmUNCj4g ICBtZXNzYWdlIGJpbmRpbmcuICBPU0NPUkUgaXMgZGVzaWduZWQgZm9yIGNvbnN0cmFpbmVkIG5v ZGVzIGFuZA0KPiAgIG5ldHdvcmtzIGFuZCBjYW4gYmUgdXNlZCBvdmVyIGFueSBsYXllciBhbmQg YWNyb3NzIGludGVybWVkaWFyaWVzLA0KPiAgIGFuZCBhbHNvIHdpdGggSFRUUC4gIE9TQ09SRSBt YXkgYmUgdXNlZCB0byBwcm90ZWN0IGdyb3VwDQo+ICAgY29tbXVuaWNhdGlvbnMgYXMgaXMgc3Bl Y2lmaWVkIGluIGEgc2VwYXJhdGUgZHJhZnQuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS8NCj4NCj5UaGVyZSBhcmUg YWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDUNCj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJp dHktMDUNCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY29yZS1v YmplY3Qtc2VjdXJpdHktMDUNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Y29yZSBtYWlsaW5n IGxpc3QNCj5jb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlDQoNCg==