From nobody Thu Dec 1 00:50:56 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D9C129C54 for ; Thu, 1 Dec 2016 00:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJHP89RkcqDL for ; Thu, 1 Dec 2016 00:50:42 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DF0129C42 for ; Thu, 1 Dec 2016 00:50:22 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud3.xs4all.net with ESMTP id EYqJ1u0084ydcfa01YqJnH; Thu, 01 Dec 2016 09:50:20 +0100 Received: from 2001:983:a264:1:482f:dfa5:11e6:f340 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 01 Dec 2016 09:50:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 01 Dec 2016 09:50:18 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <0c85346845306da9e01117bedd9e5747@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (6Vx2g3Bn/eFZ4WDP9DYxMyB8OS4qGtj1) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] yang cbor comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 08:50:46 -0000 Hi Michel, Glad that you saw my point. your text should be OK. thanks. I still need to understand the text on anydata and anyxml Peter Michel Veillette schreef op 2016-11-30 22:59: > Hi Peter > > === About " My proposal: The following example shows the encoding of > the value "eth1" assigned to the leaf 'interface-state-ref'." > > All examples have been fixed with the following scheme: > The following example shows the encoding of an > 'interface-state-ref' leaf instance set to "eth1". > See diff at > > https://github.com/core-wg/yang-cbor/commit/6f514542d5d09ec5c992e095dd609c68303cdb89#diff-083fd5e71ffd63b12d8cd2854c3ad1bf > > Your proposed solution works fine for this specific example but was > hard to apply to all examples. > I'm also not sure about the use of "assigned" which seem to imply a > previous PUT or POST. > I'm open the revisit this wording if needed. > > === About the into of section 5, I proposing the following text based > on the intro present in https://tools.ietf.org/html/rfc7951#section-6 > > The CBOR encoding of an instance of a leaf or leaf-list data node > depends on the built-in type of that data node. The following > sub-section defined the CBOR encoding of each built-in type supported > by YANG as listed in [RFC7950] section 4.2.4. Each subsection shows an > example value assigned to a data node instance of the discussed > built-in type. > > The update draft is available at > http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt > > Regards, > Michel > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Wednesday, November 30, 2016 3:29 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] yang cbor comments > > Hi Michel, > > Apologies for the late reaction, but I was occupied by other things, > and almost forgot. > > Let me give one example from section 5.9 > > The text says: The following example shows the encoding of leaf > 'interface-state- > ref' set to the value "eth1". > > However it is NOT the encoding of the leaf, but the encoding of the > value of the leaf. (that's where my confusion comes from, sorry to > seem to be nit-picking) > > My proposal: > > The following example shows the encoding of the value "eth1" assigned > to the leaf 'interface-state-ref'. > > I hope I made my point clearer. > > You may start the sections 5, before section 5.1, with the following > text: > In the folowing examples values of the discussed type are assigned to > an example leaf of the discussed type. > Consectively, the CBOR encoding of the value is shown. > (Or similar but much better text.) >> > >>> ====> Examples of section 5. Do the examples not need an identifier >>> (CBOR key)? We now are faced with values which do not belong >>> anywhere. >>> Also the SID value needs to be specified. For example section 5.1 can >>> be written as follows: >>> The leaf mtu is assumed to have value 1280 The sid of mtu is 1350 The >>> CBOR diagnostic notation of the pair is 1350: 1280, which results in >>> Page 15 /signed integer/negative integer/ >>> >>> Same answer as above. >>> None of the YANG Data Node Instances defined in section 4 (leaf, >>> container, leaf-list, list, anydata, anyxml) is encoded with its >>> identifier. >>> Such identifiers are part of the instance-identifier carry in the >>> request URI or within the payload. >>> This is the job of CoMI >>> >>> ====>Section 5.10.1; it is unclear where the value 1180 comes from. >> >> I seem to express myself badly. >> It is only needed to say that mtu is assumed to have value 1280 and >> that the CBOR encoding of 1280 is: >> >> At this moment the scope of the example CBOR code is unclear. >> >> [MV] in section 5.1, the example is introduced with the sentence: >> [MV] "The following example shows the encoding of leaf 'mtu' set to >> 1280 bytes." >> [MV] Is it the part that is unclear? >> [MV] Can you propose an updated text to clarify this example? >> >>> ====> Section 5.13 is very unclear. There are many examples but it is >>> not clear where all these values come from; what is the SID value, >>> what was the leaf instance value, is one large puzzle. One example >>> (instead of 3), but with more explanations would help. In my opinion >>> the text in belongs in the FETCH content format document that still >>> needs to be written. >>> >>> The multiple examples have been requested by different peoples >>> including Carsten. >>> These examples show completely different use cases, single instance >>> data node, list and list instance and are all useful. >>> For the question, "what is the SID value", this will be resolved by >>> the implementation of the registrars sharing a common database >>> (blockchain) of .sid files. >> >> please see my responses above. >> Not the examples are questioned but an explanation is needed that says >> that the CBOR code for the value is shown and not the whole leaf. >> >> [MV] This topic is discussed in section >> https://tools.ietf.org/html/draft-ietf-core-yang-cbor-03#section-3 >> [MV] >> [MV] "Basic schema nodes such as leaf, leaf-list, list, anydata and >> anyxml can be encoded standalone. >> [MV] In this case, only the value of this schema node is encoded in >> CBOR. Identification of this value needs >> [MV] to be provided by some external means when required. >> [MV] A collection such as container, list instance, notification, >> RPC input, RPC output, action input and action >> [MV] output is serialized using a CBOR map in which each child >> schema node is encoded using a key and a value." >> [MV] >> [MV] Can you propose an updated text to clarify this topic? >> From nobody Thu Dec 1 06:39:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7F1297C6; Thu, 1 Dec 2016 06:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=D4ATUocj; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=HZ9X5tKE 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 aDnSvecuRsz2; Thu, 1 Dec 2016 06:39:05 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 488DF129C80; Thu, 1 Dec 2016 06:36:28 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AB0EC206CA; Thu, 1 Dec 2016 09:36:27 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 01 Dec 2016 09:36:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=IHVi0Qb9uu53V4J 4qvcr7vsl3Gc=; b=D4ATUocjjSwfsnJpu7wSk42UtHxT1tEo74R3Eiz85gk1sF7 a3ASyhXGiXyTPapFXB8Kdm/ouZrx773NV0Pq/E6/C1D+j8pdOkjni2ZY+aBFO0a5 x81kMKKvhL4jZf1rzVXHuwxcfMY4/oduUcWt9ASj0CaWR6A4cvKYtviwQq90= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=IHVi0Qb9uu53V4J4qvcr7vsl3Gc=; b=HZ9X5tKEMomi4sE+N+JQ pUZS0/Xqyz6lYNJjvOUk/zSF7Px+GIN6apG7acn9kylm9r1jvzpE3hBL78bmOOBc sA9P/RThfDiW0OKE3ZuhZMmM3dPNkYHvR+yhUIvFVusoavgJoRiawH6oCWzbAwER gVbQ4FF2BE0mJDmGOoUmo3s= X-ME-Sender: X-Sasl-enc: 73TgSY0KCRju4PEbaVZA1YqKfrtljDAro5gaaNuo8KDd 1480602987 Received: from dhcp-10-150-9-159.cisco.com (unknown [173.38.117.93]) by mail.messagingengine.com (Postfix) with ESMTPA id 417DF7E2E3; Thu, 1 Dec 2016 09:36:27 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <0E4DD69D-E4EF-4FFC-B15F-A2368B3EA226@tzi.org> Date: Thu, 1 Dec 2016 09:36:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148053906144.9726.4431534233095634676.idtracker@ietfa.amsl.com> <0E4DD69D-E4EF-4FFC-B15F-A2368B3EA226@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, IESG , core@ietf.org Subject: Re: [core] Alissa Cooper's No Objection on draft-ietf-core-etch-04: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:39:07 -0000 Excellent, thanks. > On Dec 1, 2016, at 2:47 AM, Carsten Bormann wrote: >=20 >=20 >> On 30 Nov 2016, at 21:51, Alissa Cooper wrote: >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-core-etch-04: No Objection >=20 > Thank you for clearing the DISCUSS. >=20 > Your remaining COMMENTs also have been addressed in -04: >=20 >> =3D Section 2 =3D >>=20 >> "(However, while processing a search request, a server can be = expected >> to allocate computing and memory resources or even create additional >> server resources through which the response to the search can be >> retrieved.)" >>=20 >> s/search/fetch/ would be clearer I think >=20 > Done in -04. >=20 >> =3D Section 3 =3D >>=20 >> "If the Request-URI does not point to an existing >> resource, the server MAY create a new resource with that URI, >> depending on the patch document type (whether it can logically = modify >> a null resource) and permissions, etc." >>=20 >> I know this is the same text as in RFC 5789, but it's vague. What = else >> might create the basis for the server's decision besides the document >> type and permissions? >=20 > I don=E2=80=99t think the considerations going into the server=E2=80=99s= decision can be enumerated completely, but -04 changes =E2=80=9Cetc.=E2=80= =9D into: >=20 > [=E2=80=A6], as well as other conditions such as > the degree of control the server gives clients in creating new > entries in its URI space (see also Section 3.4). =20 >=20 >> =3D Section 5 =3D >>=20 >> It seems that FETCH does introduce a new security consideration, in = that >> any observer of FETCH requests can potentially glean information = about >> the specific portions of a resource of interest to the requester. = This >> might factor into decisions about whether to use DTLS to secure a >> particular request so may be worth mentioning. >=20 > This is indeed an important security consideration to be aware of. > -04 now says: >=20 > [=E2=80=A6] The payload of a FETCH > request may reveal more detailed information about the specific > portions of a resource of interest to the requester than a GET > request for the entire resource would; this may mean that > confidentiality protection of the request by DTLS or other means is > needed for FETCH where it wouldn't be needed for GET. >=20 > Thank you again for comments that really helped us improve the = document. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Thu Dec 1 13:05:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE8A1298CC; Thu, 1 Dec 2016 13:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 BUFNrq-7Km54; Thu, 1 Dec 2016 13:05:22 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBBD1298A5; Thu, 1 Dec 2016 13:00:39 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Dec 2016 13:20:08 -0800 From: Jim Schaad To: Date: Thu, 1 Dec 2016 13:00:20 -0800 Message-ID: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJLiTeDKEyfsMgGSoOfR4rDJInqcQ== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 21:05:25 -0000 Section 3 - I like the fact that the security context is being defined, however I question the wisdom of including the sections on how to derive a context from a shared secret at this point. I think it would make more sense to put this into the EDHOC document, and if you do not do that then to at least move this into an appendix. I do not believe that this is/should be the only method to populate a context. I would hope that a method of doing so from a CWT will be defined as that may have the advantage of getting more controlled random numbers. From a security analysis point of view, there is no difference between get the shared secret used here or the actual keys from a third party. There is a difference if EDHOC is used. Section 3.1 - I would think that you might be better off having the Cid be potentially different between the sender and receiver. Currently the closest you get in EDHOC would be to use the nonces, which are too long to be used here. Section 3.1 - Base Key should be Shared-Secret. The term key generally indicates that there are some additional restrictions which would not apply in this case - an example would be key lengths. It is also possible that somebody could incorrectly believe that an asymmetric key could somehow work. Section 3.1 - In principle, the algorithm could be different between the sender and receiver context. I am not sure that I would disallow this in defining your context structure. Section 3.1 - If Base Key and the IDs are not needed once the security context has been setup, remove them from the definition of the context and just make them pre-requests for the context algorithm creation you are defining. Section 3.1 - Do not use the word signed when talking about authenticated data. The operations are not even close to being the same thing from a cryptographic point of view. Section 3.1 - make the last paragraph look more like " The client and server may change roles while maintaining the same security context. When this happens, the former server still makes use of its Sender Context when sending messages and Recipient Context when receiving messages. The same is also true for the former client. In other words, changing the roles does not change the set of keys to be used." Section 3.2 - The term "in a previous phase" is probably a poor choice of words. The term phase implies to me to be part of what we are currently done, but that is not defined. Just kill the clause. Section 3.2 - Why is the replay window an input - this seems to be odd as you would not pre-fill part of the window. I assume this is really just the Replay Window Size. Section 3.2.1 - The method of creating info is insufficiently defined. The current method does not correctly separate the different fields that are used to build it. Section 3.2.3 - 64 bits for the Cid seems to be very long. You are not being consistent with your discussion in Appendix A.4 where the Cid is only 32-bits. 32-bits is much more likely value to be used, in some cases it may be only 16-bits. Section 3.2 - I would like to see a justification of using the Tid as a value that needs to be authenticated as part of the message. I don't see it in this anyplace. It should be part of a security argument. Section 3.2.3 - The last paragraph talks about what EDHOC does. This has two problems, first this should be in that document rather than here and second you are talking about using a 256-bit or 512-bit value which is even longer than you are documenting as being "normal" Section 3.2.3 - You are getting ahead of yourself. The only way that the identifiers would not be unique would be if the sender and recipient collided. I do not know that this would be a problem and therefore talking about it makes no sense. I am assuming that this is supposed to have something to do with the multicast work that I have not looked at. If so it does not belong here but there. Section 4 - I do not understand the processing of a Proxy-Uri. Do you end up with a Proxy-Uri or not? The sentence is not clear. Section 5.2 - Why make code a bstr and not an uint? It is a small integer value Section 52 - Why make alg a bstr and not an (int / tstr)? This more directly maps what the value is. Section 5.2 - why not make the transaction-id be three separate fields? This makes the field separation clearer. Section 5 - You have defined a 'sid' and said that it could be placed in the unprotected field, however you have also said that the unprotected field must be empty. These statements are contradictory. Section 2 - We had a discussion at one point about using the code as the key for the question of payload being present in a document. Specifically, one could do a put with an empty payload. In that case the version of the Object-Security Option should be the one with payload. --- This is not done well in section 2 but is in section 6.2 Section 6.1 - The reject limit on sequence number is defined as algorithm specific rather than being a fixed constant. Section 6.1 - If OSCOAP is a challenge-response, how can one observer? That would be challenge-response-response-response. Is the Tid supposed to be kept until one kills the observation? If so that should be highlighted. From nobody Thu Dec 1 16:43:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5988B129A15; Thu, 1 Dec 2016 16:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 M2TnJBYUQOMM; Thu, 1 Dec 2016 16:43:06 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB84129A16; Thu, 1 Dec 2016 16:43:05 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Dec 2016 17:02:44 -0800 From: Jim Schaad To: Date: Thu, 1 Dec 2016 16:42:55 -0800 Message-ID: <02a301d24c35$07d87690$178963b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJMM6FI9YM3owHuQxeJe70R2ag74A== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: [core] OSCOAP and BLOCK X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 00:43:09 -0000 I did not include this comment in the previous message because I was sure that there must have been something that I was just missing. I have now spent a couple of hours just trying to understand what is document says about BLOCK and I still have absolutely no idea what is going on. The document says that the BLOCK options are to be duplicated in both the wrapper and protected CoAP object. The reasoning for this makes no sense to me. From the point of view of a proxy sitting between the two end-points the message must be treated as a single atomic message and not as part of a sequence of blocks. This is because a proxy that did any type of combining or blocking of one of these messages is going to mess up the fact that the internal encrypted object needs to be treated as an atomic item by the final recipient. Otherwise it will not correctly parse and validate. On the other hand, if a single block between the two end points happens to be broken into a set of blocks by an intermediate proxy, then there would be no problems to the message. This means that the two sets of blockings are treated as completely independent objects. For this reason, I believe that the blocking options should be copied to the internal CoAP object and deleted from the wrapping one. I also have no idea where the MAC value that is being used to chain blocked messages is coming from. From nobody Thu Dec 1 23:50:40 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A918129448 for ; Thu, 1 Dec 2016 23:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se 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 32YXtbQ93HiV for ; Thu, 1 Dec 2016 23:50:36 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FEB129441 for ; Thu, 1 Dec 2016 23:50:35 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id o141so189166879lff.1 for ; Thu, 01 Dec 2016 23:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=n/ZsTM+P6WpPdoMiATywI3SrGqg0rQB7DhGogk35pnw=; b=d2YFUWsxBHFvxrJgyPr93ZpoEa7T0ZC8/TIxB12SxKs+nXhuhkPgiDlZV/2qJ1QxD6 LY8xbvh1Ns3qeyHurBT3nNyfkD74NKmU8yijgGhj/erJs82OcCKj1+uA5zvLXsj3pDGd KMu0MHCySOMB+8IAvJ175TzSUjJTsRWD0R48TWiLpcrpHU8wJb9BCW4NfmxNYwNJuDxv ehlmQ4S5QKuDzT3eiyABzJW1mKp7NRCwB4hRiaFDquGkbWLG+i4ZXzdqjh1LEX7PNwlK nt+bjWBkiU8r4sMIf2qQQYno/qco3Z2lrLe4s3zmHiaW4M+mJKI4XVUEZEU8dpv5XQ1N UT6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=n/ZsTM+P6WpPdoMiATywI3SrGqg0rQB7DhGogk35pnw=; b=iWcVx6GVBqi8qgWLWfg6cORjuuArJzAwGN4IYnYqIjl5zSsCo2/swr6YI8/rnEpcnb UzyWJNNZUEgLsdb5ajspzFQzC461AjJcgJ22mPEs4jPurHCT0CNJ47kQIgAz6PXnNlUu 39v733TcFzdvbUlBlZNbYxtC1AfyA6oNiZgK2SEtiXEf4S0mvvI9cT/tPaqJk5whYcT4 9BKIHb/1EwomDGY+dcwTUBV+6UtcowEDLXkXSNWC/P1njA4xhoLsOgLpVekjzO0Ggfb4 YDctYANQhcP8s8LiyFJ28W6qaaZ4XGCQ3FdWvnnj9SGVhe2vLWHsyaV+fyukgLMi5oqm KGkA== X-Gm-Message-State: AKaTC00GCh2CuO0Rl1U80+PPtHwAVzOmgf0cddbFujMvS7szBYky0PRDj8JHuw7OsCmcTu45 X-Received: by 10.46.78.1 with SMTP id c1mr19890825ljb.39.1480665033733; Thu, 01 Dec 2016 23:50:33 -0800 (PST) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id c2sm600884ljb.8.2016.12.01.23.50.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 23:50:33 -0800 (PST) To: Jim Schaad , draft-ietf-core-object-security@ietf.org References: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> From: Ludwig Seitz Message-ID: <5ea88fb4-92c8-752b-9940-64c9446be722@sics.se> Date: Fri, 2 Dec 2016 08:50:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090503050801010804090700" Archived-At: Cc: core@ietf.org Subject: Re: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 07:50:39 -0000 This is a cryptographically signed message in MIME format. --------------ms090503050801010804090700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hello Jim, thank you for you detailed review. Some answers and follow-up questions=20 inline, I'm sure G=F6ran and Francesca will address the rest. /Ludwig On 2016-12-01 22:00, Jim Schaad wrote: > Section 3.1 - I would think that you might be better off having the Cid= be > potentially different between the sender and receiver. Currently the > closest you get in EDHOC would be to use the nonces, which are too long= to > be used here. > Not sure what you mean here, if the Cid is different between sender and=20 receiver, how does the receiver retrieve the right OSCOAP context? > Section 3.1 - If Base Key and the IDs are not needed once the security > context has been setup, remove them from the definition of the context = and > just make them pre-requests for the context algorithm creation you are > defining. > I don't quite agree, but I'm willing to be convinced otherwise if=20 someone has a better idea. Right now my plan is to use Sender ID + Cid as subject identifier for=20 CWTs that use OSCOAP for proof-of-possession. Wouldn't that be a good=20 case for keeping this id? > Section 3.2 - Why is the replay window an input - this seems to be odd = as > you would not pre-fill part of the window. I assume this is really jus= t the > Replay Window Size. > Yes > Section 4 - I do not understand the processing of a Proxy-Uri. Do you = end > up with a Proxy-Uri or not? The sentence is not clear. > The description is not clear here indeed, I think the text got garbled=20 in some update The idea was this: If you have Proxy-URI=3Dexample.com:5683/sensors/temp.xml?time=3D90 (and = Proxy-Scheme=3Dcoap, which is left unchanged) this is split into: Proxy-Scheme=3Dcoap (AAD) Proxy-Uri=3Dexample.com:5683 (AAD) Uri-Path=3Dsensors (Encrypted) Uri-Path=3Dtemp.xml (Encrypted) Uri-Query=3Dtime=3D90 (Encrypted) /Ludwig > Section 6.1 - If OSCOAP is a challenge-response, how can one observer? = That > would be challenge-response-response-response. That was indeed the intention, but writing it that way seemed a bit=20 silly. We should write it out instead. --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelev=E4gen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order=20 to create a unified institute sector and become a stronger innovation=20 partner for businesses and society. At the end of the year we will=20 change our name to RISE. Read more at www.ri.se/en/about-rise --------------ms090503050801010804090700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEyMDIwNzUwMzJaMC8GCSqGSIb3DQEJBDEiBCA6T1+GaR3X UfCK60osrM+ByZo8XiN/rKbbovRLBrOmuDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQB35OaYkGi85P/FInpXoWky qKluKLq/HhG0Am2+RDTs/Dg4g9TZj8Cqw127JjIdZzqsLJ1UCm43yFrrjEwh9G73BZzvMTqc C0H1NAsayklMiSysVR4aY3MC5g2FpMaFiHCE/zEFym1PRGJxE4DsZN1xyCvN1Wwy/BUXtFRS JKPXhQfakQPznCcpCwd1oum2Q/5QtJzpeEODiKkQsL4vxhdPjW3HRuD9tl8/SPFud3GlKcW6 3Zk421p922U7SqCRf2IymHvknpIyQvCvNp2YbTg8BVoVgrgIB9YZcmcdWDHv1EDhhRPSs0MM nzF6c76g3X8+tK6TT87qmCDyjy24gU5GAAAAAAAA --------------ms090503050801010804090700-- From nobody Fri Dec 2 00:00:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A443812947A; Fri, 2 Dec 2016 00:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 HiVvZjRQ-AKH; Fri, 2 Dec 2016 00:00:37 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B933129443; Fri, 2 Dec 2016 00:00:37 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 00:20:16 -0800 From: Jim Schaad To: 'Ludwig Seitz' , References: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> <5ea88fb4-92c8-752b-9940-64c9446be722@sics.se> In-Reply-To: <5ea88fb4-92c8-752b-9940-64c9446be722@sics.se> Date: Fri, 2 Dec 2016 00:00:29 -0800 Message-ID: <030001d24c72$279562d0$76c02870$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJQYzPohZqCNQ6QgBJW9Bzqza6ZYAGbTM2dn+tB6eA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: Re: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 08:00:40 -0000 > -----Original Message----- > From: Ludwig Seitz [mailto:ludwig@sics.se] > Sent: Thursday, December 01, 2016 11:51 PM > To: Jim Schaad ; draft-ietf-core-object- > security@ietf.org > Cc: core@ietf.org > Subject: Re: Comments on draft-ietf-core-object-security-00 >=20 > Hello Jim, >=20 > thank you for you detailed review. Some answers and follow-up = questions > inline, I'm sure G=F6ran and Francesca will address the rest. >=20 > /Ludwig >=20 > On 2016-12-01 22:00, Jim Schaad wrote: >=20 > > Section 3.1 - I would think that you might be better off having the = Cid be > > potentially different between the sender and receiver. Currently = the > > closest you get in EDHOC would be to use the nonces, which are too = long to > > be used here. > > > Not sure what you mean here, if the Cid is different between sender = and > receiver, how does the receiver retrieve the right OSCOAP context? Foreach (Context ctx : AllContexts) { If (ctx.receiver.Cid =3D=3D CidInmessage) TestDecrypt(); } The difference betwee "ctx.Cid" and "ctx.receiver.cid" is not very big. >=20 >=20 > > Section 3.1 - If Base Key and the IDs are not needed once the = security > > context has been setup, remove them from the definition of the = context and > > just make them pre-requests for the context algorithm creation you = are > > defining. > > >=20 > I don't quite agree, but I'm willing to be convinced otherwise if > someone has a better idea. >=20 > Right now my plan is to use Sender ID + Cid as subject identifier for > CWTs that use OSCOAP for proof-of-possession. Wouldn't that be a good > case for keeping this id? It might be, but I am not sure what you think you are doing here and if = you are planning to put this into this document or into a later document. I = am less worried about the IDs than the base key under the rubric of kill a security item as soon as you don=92t need it. It looks like at least = one of the IDs is used are part of the Tid so keeping it might make sense if = there is a valid reason for thinking that is a necessary item to authenticate. >=20 > > Section 3.2 - Why is the replay window an input - this seems to be = odd as > > you would not pre-fill part of the window. I assume this is really = just the > > Replay Window Size. > > > Yes >=20 >=20 > > Section 4 - I do not understand the processing of a Proxy-Uri. Do = you end > > up with a Proxy-Uri or not? The sentence is not clear. > > > The description is not clear here indeed, I think the text got garbled > in some update >=20 > The idea was this: >=20 > If you have Proxy-URI=3Dexample.com:5683/sensors/temp.xml?time=3D90 = (and > Proxy-Scheme=3Dcoap, which is left unchanged) this is split into: >=20 > Proxy-Scheme=3Dcoap (AAD) > Proxy-Uri=3Dexample.com:5683 (AAD) > Uri-Path=3Dsensors (Encrypted) > Uri-Path=3Dtemp.xml (Encrypted) > Uri-Query=3Dtime=3D90 (Encrypted) I need to re-read how proxies work, but that makes sense to me. By the way - I did update the JAVA version of COSE, I don't know if you noticed. Jim >=20 > /Ludwig >=20 >=20 >=20 >=20 >=20 > > Section 6.1 - If OSCOAP is a challenge-response, how can one = observer? That > > would be challenge-response-response-response. >=20 > That was indeed the intention, but writing it that way seemed a bit > silly. We should write it out instead. >=20 >=20 > -- > Ludwig Seitz, PhD SICS Swedish ICT AB > Ideon Science Park, Building Beta 2 > Scheelev=E4gen 17, SE-223 70 Lund > Phone +46(0)70-349 92 51 >=20 > The RISE institutes SP, Swedish ICT and Innventia are merging in order > to create a unified institute sector and become a stronger innovation > partner for businesses and society. At the end of the year we will > change our name to RISE. Read more at www.ri.se/en/about-rise From nobody Fri Dec 2 00:31:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58984129484; Fri, 2 Dec 2016 00:31:39 -0800 (PST) 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 KXX5JJam-78L; Fri, 2 Dec 2016 00:31:36 -0800 (PST) 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 F1798126BF7; Fri, 2 Dec 2016 00:31:35 -0800 (PST) X-AuditID: c1b4fb3a-d644398000007918-b0-58413165e0b7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 56.E9.31000.56131485; Fri, 2 Dec 2016 09:31:34 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Fri, 2 Dec 2016 09:31:14 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" Thread-Topic: Comments on draft-ietf-core-object-security-06 Thread-Index: AdJKtW70xWwK1XHBRtGhNREf/zkBMgBwQCuA Date: Fri, 2 Dec 2016 08:31:14 +0000 Message-ID: References: <083101d24ad0$3b071aa0$b1154fe0$@augustcellars.com> In-Reply-To: <083101d24ad0$3b071aa0$b1154fe0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <3988E04D36A24D44A5FD075D5299C489@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7rm6aoWOEwZJDPBb73q5ntpj27wyL xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsErox9U/4zF7QYVyzZ3sLawHjHsIuR k0NCwETi+K/FTCC2kMA6RonDryS6GLmA7MWMEtd7z4Al2ARcJB40PGICSYgINDFKPJ7bxwyS YBZQljg++zAriC0sYC3ROe0fWIOIgI3E0i/HWSBsI4lD17eC1bAIqEg8O/GREcTmFbCQ+Hfv PwvEZnuJTTOvg9VwCjhIvN32EWwOo4CYxPdTa5ggdolL3HoynwniagGJJXvOM0PYohIvH/8D 6xUV0JOYPaWBHSKuJLHo9megeg6gXk2J9bv0IcZYS1xd8ogFwlaUmNL9kB3iHEGJkzOfsExg FJ+FZNsshO5ZSLpnIemehaR7ASPrKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAuDu45bfV DsaDzx0PMQpwMCrx8H6wcogQYk0sK67MPcQowcGsJMJrpusYIcSbklhZlVqUH19UmpNafIhR moNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVAOjzZqHPTy1XTE6xt3Jd6+YNbZ+cQ4vXLDe dn9BT1+OXMSzeuYLZkoiv85UVxfdkD+hZR0etSTgeeXadW0iPzNVE4+tFw45denUb72Xx4w4 GDiT3tZVzr47b9Gnz8lGFis0vd9PfnLr9pvs2UwHWl7tOH1F+57FLvdfe5WLeDhN7zarvth7 d9U/JZbijERDLeai4kQAsC6Sg7cCAAA= Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Comments on draft-ietf-core-object-security-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 08:31:39 -0000 SGkgSmltLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFRoZSBzdWJqZWN0IG9mIHRoaXMg dGhyZWFkIHNob3VsZCBvZiBjb3Vyc2UgYmUNCiJDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvcmUt b2JqZWN0LXNlY3VyaXR5LTAw4oCdLg0KDQpBcHBlbmRpeCBDLCBPU0NPTiwgaXMgYWRkcmVzc2lu ZyBvdGhlciB1c2UgY2FzZXMgdGhhbiBPU0NPQVAsIG1vcmUgb2YgdGhpcw0KYmVsb3cuIEl0IGhh cyBub3QgYmVlbiBwcm9ncmVzc2VkIGxhdGVseSBzaW5jZSB3ZSB3YW50ZWQgdG8gZm9jdXMgb24g dGhlDQpPU0NPQVAgdXNlIGNhc2VzIHdoaWNoIHNlZW0gbW9zdCByZWxldmFudCBhdCB0aGlzIHN0 YWdlLiBBbHNvIHdlIHdlcmUNCndhaXRpbmcgZm9yIEtsYXVzIHRvIHByZXNlbnQgaGlzIHNvbHV0 aW9uLCB3aGljaCBtYXkgb3ZlcmxhcCB3aXRoIE9TQ09OLiBJDQp3aWxsIG1ha2UgR2l0aHViIGlz c3VlcyBvdXQgb2YgdGhlIGNvbW1lbnRzIGlubGluZSwgYnV0IHdlIG1heSBpbmNvcnBvcmF0ZQ0K dGhvc2UgaW4gdGhlIGRyYWZ0IGF0IGEgbGF0ZXIgc3RhZ2Ugc2luY2Ugd2UgaGF2ZSBhIHRpZ2h0 IHRpbWUgc2NoZWR1bGUNCmZvciBPU0NPQVAuDQoNCk9uIDIwMTYtMTEtMzAgMDc6MDgsICJKaW0g U2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQoNCj4NCj5BcHBlbmRpeCBD IC0gSSBhbSBoYXZpbmcgYSBoYXJkIHRpbWUgd2l0aCB0aGUgZmlyc3QgcGFyYWdyYXBoIGhlcmUu ICBJIGRvDQo+bm90IGJlbGlldmUgdGhhdCB5b3UgaGF2ZSBjb3JyZWN0bHkgY2hhcmFjdGVyaXpl ZCB0aGUgcHJvYmxlbS4gIFRoZSByZWFzb24NCj50aGF0IHlvdSBjYW5ub3QgdXNlIE9TQ09BUCBm b3IgdGhpcyBoYXMgbW9yZSB0byBkbyB3aXRoIGhvdyB5b3UgZGVjaWRlZA0KPndoaWNoIHJlY29y ZHMgaW4gdGhlIGhlYWRlciB0byBhdXRoZW50aWNhdGUgcmF0aGVyIHRoYW4gdGhlIGZhY3QgdGhh dCB0aGlzDQo+aXMgZ29pbmcgdG8gYmUgZGlzdHJpYnV0ZWQgdG8gbXVsdGlwbGUgcmVjaXBpZW50 cy4NCg0KVGhlIGludGVuZGVkIGxvZ2ljIGlzIHRoZSBmb2xsb3dpbmc6DQoNClRoZSBzZWN1cml0 eSByZXF1aXJlbWVudHMgZHJhZnQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YXJ0a2UtY29yZS1lMmUtc2VjdXJpdHktcmVxcyBjdXJyZW50bHkNCmRlc2NyaWJlcyB0aHJlZSB1 c2UgY2FzZXMg4oCccHJveHkgZm9yd2FyZGluZ+KAnSwg4oCccHJveHkgY2FjaGluZ+KAnSBhbmQN CuKAnHB1Ymxpc2gtc3Vic2NyaWJl4oCdLiBUaGUgc29sdXRpb25zIHRvIHRoZXNlIHJlcXVpcmVt ZW50cyBwcm90ZWN0IGFzIG11Y2gNCmFzIGlzIHBvc3NpYmxlLCB3aGlsZSBzdGlsbCBhbGxvd2lu ZyB0aGUgZnVuY3Rpb25hbGl0eSBvZiB0aGUgdXNlIGNhc2UuDQpPU0NPQVAgYWRkcmVzc2VzIHRo ZSAicHJveHkgZm9yd2FyZGluZ+KAnSB1c2UgY2FzZSwgd2hpY2ggaXMgYSBiYXNpYyBDb0FQDQpy ZXF1ZXN0LXJlc3BvbnNlIHdpdGggb3B0aW9uYWwgZm9yd2FyZCBwcm94eSBmdW5jdGlvbmFsaXR5 LiBUaGlzIGlzIGEgdXNlDQpjYXNlIHdlIGhhdmUgYmVlbiByZXF1ZXN0ZWQgdG8gc3VwcG9ydCwg YW5kIGl0IGlzIGFuIGludGVyZXN0aW5nIGNhc2UgYWxzbw0KYmVjYXVzZSBlc3NlbnRpYWxseSBh bGwgb3B0aW9ucyBhbmQgaGVhZGVycyB0aGF0IGFyZSBwYXNzZWQgZW5kLXRvLWVuZCBpbg0KYSBD b0FQIHJlcXVlc3QgYW5kIHJlc3BvbnNlIGNhbiBiZSBwcm90ZWN0ZWQsIHJlc3BvbnNlIGNhbiBi ZSBib3VuZCB0byBhDQpyZXF1ZXN0LCBhbmQgc29tZSBvdGhlciBzZWN1cml0eSBmZWF0dXJlcyBj YW4gYmUgc3VwcG9ydGVkLg0KDQpPU0NPTiBhZGRyZXNzZXMgb3RoZXIgdXNlIGNhc2VzIHdpdGgg YSBjb21tb24gc29sdXRpb24sIGluY2x1ZGluZyB0aGUgdHdvDQpyZW1haW5pbmcgdXNlIGNhc2Vz IG1lbnRpb25lZCBhYm92ZS4gSW4gdGhlc2UgY2FzZXMgbGVzcyBvZiB0aGUgcmVjb3Jkcw0KY2Fu IGJlIHByb3RlY3RlZCwgZS5nLiBiZWNhdXNlIGEgc2luZ2xlIHJlc3BvbnNlIHNob3VsZCBiZSBt ZWFuaW5nZnVsIHRvDQptdWx0aXBsZSByZXF1ZXN0cy4gVGhpcyBzb2x1dGlvbiB0aHVzIHRhcmdl dHMgYSBmb3JtYXQgd2hlcmUgbXVsdGlwbGUgdXNlDQpjYXNlcyBjYW4gYmUgc3VwcG9ydGVkIHJh dGhlciB0aGFuIG9wdGltaXNpbmcgc2VjdXJpdHkgZm9yIGEgcGFydGljdWxhcg0KdXNlIGNhc2Uu DQoNCkkgd2lsbCBtYWtlIGFuIGlzc3VlIHRvIGNsYXJpZnkgdGhpcy4NCg0KPg0KPkFwcGVuZGl4 IEMgLSBUYWxraW5nIGFib3V0IHRoZSAidW5wcm90ZWN0ZWQiIGFuZCB0aGUgInByb3RlY3RlZCIg Q29BUA0KPm1lc3NhZ2UgaXMgdmVyeSBjb25mdXNpbmcgZXNwZWNpYWxseSBzaW5jZSBDT1NFIGhh cyBwcm90ZWN0ZWQgYW5kDQo+dW5wcm90ZWN0ZWQgb2JqZWN0cyBhcyB3ZWxsLiAgSXQgd291bGQg YmUgYmV0dGVyIHRvIHVzZSBhIGRpZmZlcmVudA0KPnRlcm1pbm9sb2d5IHN1Y2ggYXMgInRoZSBv cmlnaW5hbCBtZXNzYWdlIiBhbmQgInRoZSByZXN1bHRpbmcgbWVzc2FnZSIuDQoNClRoaXMgdGVy bWlub2xvZ3kgaXMgZGVmaW5lZCBpbiB0aGUgYm9keSBvZiB0aGUgZHJhZnQuIChGV0lXIHRoZQ0K dGVybWlub2xvZ3kgcHJvYmFibHkgcHJlZGF0ZXMgQ09TRS4pIElmIHdlIGFsd2F5cyBxdWFsaWZ5 IHdpdGgNCnVucHJvdGVjdGVkL3VucHJvdGVjdGVkIENvQVAsIHByb3RlY3RlZC91bnByb3RlY3Rl ZCBDT1NFIGhlYWRlciwgSSBzdXBwb3NlDQp0aGVyZSB3b3VsZCBsZXNzIG9mIGEgcmlzayBmb3Ig bWlzdW5kZXJzdGFuZGluZz8NCg0KPg0KPkFwcGVuZGl4IEMgLSBJIGRvIG5vdCB1bmRlcnN0YW5k IHdoYXQgdGhpcyBzZW50ZW5jZSBtZWFucy4gIiBPU0NPTiBzaGFsbA0KPm5vdA0KPmJlIHVzZWQg aW4gY2FzZXMgd2hpY2ggcmVxdWlyZSBhIHNlY3VyZSBiaW5kaW5nIGJldHdlZW4gcmVxdWVzdCBh bmQNCj5yZXNwb25zZS4iICBJcyBpdCBpbnRlbmRlZCB0byBzYXkgdGhhdCB0aGUgdXNlIG9mIGEg dHJhbnNhY3Rpb24gaWRlbnRpZmllcg0KPmluIHRoZSBDT1NFIHdyYXBwZXJzIGZvciB0aGUgcmVx dWVzdCBhbmQgcmVzcG9uc2UgaXMgbm90IHBlcm1pdHRlZD8gIFRoZXJlDQo+YXJlIGEgbG90IG9m IHdheXMgdG8gZG8gdGhpcyB0aGF0IGRvIG5vdCByZWx5IG9uIENvQVAuDQoNCkFzIG1lbnRpb25l ZCwgdGhpcyBmb3JtYXQgaXMgYWRkcmVzc2luZyB1c2UgY2FzZXMgd2hpY2ggZG9lcyBub3QgYmlu ZA0KcmVzcG9uc2UgdG8gcmVxdWVzdC4gSXQgaXMgcG9zc2libGUgdG8gZGVmaW5lIGEgd3JhcHBp bmcgb2YgYSBtZXNzYWdlDQpleGNoYW5nZSBpbiBDT1NFIHdoaWNoIGhhcyBkaWZmZXJlbnQgZmVh dHVyZXMsIGJ1dCB0aGF0IHdhcyBub3QgdGhlDQppbnRlbnRpb24gaGVyZS4NCg0KDQo+DQo+QXBw ZW5kaXggQyAtIEl0IGlzIG5vdCBjbGVhciBpZiB0aGUgQ29udGVudC1Gb3JtYXQgc2hvdWxkIGJl IHNldCBpZiB0aGVyZQ0KPndhcyBubyBDb250ZW50LUZvcm1hdCBpbiB0aGUgb3JpZ2luYWwgbWVz c2FnZS4NCg0KSXQgc2hvdWxkLCB0byBiZSBjbGFyaWZpZWQuDQoNCj4NCj5BcHBlbmRpeCBDLjEg LSBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBzZWN0aW9uIGlzIHRyeWluZyB0bw0KPmFj Y29tcGxpc2guICBJdCBhcHBlYXJzIHRvIGJlIGRvaW5nIHRocmVlIGRpZmZlcmVudCB0aGluZ3Ms IHNvbWUgb2Ygd2hpY2gNCj5zaG91bGQgYmUgaW4gQXBwZW5kaXggQywgc29tZSBvZiB3aGljaCBz aG91bGQgYmUgc3RhbmRhbG9uZSBhbmQgc29tZSBvZg0KPndoaWNoIGxvb2tzIGxpa2UgaXQgc2hv dWxkIGJlDQoNCkl0IGlzIGFuIGludHJvZHVjdGlvbiB0byBzZWN0aW9ucyBDLjItQy41LiBXZSBz aG91bGQgY2xhcmlmeSB0aGF0Lg0KDQo+DQo+QXBwZW5kaXggQy41IC0gVGhlcmUgc2hvdWxkIGJl IGEgZGlzY3Vzc2lvbiByZWxhdGVkIHRoaXMgdGhpcyBhYm91dCB0aGUNCj5kaWZmZXJlbnQgc2Vj dXJpdHkgcHJvcGVydGllcyB0aGF0IGFyZSB0byBiZSBmb3VuZCBmb3IgRW5jcnlwdCtTaWduKE0p IHZzDQo+U2lnbihFbmNyeXB0KE0pKS4NCg0KVGhlcmUgYXJlIHBsYW5zIHRvIHdyaXRlIG1vcmUg YWJvdXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgU0VBUywNCnByb2JhYmx5IGluIGEgZGlm ZmVyZW50IGRvY3VtZW50Lg0KDQo+DQo+QXBwZW5kaXggQiAtIFRoZXNlIGFyZSByZWFsbHkgZXhh bXBsZSBtZXNzYWdlIGZsb3dzIHJhdGhlciB0aGFuIGV4YW1wbGVzDQo+b2YNCj5PU0NPUCBtZXNz YWdlcy4gIFRoaXMgc2hvdWxkIGJlIG1hZGUgY2xlYXJlciBpbiB0aGUgc2VjdGlvbiB0aXRsZQ0K DQpPSywgSeKAmWxsIG1ha2UgdGhhdCB1cGRhdGUgaW4gLTAxLg0KDQo+DQo+QXBwZW5kaXggQi4x IC0gSG93IGRvZXMgb25lIHNlY3VyZWx5IGJpbmQgdGhlIHJlcXVlc3QgYW5kIHRoZSByZXNwb25z ZT8gIEkNCj5hbSBub3Qgc2VlaW5nIGFueXRoaW5nIGZyb20gdGhpcyBleGFtcGxlIHRoYXQgd2ls bCBkbyBzby4NCg0KTm8sIGl0IGlzIG5vdCB2aXNpYmxlIGZyb20gdGhlIG1lc3NhZ2UgZm9ybWF0 LiBTZWUgc2VjdGlvbiA2LjEgInRoZQ0KcmVzcG9uc2UgaXMgdmVyaWZpZWQgdG8gbWF0Y2ggYSBw cmlvciByZXF1ZXN0LCBieSBpbmNsdWRpbmcgdGhlIHVuaXF1ZQ0KdHJhbnNhY3Rpb24gaWRlbnRp ZmllciBvZiB0aGUgcmVxdWVzdCBpbiB0aGUgQWRkaXRpb25hbCBBdXRoZW50aWNhdGVkIERhdGEN Cm9mIHRoZSByZXNwb25zZSBtZXNzYWdlLiINCg0KR8O2cmFuDQoNCg0K From nobody Fri Dec 2 02:43:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350AE129622; Fri, 2 Dec 2016 02:43:00 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 IN6QFqB277yv; Fri, 2 Dec 2016 02:42:57 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A7A1295C1; Fri, 2 Dec 2016 02:42:55 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-b3-5841502ea811 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id CB.1E.32482.E2051485; Fri, 2 Dec 2016 11:42:54 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 2 Dec 2016 11:42:23 +0100 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=rP8ZLd1SQTTHQKX7/YhA8J8GRiwGxm5OLbts+iWeY64=; b=MsFQ0STjYHPQrnmXeDUL2OC3jOzGWfYYFAOonjkRK08YeSAWikIttRJbCuWVXuPLuQ04viI9sue9InrqGkG0nNXdY0LU9zA4rdyScXIjqvuVAO/EQD2PKSKEJ8d8vDtkMN9kK4o/Qtum7yqrGOJHxULHDerooowfglb9pZzOv7I= Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2537.eurprd07.prod.outlook.com (10.168.129.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Fri, 2 Dec 2016 10:42:21 +0000 Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([10.168.129.17]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([10.168.129.17]) with mapi id 15.01.0761.009; Fri, 2 Dec 2016 10:42:21 +0000 From: Francesca Palombini To: Jim Schaad , 'Ludwig Seitz' , "draft-ietf-core-object-security@ietf.org" Thread-Topic: [core] Comments on draft-ietf-core-object-security-00 Thread-Index: AQHSTHDY0VDSjK7jDUa90VQDmgP1zaD0S2mAgAAtAJA= Date: Fri, 2 Dec 2016 10:42:21 +0000 Message-ID: References: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> <5ea88fb4-92c8-752b-9940-64c9446be722@sics.se> <030001d24c72$279562d0$76c02870$@augustcellars.com> In-Reply-To: <030001d24c72$279562d0$76c02870$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.36.157.200] x-ms-office365-filtering-correlation-id: 10aefd47-2978-4b21-756e-08d41a9fe559 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2537; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2537; 7:UZDeW/ekQuS3ctwIww8BVw07R6SwobuIW1if+QHzz5iBV+UYgiq9v2p3mgxRp3pVSfwIrf+gSSfMGBvyasPtXs9ESUPXMSJ+PhZfynRycTLyNYOJT8NpcVpiPaUJPDJWaBS07pvPOw8twXKQzxIrR2YRcbXrjIB49ncj402rhAK4yHeKn0Pcfkszr5t5o73ZZz6sxq/FjG1mFrw+yqaQyPpgSFvMukVo2C2DHsTusgZI2Ybnn5IJ6wXM5GO1lS6orUiB4hEHoHL/OFY0/o2Y5X994tPRFE280do41YmXt4HXQzAILjPrhSdmJiPxGjreyDQ9EaU4ALkkiX3EaBcDxFaAJqL1wu83Asdze/aPsFC1Xj/21k8isnx/2FZJ9pjhi04JR55gJVP2f6kd+YkcKdxlMBkbWaEhvCwzV/G2F0b1YdEmHLv4mThFc8vmOxqmzTzazBWxxvAvBey6VRKqlg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6042181)(6072148); SRVR:HE1PR0701MB2537; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2537; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(13464003)(189002)(81156014)(81166006)(54356999)(8936002)(6506004)(551934003)(561944003)(101416001)(9686002)(66066001)(33656002)(305945005)(230783001)(86362001)(68736007)(76176999)(7696004)(2501003)(5660300001)(50986999)(3846002)(2950100002)(102836003)(6116002)(7736002)(74316002)(8676002)(2906002)(4326007)(92566002)(15650500001)(3280700002)(3660700001)(229853002)(189998001)(97736004)(5001770100001)(38730400001)(122556002)(106116001)(105586002)(106356001)(7846002)(77096006)(76576001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2537; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2016 10:42:21.4288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2537 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUyM2K7qK5egGOEweHnChb73q5ntpj27wyL xerp39ksXrXeYXZg8dg4Zzqbx5IlP5k8eo/9ZgtgjuKySUnNySxLLdK3S+DKODNrF3PBKdeK iXMvsjQw7jHrYuTgkBAwkfjXntXFyMUhJLCOUWLz1DusEM5xRokX+7cCOZwcLAK9zBIvNwdA JGYwSTw4fJsRwjnJKLHmzTZmkCo2ARuJCw/fg7WLCCxmlLi66xlYgllAWeL47MNgo4QFnCQm NTWC2SICzhIH101mgrCtJA6+/ckMsU5F4sycD4wg9/EKJEis2cwBsWwZo8SfAysYQWo4BRwk ej73sYHYjAKyEl8aV0PtEpe49WQ+2EwJAQGJJXvOM0PYohIvH/9jhahPlrhyu48dIq4ksaNp NlSNr8Sy06cZIWx/iY1N91hAFksI9LFIvLixDaooX2L+z99Qdp7EyYNTWSGKpjNJtP49C9Ut IzF1fgMzROI0q8S7TXvBThISSJVYvraVERIUUhJ3r3QyTmDUmoXkcghbR2LB7k9sELa2xLKF r5lBbF4BQYmTM5+wLGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRmFgObvmtuoPx8hvH Q4wCHIxKPLwfrBwihFgTy4orcw8xSnAwK4nwqvk5RgjxpiRWVqUW5ccXleakFh9ilOZgURLn NVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAWFX9Y4mu0/z9q5qnzU5//cFfuqDUe1O05S7hYr3b q7ZLbjP54iZbb2oe8mdnpH7/g5Ddji8jKyanm+X0+R6+uE9R3Ml+S2hUV+zvDevV44/OuiB+ x22G0z+tykWbbMs0E6aH7d/ccCO87YX2I24J7tfMM68Lecy+vOtm/DNv96zzmnu6igI3KrEU ZyQaajEXFScCAOK3NyIoAwAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 10:43:00 -0000 Jim, Thank you so much for a detailed review! Before answering inline, please note that some of these comments were alrea= dy taken care of in the latest version (commit 30475e3 in the github https:= //github.com/core-wg/oscoap ), updated yesterday (1st of December). =20 Francesca > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: den 1 december 2016 22:00 > To: draft-ietf-core-object-security@ietf.org > Cc: core@ietf.org > Subject: [core] Comments on draft-ietf-core-object-security-00 >=20 > Section 3 - I like the fact that the security context is being defined, h= owever I > question the wisdom of including the sections on how to derive a context > from a shared secret at this point. I think it would make more sense to = put > this into the EDHOC document, and if you do not do that then to at least > move this into an appendix. I do not believe that this is/should be the = only > method to populate a context. I would hope that a method of doing so fro= m > a CWT will be defined as that may have the advantage of getting more > controlled random numbers. From a security analysis point of view, there= is > no difference between get the shared secret used here or the actual keys > from a third party. There is a difference if EDHOC is used. >=20 > Section 3.1 - I would think that you might be better off having the Cid b= e > potentially different between the sender and receiver. Currently the clo= sest > you get in EDHOC would be to use the nonces, which are too long to be use= d > here. >=20 I am still not 100% sure what you mean here. Do you mean discard the use of= Cid and only use Sender ID and Recipient ID to retrieve the right contexts= ? This creates problems with the current text since the Cid should be globa= lly unique and the Sender/Recipient ID only locally unique. What would be t= he advantage of using Recipient ID instead of Cid? > Section 3.1 - Base Key should be Shared-Secret. The term key generally > indicates that there are some additional restrictions which would not app= ly in > this case - an example would be key lengths. It is also possible that > somebody could incorrectly believe that an asymmetric key could somehow > work. >=20 Good point. What about using Master Secret? (Inspired by TLS terminology, i= t avoids overlapping with EDHOC terminology) > Section 3.1 - In principle, the algorithm could be different between the > sender and receiver context. I am not sure that I would disallow this in > defining your context structure. >=20 Point taken. If there is use case/interest for this, we may consider adding= this, but for simplicity reasons we think that request and response should= be protected with the same algorithm. > Section 3.1 - If Base Key and the IDs are not needed once the security > context has been setup, remove them from the definition of the context an= d > just make them pre-requests for the context algorithm creation you are > defining. >=20 About the IDs, the Sender/Recipient ID need to be kept since it is used in = the AAD. We can remove the Base Key. > Section 3.1 - Do not use the word signed when talking about authenticated > data. The operations are not even close to being the same thing from a > cryptographic point of view. >=20 Yes, this was removed in latest revision (commit 30475e3) > Section 3.1 - make the last paragraph look more like " The client and ser= ver > may change roles while maintaining the same security context. When this > happens, the former server still makes use of its Sender Context when > sending messages and Recipient Context when receiving messages. > The same is also true for the former client. In other words, changing th= e > roles does not change the set of keys to be used." >=20 Ok, we will integrate your proposal into the updated version (at line 237 o= f the md document). > Section 3.2 - The term "in a previous phase" is probably a poor choice of > words. The term phase implies to me to be part of what we are currently > done, but that is not defined. Just kill the clause. >=20 Agreed (true for the 4 occurrences). > Section 3.2 - Why is the replay window an input - this seems to be odd as= you > would not pre-fill part of the window. I assume this is really just the = Replay > Window Size. >=20 Ok (changed in updated version) > Section 3.2.1 - The method of creating info is insufficiently defined. T= he > current method does not correctly separate the different fields that are = used > to build it. >=20 Ok (also changed) > Section 3.2.3 - 64 bits for the Cid seems to be very long. You are not b= eing > consistent with your discussion in Appendix A.4 where the Cid is only 32-= bits. > 32-bits is much more likely value to be used, in some cases it may be onl= y 16- > bits. >=20 64 is just a recommendation. We did add text about shorter Cid (line 289 of= the md doc). > Section 3.2 - I would like to see a justification of using the Tid as a v= alue that > needs to be authenticated as part of the message. I don't see it in this > anyplace. It should be part of a security argument. >=20 We did add some text in line 209 "The Tid is part of the Additional Authent= icated Data (AAD, see {{sec-obj-cose}}) of the protected CoAP response mess= age, which is how responses are bound to requests.", is this not enough? > Section 3.2.3 - The last paragraph talks about what EDHOC does. This has > two problems, first this should be in that document rather than here and > second you are talking about using a 256-bit or 512-bit value which is ev= en > longer than you are documenting as being "normal" >=20 Right, this was removed. > Section 3.2.3 - You are getting ahead of yourself. The only way that the > identifiers would not be unique would be if the sender and recipient coll= ided. > I do not know that this would be a problem and therefore talking about it > makes no sense. I am assuming that this is supposed to have something to > do with the multicast work that I have not looked at. If so it does not = belong > here but there. >=20 The new updated version say "SHALL be unique", as any collisions may lead t= o loss of both confidentiality and integrity. > Section 4 - I do not understand the processing of a Proxy-Uri. Do you en= d up > with a Proxy-Uri or not? The sentence is not clear. >=20 We will try to clarify this. We do reference CoAP processing though, so I d= on't really see how we could improve here. =20 > Section 5.2 - Why make code a bstr and not an uint? It is a small intege= r > value >=20 Right, we'll change this. > Section 52 - Why make alg a bstr and not an (int / tstr)? This more dire= ctly > maps what the value is. >=20 Changed too. > Section 5.2 - why not make the transaction-id be three separate fields? > This makes the field separation clearer. Done too. Please check section 5.2 again. >=20 > Section 5 - You have defined a 'sid' and said that it could be placed in = the > unprotected field, however you have also said that the unprotected field > must be empty. These statements are contradictory. Now we have moved the 'sid' definition as a COSE Header before. The idea is= that we need to define the 'sid' COSE Header, and for security purposes th= is _can_ be placed in the unprotected Header (as 'kid'), but in our applica= tion the 'sid' is protected. I don't see how these are contradictory.=20 >=20 > Section 2 - We had a discussion at one point about using the code as the = key > for the question of payload being present in a document. Specifically, o= ne > could do a put with an empty payload. In that case the version of the Ob= ject- > Security Option should be the one with payload. --- This is not done well= in > section 2 but is in section 6.2 >=20 Right. We will change this. > Section 6.1 - The reject limit on sequence number is defined as algorithm > specific rather than being a fixed constant. >=20 Yes. Is this a problem? TLS 1.3 also makes this algorithm specific, if I'm = not wrong. And wouldn't make more sense to have all limits in COSE, rather than in OSC= OAP? > Section 6.1 - If OSCOAP is a challenge-response, how can one observer? > That would be challenge-response-response-response. Is the Tid supposed > to be kept until one kills the observation? If so that should be highlig= hted. >=20 >=20 There are unique responses bound to each challenge. In case of observe, yes= , the Tid (in the AAD) is supposed to be the same for all the responses. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Dec 2 05:29:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488B61296DF; Fri, 2 Dec 2016 05:29:01 -0800 (PST) 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 UZxWlRxx1i9x; Fri, 2 Dec 2016 05:28:59 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF3F129472; Fri, 2 Dec 2016 05:28:58 -0800 (PST) X-AuditID: c1b4fb2d-073ff70000001117-63-584177179d15 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id B1.62.04375.71771485; Fri, 2 Dec 2016 14:28:56 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Fri, 2 Dec 2016 14:28:46 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" Thread-Topic: Comments on draft-ietf-core-object-security-00 Thread-Index: AdJLiTeDKEyfsMgGSoOfR4rDJInqcQBFsi+A Date: Fri, 2 Dec 2016 13:28:45 +0000 Message-ID: References: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> In-Reply-To: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <47E141A16CC0634F82BBB58777919E52@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7tK5EuWOEweUzWhb73q5ntpj27wyL xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsErox7V4+wFjwQq9i0ezZzA+MUsS5G Tg4JAROJiZdfsHYxcnEICaxjlPix4R8bhLOYUaL19G1mkCo2AReJBw2PmEASIgJNjBKP5/aB JZgFlCWOzz7MCmILC1hLTG3/zghiiwjYSHRM/M0MYRtJvHp3HizOIqAisX7SASCbg4NXwELi 8WIdkLCQgL3Euwe/WUDCnAIOEm87g0DCjAJiEt9PrWGC2CQucevJfCaIowUkluw5zwxhi0q8 fPwP7AJRAT2J2VMa2CHiShKLbn9mAhnJLKApsX6XPsQYa4lJ35+yQdiKElO6H4KV8woISpyc +YRlAqP4LCTbZiF0z0LSPQtJ9ywk3QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbd wS2/dXcwrn7teIhRgINRiYf3g5VDhBBrYllxZe4hRgkOZiUR3n/FjhFCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MEY2X7AxO/H00YrLH7cqJMnKbTQI ehSp8Sdu6yozt1lfSz73f9d762/4Jm6/2o6mGcINtbLN9m2xHFtsdmSbVTBH3rx+I/BN2V7r C093ibOlTXy8/425UaqJ5KnV/FXfliznYNLiUX4W+zHbcoaajF3i/SNtgS+Y9B9MaxZ6nC98 eq/83vXF55VYijMSDbWYi4oTAR/otry2AgAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 13:29:01 -0000 VGhlIGNvbW1lbnQgd2UgZGlkbuKAmXQgcmVzcG9uZCB0byBpbiB0aGUgcHJldmlvdXMgbWFpbDoN Cg0KT24gMjAxNi0xMi0wMSAyMjowMCwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMu Y29tPiB3cm90ZToNCg0KPlNlY3Rpb24gMyAtIEkgbGlrZSB0aGUgZmFjdCB0aGF0IHRoZSBzZWN1 cml0eSBjb250ZXh0IGlzIGJlaW5nIGRlZmluZWQsDQo+aG93ZXZlciBJIHF1ZXN0aW9uIHRoZSB3 aXNkb20gb2YgaW5jbHVkaW5nIHRoZSBzZWN0aW9ucyBvbiBob3cgdG8gZGVyaXZlIGENCj5jb250 ZXh0IGZyb20gYSBzaGFyZWQgc2VjcmV0IGF0IHRoaXMgcG9pbnQuICBJIHRoaW5rIGl0IHdvdWxk IG1ha2UgbW9yZQ0KPnNlbnNlIHRvIHB1dCB0aGlzIGludG8gdGhlIEVESE9DIGRvY3VtZW50LCBh bmQgaWYgeW91IGRvIG5vdCBkbyB0aGF0IHRoZW4NCj50bw0KPmF0IGxlYXN0IG1vdmUgdGhpcyBp bnRvIGFuIGFwcGVuZGl4LiAgSSBkbyBub3QgYmVsaWV2ZSB0aGF0IHRoaXMgaXMvc2hvdWxkDQo+ YmUgdGhlIG9ubHkgbWV0aG9kIHRvIHBvcHVsYXRlIGEgY29udGV4dC4gIEkgd291bGQgaG9wZSB0 aGF0IGEgbWV0aG9kIG9mDQo+ZG9pbmcgc28gZnJvbSBhIENXVCB3aWxsIGJlIGRlZmluZWQgYXMg dGhhdCBtYXkgaGF2ZSB0aGUgYWR2YW50YWdlIG9mDQo+Z2V0dGluZyBtb3JlIGNvbnRyb2xsZWQg cmFuZG9tIG51bWJlcnMuICBGcm9tIGEgc2VjdXJpdHkgYW5hbHlzaXMgcG9pbnQgb2YNCj52aWV3 LCB0aGVyZSBpcyBubyBkaWZmZXJlbmNlIGJldHdlZW4gZ2V0IHRoZSBzaGFyZWQgc2VjcmV0IHVz ZWQgaGVyZSBvcg0KPnRoZQ0KPmFjdHVhbCBrZXlzIGZyb20gYSB0aGlyZCBwYXJ0eS4gIFRoZXJl IGlzIGEgZGlmZmVyZW5jZSBpZiBFREhPQyBpcyB1c2VkLg0KDQpJbiBhIHByZXZpb3VzIHZlcnNp b24gb2YgdGhlIGRyYWZ0IHdlIGRpZCBleGFjdGx5IHRoYXQgLSBkZWZpbmUgdGhlDQpzZWN1cml0 eSBjb250ZXh0IGJ1dCBub3QgaG93IHRvIGFycml2ZSBhdCBpdC4gVGhpcyByYWlzZWQgc29tZSBx dWVzdGlvbnMsDQphbmQgd2UgZGVjaWRlZCB0aGF0IGhhdmluZyBlc3NlbnRpYWxseSBhIHNoYXJl ZCBiYXNlIGtleSAvIG1hc3RlciBzZWNyZXQNCnNlZW1lZCB0byBiZSBhIG11Y2ggbW9yZSBuYXR1 cmFsIHN0YXJ0aW5nIHBvaW50IGZvciBPU0NPQVAsIGFuZCB0aGVzZQ0KcGFyYW1ldGVycyBjb3Vs ZCBiZSBvYnRhaW5lZCBmcm9tIEVESE9DLCBBQ0UsIFRMUywgb3Igd2hhdGV2ZXIuIFNpbmNlDQpF REhPQyBpcyBub3QgdGhlIG9ubHkga2V5IGV4Y2hhbmdlIHByb3RvY29sIHRoYXQgY2FuIGJlIHVz ZWQgd2l0aCBPU0NPQVAsDQp0aGUgZGVyaXZhdGlvbiBvZiB0aGUgc2VjdXJpdHkgY29udGV4dCBt dXN0IGJlIGluY2x1ZGVkIGluIHRoaXMgZHJhZnQuDQoNCg0KSSBkb27igJl0IHVuZGVyc3RhbmQg dGhlIHBhcnQgImdldHRpbmcgbW9yZSBjb250cm9sbGVkIHJhbmRvbSBudW1iZXJz4oCdIHNpbmNl DQp0aGVyZSBubyBlbGVtZW50IG9mIHJhbmRvbW5lc3MgaW4gdGhlIGRlcml2YXRpb24uIFdoYXQg aXMgdGhlIGFkdmFudGFnZSBvZg0KaGF2aW5nIG11bHRpcGxlIHdheXMgdG8gZGVyaXZlIHRoZSBz ZWN1cml0eSBjb250ZXh0Pw0KDQoNCllvdXIgbWVudGlvbmluZyBvZiBDV1QsIGlzIHRoYXQgcmVm ZXJyaW5nIHRvIGl0cyB1c2UgYXMgYWNjZXNzIHRva2VuIGluDQpBQ0U/IElmIHNvLCB0aGUgQ1dU IGNvdWxkIGNvbnRhaW4gYSBzeW1tZXRyaWMgUE9QLWtleSBhbmQgc29tZSBvdGhlcg0KY2xhaW1z IGFuZCBmaXQgbmF0dXJhbCBpbnRvIHRoZSBjdXJyZW50IHdyaXRpbmcuDQoNCkkgc2VlIG1vcmUg aXNzdWVzIGZyb20gYSBjb25zdHJhaW5lZG5lc3MgcG9pbnQgb2YgdmlldyB0byB0cmFuc3BvcnQg YQ0KbGFyZ2Ugc2VjdXJpdHkgY29udGV4dCB0aGFuIHRvIGRlcml2ZSB0aGUgc2VjdXJpdHkgY29u dGV4dCBvbiBib2FyZC4NCg0KQXNzdW1pbmcgdGhhdCB3ZSBrZWVwIHRoZSBzaGFyZWQga2V5IGV0 Yy4gYXMgc3RhcnRpbmcgcG9pbnQgZm9yIE9TQ09BUCwgaXQNCmFsc28gbWFrZXMgc2Vuc2UgdG8g a2VlcCB0aGUgZGVyaXZhdGlvbiBvZiB0aGUgc2VjdXJpdHkgY29udGV4dCBpbiB0aGUNCmJvZHku DQoNCkfDtnJhbg0KDQoNCg== From nobody Fri Dec 2 06:11:16 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B021296B1; Fri, 2 Dec 2016 06:11:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148068787561.29697.7885102482488751283.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 06:11:15 -0800 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Stephen Farrell's No Objection on draft-ietf-core-http-mapping-17: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:11:16 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-http-mapping-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my DISCUSS points. OLD Comments below. I didn't check 'em vs. the latest draft. --- Generally, I'd have been happier if this document went more towards reducing the attack surface and seemed less keen on being more flexible. I assume though that the WG considered that. (Some specific places that occurred to me are noted below.) I also agree with Kathleen's discuss. - 6.1: "free to attempt mapping a single Accept header in a GET request to multiple CoAP GET requests" - does that provide a potential way to DoS (e.g. battery depletion) devices in the constrained network? If so, would a warning be useful? E.g. to limit the number of times a given media type is attempted. - 6.1: What "other forms of access control" do you mean? - 6.2: This looks like it allows too large an attack surface and maybe you ought default to denying - 6.5: Transcoding bugs galore! Given the history of bugs in transcoding libraries shouldn't you recommend some caution here? And are there forms of zipbomb that might cause problems? - 8.2: The presentation of the formula is not clear to me. You say "reduces M_R iff..." but that's not a clear "method to decide" as promised. - 10.3: In practice, what does "other means" mean in "This recommendation may be relaxed in case the destination network is believed to be secured by other means." ? From nobody Fri Dec 2 06:42:30 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C245A1294D4; Fri, 2 Dec 2016 06:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 ltsA6NViXeoh; Fri, 2 Dec 2016 06:42:19 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4241294B0; Fri, 2 Dec 2016 06:42:18 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id CE1A1521D229B; Fri, 2 Dec 2016 14:42:13 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uB2EgEtN032084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2016 14:42:16 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uB2Eg4M9031877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Dec 2016 14:42:12 GMT Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.191]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Fri, 2 Dec 2016 15:42:01 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Stephen Farrell , The IESG Thread-Topic: [ALU] [core] Stephen Farrell's No Objection ondraft-ietf-core-http-mapping-17: (with COMMENT) Thread-Index: AQHSTKX6Cpcz1W89X0WEBWxzu77d36D0qmUA Date: Fri, 2 Dec 2016 14:42:01 +0000 Message-ID: References: <148068787561.29697.7885102482488751283.idtracker@ietfa.amsl.com> In-Reply-To: <148068787561.29697.7885102482488751283.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_D467376D7724Bthomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] [ALU] Stephen Farrell's No Objection ondraft-ietf-core-http-mapping-17: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:42:22 -0000 --_000_D467376D7724Bthomasfossatialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stephen, All your comments had been addressed in =9615 [1] and the relevant text has= not changed since then. Cheers, thanks, t [1] https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-http-mapping-14&url= 2=3Ddraft-ietf-core-http-mapping-15 On 02/12/2016 14:11, "core on behalf of Stephen Farrell" on behalf of stephen.farrell@cs.tcd.ie> wrote: Stephen Farrell has entered the following ballot position for draft-ietf-core-http-mapping-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my DISCUSS points. OLD Comments below. I didn't check 'em vs. the latest draft. --- Generally, I'd have been happier if this document went more towards reducing the attack surface and seemed less keen on being more flexible. I assume though that the WG considered that. (Some specific places that occurred to me are noted below.) I also agree with Kathleen's discuss. - 6.1: "free to attempt mapping a single Accept header in a GET request to multiple CoAP GET requests" - does that provide a potential way to DoS (e.g. battery depletion) devices in the constrained network? If so, would a warning be useful? E.g. to limit the number of times a given media type is attempted. - 6.1: What "other forms of access control" do you mean? - 6.2: This looks like it allows too large an attack surface and maybe you ought default to denying - 6.5: Transcoding bugs galore! Given the history of bugs in transcoding libraries shouldn't you recommend some caution here? And are there forms of zipbomb that might cause problems? - 8.2: The presentation of the formula is not clear to me. You say "reduces M_R iff..." but that's not a clear "method to decide" as promised. - 10.3: In practice, what does "other means" mean in "This recommendation may be relaxed in case the destination network is believed to be secured by other means." ? _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_D467376D7724Bthomasfossatialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <756C0FA68BA37340976597E9DE96B506@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Hi Stephen,

All your comments had been addressed in =9615 [1] and the relevant tex= t has not changed since then.

Cheers, thanks,
t

[1] https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-http-mapping-1= 4&url2=3Ddraft-ietf-core-http-mapping-15

On 02/12/2016 14:11, "core on behalf of Stephen Farrell" <= ;core-bounces@ietf.org on beha= lf of stephen.farrell@cs.tcd.ie&= gt; wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-core-http-mapping-17: No Objection

When responding, please keep the subject line intact and reply to all<= /div>
email addresses included in the To and CC lines. (Feel free to cut thi= s
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/



----------------------------------------------------------------------=
COMMENT:
----------------------------------------------------------------------=


Thanks for handling my DISCUSS points.

OLD Comments below. I didn't check 'em vs. the latest
draft.
---


Generally, I'd have been happier if this document went more
towards reducing the attack surface and seemed less keen on
being more flexible. I assume though that the WG considered
that. (Some specific places that occurred to me are noted
below.)

I also agree with Kathleen's discuss.

- 6.1: "free to attempt mapping a single Accept header in a
GET request to multiple CoAP GET requests" - does that
provide a potential way to DoS (e.g. battery depletion)
devices in the constrained network? If so, would a warning be
useful? E.g. to limit the number of times a given media type
is attempted.

- 6.1: What "other forms of access control" do you mean?

- 6.2: This looks like it allows too large an attack surface
and maybe you ought default to denying

- 6.5: Transcoding bugs galore! Given the history of bugs in
transcoding libraries shouldn't you recommend some caution
here? And are there forms of zipbomb that might cause
problems?

- 8.2: The presentation of the formula is not clear to me.
You say "reduces M_R iff..." but that's not a clear "me= thod
to decide" as promised.

- 10.3: In practice, what does "other means" mean in "T= his
recommendation may be relaxed in case the destination network
is believed to be secured by other means." ?


_______________________________________________
core mailing list



--_000_D467376D7724Bthomasfossatialcatellucentcom_-- From nobody Fri Dec 2 06:43:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F571296C0; Fri, 2 Dec 2016 06:43:07 -0800 (PST) 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 HZvZgTegL0rl; Fri, 2 Dec 2016 06:43:06 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7C312953B; Fri, 2 Dec 2016 06:42:38 -0800 (PST) X-AuditID: c1b4fb30-c294498000000c18-e6-5841885caff6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 13.2A.03096.C5881485; Fri, 2 Dec 2016 15:42:36 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Fri, 2 Dec 2016 15:42:35 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" Thread-Topic: OSCOAP and BLOCK Thread-Index: AdJMM6FI9YM3owHuQxeJe70R2ag74AAdq92A Date: Fri, 2 Dec 2016 14:42:34 +0000 Message-ID: References: <02a301d24c35$07d87690$178963b0$@augustcellars.com> In-Reply-To: <02a301d24c35$07d87690$178963b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <1B86068A43A94646A15851C8D013B90C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7k25Mh2OEwd/DYhb73q5ntpj27wyL xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsEroy2p+vZClbwVew66NvA+IO3i5GT Q0LARGLvtNtMXYxcHEIC6xgl1vQ1QjmLGSVuLn3LAlLFJuAi8aDhEVhCRKCJUeLx3D5mkASz gLLE8dmHWbsYOTiEBWQlVrTkgoRFBOQk/p28wAphG0ms23OaHcRmEVCR2NHYCRbnFbCQOLl4 KiOILSRgL7Fq+TKwkZwCDhKNG+6A1TMKiEl8P7WGCWKVuMStJ/OZIK4WkFiy5zwzhC0q8fLx P7CZogJ6ErOnNLBDxJUkVmy/xAhyGrOApsT6XfoQY6wl3s3fzQhhK0pM6X7IDnGOoMTJmU9Y JjCKz0KybRZC9ywk3bOQdM9C0r2AkXUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmDUHdzy 22AH48vnjocYBTgYlXh4P1g5RAixJpYVV+YeYpTgYFYS4Z3Y5hghxJuSWFmVWpQfX1Sak1p8 iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUAyPrS87d1gEvV167+fzV82kG357uPNby VblCN3FR4cG0ZoUGlajqg2p3A3ist5SIHC55tVrqgeC2vXx/A/8fPiBXNFNy9ZP1Yo8DuEy5 TYwUDk2sWuM67/zWoHiV+Zej8p5JGGX8VGANq/GfXpmwuJBx4lzZkx6MH6UibQ4/dbfW/yl8 487CLnslluKMREMt5qLiRADNUpOBtgIAAA== Archived-At: Cc: "core@ietf.org" Subject: Re: [core] OSCOAP and BLOCK X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:43:08 -0000 DQpPbiAyMDE2LTEyLTAyIDAxOjQyLCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5j b20+IHdyb3RlOg0KDQo+SSBkaWQgbm90IGluY2x1ZGUgdGhpcyBjb21tZW50IGluIHRoZSBwcmV2 aW91cyBtZXNzYWdlIGJlY2F1c2UgSSB3YXMgc3VyZQ0KPnRoYXQgdGhlcmUgbXVzdCBoYXZlIGJl ZW4gc29tZXRoaW5nIHRoYXQgSSB3YXMganVzdCBtaXNzaW5nLg0KDQpKdXN0IHRlc3Rpbmcgb25l IHRoaW5nIHdoaWNoIHdlIHJlYWxpemVkIGlzIG5vdCB2ZXJ5IGNsZWFyIGluIHRoZSBjdXJyZW50 DQp3cml0aW5nOiB0aGUgdHdvIGluc3RhbmNlcyBvZiB0aGUgZHVwbGljYXRlIG9wdGlvbnMgYSkg aW4gZ2VuZXJhbCBkb27igJl0DQpoYXZlIHRoZSBzYW1lIHZhbHVlLCBhbmQgYikgZG8gbm90IGJv dGggbmVlZCB0byBiZSBwcmVzZW50IGluIGEgZ2l2ZW4NCm1lc3NhZ2UuIFdhcyB0aGlzIHRoZSBz b3VyY2UgZm9yIG1pc3VuZGVyc3RhbmRpbmc/DQoNClRoZSBpbm5lciBibG9jayBvcHRpb24sIHdo aWNoIGlzIHByb3RlY3RlZCBieSB0aGUgQ09TRSBtZXNzYWdlIGlzIG9ubHkNCnRhbGtpbmcgYWJv dXQgdGhlIHNlZ21lbnRhdGlvbiBlbmQtdG8tZW5kLCB3aGVyZWFzIHRoZSBvdXRlciB1bnByb3Rl Y3RlZA0KYmxvY2sgb3B0aW9uIGlzIG9ubHkgYWJvdXQgdGhlIHNlZ21lbnRhdGlvbiBpbiB0aGUg Y3VycmVudCBob3AsIGFuZCB0aGUNCnZhbHVlcyBvZiB0aG9zZSBvcHRpb25zIGFyZSB0aHVzIHNl dCBpbmRlcGVuZGVudGx5LiBJbiBmYWN0LCB0aGUgb3V0ZXINCmJsb2NrIG9wdGlvbiBtYXkgY2hh bmdlIG11bHRpcGxlIHRpbWVzIHRocm91Z2hvdXQgdGhlIGpvdXJuZXkgb2YgdGhlDQptZXNzYWdl IGlmIGl0IGJlY29tZXMgZnJhZ21lbnRlZCBhbmQgcmVhc3NlbWJsZWQgc2V2ZXJhbCB0aW1lcywg d2hlcmVhcw0KdGhlIGlubmVyIGJsb2NrIG9wdGlvbiByZW1haW5zIGNvbnN0YW50IChvciwgaWYg aXQgaXMgY2hhbmdlZCwgd2lsbCBiZQ0KZGV0ZWN0ZWQpLg0KDQoNCj4NCj5JIGFsc28gaGF2ZSBu byBpZGVhIHdoZXJlIHRoZSBNQUMgdmFsdWUgdGhhdCBpcyBiZWluZyB1c2VkIHRvIGNoYWluDQo+ YmxvY2tlZA0KPm1lc3NhZ2VzIGlzIGNvbWluZyBmcm9tLg0KPg0KDQpUaGlzIE1BQyBpcyB0aGUg bGFzdCBieXRlcyBvZiB0aGUgQUVBRCBvdXRwdXQgb2YgdGhlIENPU0UgbWVzc2FnZQ0KY29udGFp bmluZyBhIGZyYWdtZW50IGdlbmVyYXRlZCBieSB0aGUgb3JpZ2luYXRpbmcgZW5kcG9pbnQsIGFu ZCB2ZXJpZmllZA0KYnkgdGhlIGRlc3RpbmF0aW9uIGVuZHBvaW50Lg0KDQpEb2VzIGl0IG1ha2Ug bW9yZSBzZW5zZT8NCg0KR8O2cmFuDQoNCg== From nobody Fri Dec 2 06:44:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A401129636 for ; Fri, 2 Dec 2016 06:44:23 -0800 (PST) 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 mcGoGctYTy4x for ; Fri, 2 Dec 2016 06:44:21 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6293612951D for ; Fri, 2 Dec 2016 06:44:21 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-33-584188c3890a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 27.F1.32482.3C881485; Fri, 2 Dec 2016 15:44:19 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Fri, 2 Dec 2016 15:44:18 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: [core] OSCOAP update Thread-Index: AQHSSxif7sKIdzvIZ0GoNx6934CUxKDxkn6AgAMsbQA= Date: Fri, 2 Dec 2016 14:44:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7tO7hDscIgyeTTCyOTLnLarHv7Xpm ByaPJUt+MnlMW5QZwBTFZZOSmpNZllqkb5fAlfHh9wKmgiUcFQ2X+1kbGDs4uhg5OCQETCS2 rzfsYuTiEBJYxyjx5dYtdghnMaNET+9J1i5GTg42AReJBw2PmEBsEQEliQsX17CB2MwCyhLH Zx8GqxEWUJTYuvg9M8hQsJq92RDlVhLLpp5mBrFZBFQk9s7+BNbKK2Ah8ej3drC4kECmxL/e S2CtnALWEru3J4OEGQXEJL6fWsMEsUlc4taT+WC2hICAxJI955khbFGJl4//gV0gKqAnMXtK AztEXEmicckTVpCRzAKaEut36UOMsZY4+WgxM4StKDGl+yE7xDWCEidnPmGZwCg+C8m2WQjd s5B0z0LSPQtJ9wJG1lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgVF2cMtv1R2Ml984HmIU 4GBU4uH9YOUQIcSaWFZcmXuIUYKDWUmEd2KbY4QQb0piZVVqUX58UWlOavEhRmkOFiVxXrOV 98OFBNITS1KzU1MLUotgskwcnFINjBpr/3Qr7uXd7PNb6G4ne2falNhdn2XaNnKq7q7ULu29 nnZYxM/Qbe4zSeX01iXqWx0P7C88/bRAYWN00i6HrWw2/3lZT8rqrr88bVFUjqPrs/7QmMN/ OQ8E3yw/FnbumvG5uTy+2Yc37jz3YRfbJMawsJYFWgv3+z8Mcg76KxjYNKvDnF1OWYmlOCPR UIu5qDgRAN9CuWWuAgAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] OSCOAP update X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:44:23 -0000 DQoNCk9uIDIwMTYtMTEtMzAgMTY6MTYsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQo+T24gMzAgTm92IDIwMTYsIGF0IDE1OjQ3LCBHw7ZyYW4gU2VsYW5kZXIgPGdv cmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4NCj53cm90ZToNCj4+IA0KPj4gV2UgcGxhbiB0byBy ZWxlYXNlIGEgdmVyc2lvbiAtMDEgdGhpcyB3ZWVrIChhbHNvIGNvbnNpZGVyaW5nIHRoZSByZWNl bnQNCj4+IGNvbW1lbnRzIGZyb20gSmltKSBhbmQgd291bGQgcHJvcG9zZSB1cyB0byB1c2UgLTAx IGFzIHRoZSBpbXBsZW1lbnRhdGlvbg0KPj4gdmVyc2lvbiBpbnN0ZWFkIG9mIC0wMC4NCj4NCj5T b3VuZHMgZ29vZCB0byBtZS4gIE1heWJlIHdlIHNob3VsZCBldmVuIGdldCBpbiBhIGZldyByZXZp ZXdzIG9mIC0wMQ0KPmJlZm9yZSB3ZSBsYWJlbC4NCj4NCj5JIHRoaW5rIHRoZSBiZXN0IHdheSB0 byBnZXQgdGhlc2UgaXMgZm9yIHRoZSBjaGFpcnMgdG8gaXNzdWUgYSBmb3JtYWwNCj5sYXN0IGNh bGwgb24gLTAxIG9uY2UgaXRzIHRoZXJlIChub3QgYSBXR0xDLCBidXQgYSBsYXN0IGNhbGwgYmVm b3JlDQo+bGFiZWxpbmcpLiAgVGhpcyBzaG91bGQgYmUgZG9hYmxlIGluIGEgd2VlaywgSSB0aGlu ay4NCg0KV2Ugd291bGQgbGlrZSB0byBnbyBvdmVyIEppbeKAmXMgbGF0ZXN0IHJvdW5kIG9mIGNv bW1lbnRzIGJlZm9yZSByZWxlYXNpbmcNCi0wMSwgc28gaXQgd2lsbCBjb21lIG5leHQgd2VlayBp bnN0ZWFkIG9mIHRvZGF5Lg0KDQpHw7ZyYW4NCg0KDQo= From nobody Fri Dec 2 17:51:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526631294D7; Fri, 2 Dec 2016 17:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 Ig4HfSx6i38w; Fri, 2 Dec 2016 17:51:09 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F33B1294D4; Fri, 2 Dec 2016 17:51:09 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 18:10:42 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> In-Reply-To: Date: Fri, 2 Dec 2016 17:50:55 -0800 Message-ID: <043e01d24d07$b13f9650$13bec2f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJQYzPohZqCNQ6QgBJW9Bzqza6ZYAPHk5ANn9sHmtA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: Re: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 01:51:11 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Friday, December 02, 2016 5:29 AM > To: Jim Schaad ; draft-ietf-core-object- > security@ietf.org > Cc: core@ietf.org > Subject: Re: Comments on draft-ietf-core-object-security-00 >=20 > The comment we didn=E2=80=99t respond to in the previous mail: >=20 > On 2016-12-01 22:00, "Jim Schaad" wrote: >=20 > >Section 3 - I like the fact that the security context is being = defined, > >however I question the wisdom of including the sections on how to > >derive a context from a shared secret at this point. I think it = would > >make more sense to put this into the EDHOC document, and if you do = not > >do that then to at least move this into an appendix. I do not = believe > >that this is/should be the only method to populate a context. I = would > >hope that a method of doing so from a CWT will be defined as that may > >have the advantage of getting more controlled random numbers. From a > >security analysis point of view, there is no difference between get = the > >shared secret used here or the actual keys from a third party. There > >is a difference if EDHOC is used. >=20 > In a previous version of the draft we did exactly that - define the = security > context but not how to arrive at it. This raised some questions, and = we decided > that having essentially a shared base key / master secret seemed to be = a much > more natural starting point for OSCOAP, and these parameters could be > obtained from EDHOC, ACE, TLS, or whatever. Since EDHOC is not the = only key > exchange protocol that can be used with OSCOAP, the derivation of the = security > context must be included in this draft. >=20 >=20 > I don=E2=80=99t understand the part "getting more controlled random = numbers=E2=80=9D since > there no element of randomness in the derivation. What is the = advantage of > having multiple ways to derive the security context? Both EDHOC and TLS (depending on who you talk to) require that you have = a level of random numbers that might or might not be well suited to a = constrained device where you can get into situations that either you = don't have a good source, or when you re-start you end up with the same = stream. Only going with ACE tokens can you be ensured of having a good = source of randomness for these cases. =20 >=20 >=20 > Your mentioning of CWT, is that referring to its use as access token = in ACE? If > so, the CWT could contain a symmetric POP-key and some other claims = and fit > natural into the current writing. Yes, that is what I was thinking of. I agree that it can hold the = symmetric POP-key, however it can also equally well hold the entire = security context. In some cases this will be far more preferred to than = doing the key derivation steps. One case where this would be true is if = you are doing multicast. As part of the join response, the token could = return the full set of items that are needed. This could be either just = the receive fields, if no responses are going to need to be sent back, = or both the send and receive fields. If both sets of fields are sent = back, then it is not possible for to try and generate a new set of keys = for a different end point that is part of the multi-cast. You have = very different security properties in these cases. >=20 > I see more issues from a constrainedness point of view to transport a = large > security context than to derive the security context on board. It will depend on what security properties you want. >=20 > Assuming that we keep the shared key etc. as starting point for = OSCOAP, it also > makes sense to keep the derivation of the security context in the = body. I think it makes more sense to move to an appendix. Jim >=20 > G=C3=B6ran >=20 From nobody Fri Dec 2 18:09:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691861294F9; Fri, 2 Dec 2016 18:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 OLoqoTv13JUJ; Fri, 2 Dec 2016 18:09:21 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0E01294D7; Fri, 2 Dec 2016 18:09:20 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 18:29:01 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <02a301d24c35$07d87690$178963b0$@augustcellars.com> In-Reply-To: Date: Fri, 2 Dec 2016 18:09:13 -0800 Message-ID: <044001d24d0a$40116820$c0343860$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIBsRHOg6QRbG4c0Rd89/U/ypr/bAG/OQOEoIi0G8A= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: Re: [core] OSCOAP and BLOCK X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 02:09:22 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Friday, December 02, 2016 6:43 AM > To: Jim Schaad ; draft-ietf-core-object- > security@ietf.org > Cc: core@ietf.org > Subject: Re: OSCOAP and BLOCK >=20 >=20 > On 2016-12-02 01:42, "Jim Schaad" wrote: >=20 > >I did not include this comment in the previous message because I was > >sure that there must have been something that I was just missing. >=20 > Just testing one thing which we realized is not very clear in the = current > writing: the two instances of the duplicate options a) in general = don=E2=80=99t have the > same value, and b) do not both need to be present in a given message. = Was this > the source for misunderstanding? That would be a very large cause of misunderstanding. The word = duplicate to me means that they start with the same value, even if the = values may be changed at a later date. If that is the case, then I = think there may be other items which should be marked as duplicate. One = example of that would be Uri-Path as I suggested in a different mail = where all OSCOAP mail could be sent to a well-known point and thus there = would be a Uri-Path in the duplicate column. =20 The test code that I wrote automatically copied the option to the = encrypted request and left it alone in the unencrypted request. This = must not be what you meant and that is a surprise. >=20 > The inner block option, which is protected by the COSE message is only = talking > about the segmentation end-to-end, whereas the outer unprotected block > option is only about the segmentation in the current hop, and the = values of > those options are thus set independently. In fact, the outer block = option may > change multiple times throughout the journey of the message if it = becomes > fragmented and reassembled several times, whereas the inner block = option > remains constant (or, if it is changed, will be detected). >=20 >=20 > > > >I also have no idea where the MAC value that is being used to chain > >blocked messages is coming from. > > >=20 > This MAC is the last bytes of the AEAD output of the COSE message = containing a > fragment generated by the originating endpoint, and verified by the = destination > endpoint. This would be call the AEAD Tag value not the MAC value. Different = beast. Jim >=20 > Does it make more sense? >=20 > G=C3=B6ran From nobody Fri Dec 2 18:38:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C95129530; Fri, 2 Dec 2016 18:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 d4yjQmfKU1Tq; Fri, 2 Dec 2016 18:38:45 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A918129525; Fri, 2 Dec 2016 18:38:44 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 18:58:18 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <083101d24ad0$3b071aa0$b1154fe0$@augustcellars.com> In-Reply-To: Date: Fri, 2 Dec 2016 18:38:31 -0800 Message-ID: <044101d24d0e$57fbdb10$07f39130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKaVnhZja3Zi1ELigv8nmadx6425QH62YMNn1WRANA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: Re: [core] Comments on draft-ietf-core-object-security-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 02:38:47 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Friday, December 02, 2016 12:31 AM > To: Jim Schaad ; draft-ietf-core-object- > security@ietf.org > Cc: core@ietf.org > Subject: Re: Comments on draft-ietf-core-object-security-06 >=20 > Hi Jim, >=20 > Thanks for your comments. The subject of this thread should of course = be > "Comments on draft-ietf-core-object-security-00=E2=80=9D. I think the -06 is left over from looking at the EDHOC document. You = are completely correct it should have been -00 >=20 > Appendix C, OSCON, is addressing other use cases than OSCOAP, more of = this > below. It has not been progressed lately since we wanted to focus on = the > OSCOAP use cases which seem most relevant at this stage. Also we were = waiting > for Klaus to present his solution, which may overlap with OSCON. I = will make > Github issues out of the comments inline, but we may incorporate those = in the > draft at a later stage since we have a tight time schedule for OSCOAP. >=20 > On 2016-11-30 07:08, "Jim Schaad" wrote: >=20 > > > >Appendix C - I am having a hard time with the first paragraph here. = I > >do not believe that you have correctly characterized the problem. = The > >reason that you cannot use OSCOAP for this has more to do with how = you > >decided which records in the header to authenticate rather than the > >fact that this is going to be distributed to multiple recipients. >=20 > The intended logic is the following: >=20 > The security requirements draft > https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs = currently > describes three use cases =E2=80=9Cproxy forwarding=E2=80=9D, = =E2=80=9Cproxy caching=E2=80=9D and =E2=80=9Cpublish- > subscribe=E2=80=9D. The solutions to these requirements protect as = much as is possible, > while still allowing the functionality of the use case. > OSCOAP addresses the "proxy forwarding=E2=80=9D use case, which is a = basic CoAP > request-response with optional forward proxy functionality. This is a = use case > we have been requested to support, and it is an interesting case also = because > essentially all options and headers that are passed end-to-end in a = CoAP request > and response can be protected, response can be bound to a request, and = some > other security features can be supported. >=20 > OSCON addresses other use cases with a common solution, including the = two > remaining use cases mentioned above. In these cases less of the = records can be > protected, e.g. because a single response should be meaningful to = multiple > requests. This solution thus targets a format where multiple use cases = can be > supported rather than optimising security for a particular use case. >=20 > I will make an issue to clarify this. It is not the least bit clear to me that publish-subscribe case cannot = be done with OSCOAP. The proxy caching problem is more difficult, but = is not solved by OSCON in a way that is not also solved in the OSCOAP = case as far as I can tell. >=20 > > > >Appendix C - Talking about the "unprotected" and the "protected" CoAP > >message is very confusing especially since COSE has protected and > >unprotected objects as well. It would be better to use a different > >terminology such as "the original message" and "the resulting = message". >=20 > This terminology is defined in the body of the draft. (FWIW the = terminology > probably predates COSE.) If we always qualify with = unprotected/unprotected > CoAP, protected/unprotected COSE header, I suppose there would less of = a risk > for misunderstanding? Doing the full qualification would be nice. I will admit that I = probably missed that since I started half way down the document. >=20 > > > >Appendix C - I do not understand what this sentence means. " OSCON > >shall not be used in cases which require a secure binding between > >request and response." Is it intended to say that the use of a > >transaction identifier in the COSE wrappers for the request and > >response is not permitted? There are a lot of ways to do this that = do > >not rely on CoAP. >=20 > As mentioned, this format is addressing use cases which does not bind = response > to request. It is possible to define a wrapping of a message exchange = in COSE > which has different features, but that was not the intention here. This is not making it any clearer to me.=20 >=20 >=20 > > > >Appendix C - It is not clear if the Content-Format should be set if > >there was no Content-Format in the original message. >=20 > It should, to be clarified. >=20 > > > >Appendix C.1 - I do not understand what this section is trying to > >accomplish. It appears to be doing three different things, some of > >which should be in Appendix C, some of which should be standalone and > >some of which looks like it should be >=20 > It is an introduction to sections C.2-C.5. We should clarify that. Making C.2-C.5 be sub sections would probably also help Jim >=20 > > > >Appendix C.5 - There should be a discussion related this this about = the > >different security properties that are to be found for = Encrypt+Sign(M) > >vs Sign(Encrypt(M)). >=20 > There are plans to write more about the security properties of SEAS, = probably in > a different document. >=20 > > > >Appendix B - These are really example message flows rather than > >examples of OSCOP messages. This should be made clearer in the = section > >title >=20 > OK, I=E2=80=99ll make that update in -01. >=20 > > > >Appendix B.1 - How does one securely bind the request and the = response? > >I am not seeing anything from this example that will do so. >=20 > No, it is not visible from the message format. See section 6.1 "the = response is > verified to match a prior request, by including the unique transaction = identifier > of the request in the Additional Authenticated Data of the response = message." >=20 > G=C3=B6ran >=20 From nobody Fri Dec 2 19:35:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F718129580; Fri, 2 Dec 2016 19:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 Fbc3l0FkHLBq; Fri, 2 Dec 2016 19:35:01 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAECD129575; Fri, 2 Dec 2016 19:35:00 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 19:54:33 -0800 From: Jim Schaad To: 'Francesca Palombini' , 'Ludwig Seitz' , References: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> <5ea88fb4-92c8-752b-9940-64c9446be722@sics.se> <030001d24c72$279562d0$76c02870$@augustcellars.com> In-Reply-To: Date: Fri, 2 Dec 2016 19:34:45 -0800 Message-ID: <044801d24d16$332c82a0$998587e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJQYzPohZqCNQ6QgBJW9Bzqza6ZYAGbTM2dAgkf2NEBFqWvqJ/TiPBg Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: Re: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 03:35:04 -0000 > -----Original Message----- > From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] > Sent: Friday, December 02, 2016 2:42 AM > To: Jim Schaad ; 'Ludwig Seitz' ; > draft-ietf-core-object-security@ietf.org > Cc: core@ietf.org > Subject: RE: [core] Comments on draft-ietf-core-object-security-00 > > Jim, > > Thank you so much for a detailed review! > > Before answering inline, please note that some of these comments were already > taken care of in the latest version (commit 30475e3 in the github > https://github.com/core-wg/oscoap ), updated yesterday (1st of December). > > Francesca > > > -----Original Message----- > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Jim Schaad > > Sent: den 1 december 2016 22:00 > > To: draft-ietf-core-object-security@ietf.org > > Cc: core@ietf.org > > Subject: [core] Comments on draft-ietf-core-object-security-00 > > > > Section 3 - I like the fact that the security context is being > > defined, however I question the wisdom of including the sections on > > how to derive a context from a shared secret at this point. I think > > it would make more sense to put this into the EDHOC document, and if > > you do not do that then to at least move this into an appendix. I do > > not believe that this is/should be the only method to populate a > > context. I would hope that a method of doing so from a CWT will be > > defined as that may have the advantage of getting more controlled > > random numbers. From a security analysis point of view, there is no > > difference between get the shared secret used here or the actual keys from a > third party. There is a difference if EDHOC is used. > > > > Section 3.1 - I would think that you might be better off having the > > Cid be potentially different between the sender and receiver. > > Currently the closest you get in EDHOC would be to use the nonces, > > which are too long to be used here. > > > > I am still not 100% sure what you mean here. Do you mean discard the use of > Cid and only use Sender ID and Recipient ID to retrieve the right contexts? This > creates problems with the current text since the Cid should be globally unique > and the Sender/Recipient ID only locally unique. What would be the advantage > of using Recipient ID instead of Cid? > Remember that I don't believe in global uniqueness of Cid values. No I do not mean to discard the IDs and replace the Cid with them. I think that you might be in a situation where you have the same IDs but different Cids when talking to the same server. This would be a situation where you have different ACLs that were established with different secrets. However, if the Cid value is locally unique then the value would be different on the two different sides rather than shared. Thus EDHOC could send not only IDs, which would correspond to ACLs but also a locally unique Cid can be enforced where a global unique one cannot. > > Section 3.1 - Base Key should be Shared-Secret. The term key > > generally indicates that there are some additional restrictions which > > would not apply in this case - an example would be key lengths. It is > > also possible that somebody could incorrectly believe that an > > asymmetric key could somehow work. > > > > Good point. What about using Master Secret? (Inspired by TLS terminology, it > avoids overlapping with EDHOC terminology) Works for me. > > > Section 3.1 - In principle, the algorithm could be different between > > the sender and receiver context. I am not sure that I would disallow > > this in defining your context structure. > > > > Point taken. If there is use case/interest for this, we may consider adding this, > but for simplicity reasons we think that request and response should be > protected with the same algorithm. I agree that they are almost always going to be the same, but there is a difference between saying that and enforcing that by where you put the algorithm in the context. Another place where this might come in is that you could have a and a field in the context. In this case the algorithms are going to be going to be different, but it is still useful to think of them as parts of the same security context > > > Section 3.1 - If Base Key and the IDs are not needed once the security > > context has been setup, remove them from the definition of the context > > and just make them pre-requests for the context algorithm creation you > > are defining. > > > > About the IDs, the Sender/Recipient ID need to be kept since it is used in the > AAD. We can remove the Base Key. Is there a security reasoning behind this? > > > Section 3.1 - Do not use the word signed when talking about > > authenticated data. The operations are not even close to being the > > same thing from a cryptographic point of view. > > > > Yes, this was removed in latest revision (commit 30475e3) > > > Section 3.1 - make the last paragraph look more like " The client and > > server may change roles while maintaining the same security context. > > When this happens, the former server still makes use of its Sender > > Context when sending messages and Recipient Context when receiving > messages. > > The same is also true for the former client. In other words, changing > > the roles does not change the set of keys to be used." > > > > Ok, we will integrate your proposal into the updated version (at line 237 of the > md document). > > > Section 3.2 - The term "in a previous phase" is probably a poor choice > > of words. The term phase implies to me to be part of what we are > > currently done, but that is not defined. Just kill the clause. > > > > Agreed (true for the 4 occurrences). > > > Section 3.2 - Why is the replay window an input - this seems to be odd > > as you would not pre-fill part of the window. I assume this is really > > just the Replay Window Size. > > > > Ok (changed in updated version) > > > Section 3.2.1 - The method of creating info is insufficiently defined. > > The current method does not correctly separate the different fields > > that are used to build it. > > > > Ok (also changed) > > > Section 3.2.3 - 64 bits for the Cid seems to be very long. You are > > not being consistent with your discussion in Appendix A.4 where the Cid is only > 32-bits. > > 32-bits is much more likely value to be used, in some cases it may be > > only 16- bits. > > > > 64 is just a recommendation. We did add text about shorter Cid (line 289 of the > md doc). Right, but if 64 is your recommendation then it should be what you in the appendixes. > > > Section 3.2 - I would like to see a justification of using the Tid as > > a value that needs to be authenticated as part of the message. I > > don't see it in this anyplace. It should be part of a security argument. > > > > We did add some text in line 209 "The Tid is part of the Additional Authenticated > Data (AAD, see {{sec-obj-cose}}) of the protected CoAP response message, > which is how responses are bound to requests.", is this not enough? Why is insufficient? > > > Section 3.2.3 - The last paragraph talks about what EDHOC does. This > > has two problems, first this should be in that document rather than > > here and second you are talking about using a 256-bit or 512-bit value > > which is even longer than you are documenting as being "normal" > > > > Right, this was removed. > > > Section 3.2.3 - You are getting ahead of yourself. The only way that > > the identifiers would not be unique would be if the sender and recipient > collided. > > I do not know that this would be a problem and therefore talking about > > it makes no sense. I am assuming that this is supposed to have > > something to do with the multicast work that I have not looked at. If > > so it does not belong here but there. > > > > The new updated version say "SHALL be unique", as any collisions may lead to > loss of both confidentiality and integrity. Need to look, but I don't think I understand. > > > Section 4 - I do not understand the processing of a Proxy-Uri. Do you > > end up with a Proxy-Uri or not? The sentence is not clear. > > > > We will try to clarify this. We do reference CoAP processing though, so I don't > really see how we could improve here. > > > Section 5.2 - Why make code a bstr and not an uint? It is a small > > integer value > > > > Right, we'll change this. > > > Section 52 - Why make alg a bstr and not an (int / tstr)? This more > > directly maps what the value is. > > > > Changed too. > > > Section 5.2 - why not make the transaction-id be three separate fields? > > This makes the field separation clearer. > > Done too. Please check section 5.2 again. > > > > > Section 5 - You have defined a 'sid' and said that it could be placed > > in the unprotected field, however you have also said that the > > unprotected field must be empty. These statements are contradictory. > > Now we have moved the 'sid' definition as a COSE Header before. The idea is > that we need to define the 'sid' COSE Header, and for security purposes this > _can_ be placed in the unprotected Header (as 'kid'), but in our application the > 'sid' is protected. I don't see how these are contradictory. > > > > > Section 2 - We had a discussion at one point about using the code as > > the key for the question of payload being present in a document. > > Specifically, one could do a put with an empty payload. In that case > > the version of the Object- Security Option should be the one with > > payload. --- This is not done well in section 2 but is in section 6.2 > > > > Right. We will change this. > > > Section 6.1 - The reject limit on sequence number is defined as > > algorithm specific rather than being a fixed constant. > > > > Yes. Is this a problem? TLS 1.3 also makes this algorithm specific, if I'm not > wrong. > And wouldn't make more sense to have all limits in COSE, rather than in > OSCOAP? I was just objecting to having the number at this location not the idea of a limit. Jim > > > Section 6.1 - If OSCOAP is a challenge-response, how can one observer? > > That would be challenge-response-response-response. Is the Tid > > supposed to be kept until one kills the observation? If so that should be > highlighted. > > > > > > There are unique responses bound to each challenge. In case of observe, yes, > the Tid (in the AAD) is supposed to be the same for all the responses. > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Sat Dec 3 00:43:14 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C05129624; Sat, 3 Dec 2016 00:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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=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 QT812C4F84VO; Sat, 3 Dec 2016 00:43:07 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1881295A5; Sat, 3 Dec 2016 00:43:07 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id 3so116484774pgd.0; Sat, 03 Dec 2016 00:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:mime-version :content-transfer-encoding; bh=eVWhb+u145s36rKWpno8O/fFqCSOJzsuC4fLcdxiQgg=; b=dtDA3o35FwuZHwYi0WwlCJmB6VHRcvcMZwwo1SvGU9lqtQwU4w0qS4fhX/4Uq6kKMR lSkBuNFou1tW5HIrXo5j6Igyg2P9mmK36D1+k9TKHK+kZ7R1LmR5VhRXJaPBATOTIWL5 Z05uhcHXphAO5PMKg0QRhBvorwhPWWAN98qFc+Pj9+Acvl5CPkH0X2Ky142bfDlNr1XM 63d75FV8Aj7OmBe4BDwED1wvNG1uM/UrAeBf7pt9lFUc4a/Hp/K0Iz4HeageLqdIQQC+ xEhkjtZguJCGFFONaSK7AkciVXBU7G7vGFptGBxKjQHC/d9CUuSUtQbdKP/lvc+K+6Ki Dfag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:subject:from:to:cc:date :mime-version:content-transfer-encoding; bh=eVWhb+u145s36rKWpno8O/fFqCSOJzsuC4fLcdxiQgg=; b=O3ql/jPFQ/i6HH/zwX3YZLAmWKrgmkzGWK2TYqPJrcr76JLUGYjYm5PSQkbM1BNzXi YQse6vgnejl4OBiRLA5rU0MLSm1uEz4IKWp7nIRttKWWjPRKSNX8dKWLFkXQg9x0Wa+O s9XQjdbOvlvjI3d1so9g08572PqavkI8m/vDvMiCCTR58kAk716v44ixu+3bM2o8ZKTz iEZnBXUoB7Rh8RUGQYQmIPjtFnr+ywb8rARwZAYg7Z3IB2N2rTnQFKORlgIsBMLNISKF KqAwezj587EAo8RaSu44O9lIevIw5Hie4XEiUWXoG6Laiwrg/FTe45qBcjARtgujApLq LLsA== X-Gm-Message-State: AKaTC00iRWjbTIdEoObY9EeZOHnoMhwYutfaGOisINXGxCXY8KXdGf7CsFTk5jfmLlsQJw== X-Received: by 10.84.215.158 with SMTP id l30mr104487995pli.132.1480754586742; Sat, 03 Dec 2016 00:43:06 -0800 (PST) Received: from desktop ([103.232.159.187]) by smtp.gmail.com with ESMTPSA id o68sm13026712pfb.42.2016.12.03.00.43.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Dec 2016 00:43:05 -0800 (PST) Sender: Jan Newmarch Message-ID: <1480754578.4443.186.camel@newmarch.name> From: Jan Newmarch To: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Date: Sat, 03 Dec 2016 19:42:58 +1100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jan Newmarch Subject: [core] Comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 08:43:12 -0000 Hi Not sure if I am following protocol posting to core@ietf.org. Previous email to draft-ietf-core-resource-directory@ietf.org had no response. I haven't been able to track down many past discussions on this draft, it may be that my comments have been answered already, if so, apologies. re: 5.1 Simple publishing to an RD This says that POST can be made to ./well-known/core on the RD. It doesn't say if the required parameter 'ep' in 6.3 is required for this method of registration. Why does the RD have to support filtering? This is optional for other CoAP agents. It does add a burden to the RD that is not required for other agents. Why does an endpoint sending a POST request to an endpoint have to have an empty body? Couldn't it include resources? Then the RD wouldn't need to make a request to the server. Could you say "If the body is empty then it triggers a GET request. If it has a non-empty body then these are the resources being registered." Section 5.1 POSTS to an RD. POST would normally expect a return value which is the uri of the newly created resource. This return value is not mentioned in  draft-ietf-core-resource-directory-09. Is it the same value that would be returned by a 6.3 Registration such as  Res: 2.01 Created    Location: /rd/4521 If not, then what? if yes, then presumably the RD has created a new resource with empty values (possibly with an endpoint name?). 5.1 states that later the RD will query the endpoint with a GET, and then presumably the value stored on the RD will be updated. Could the endpoint have in the meantime done a 6.4 update based on the uri it got back? What happens in such cases? Before the RD has updated the value in its directory, can a 3rd party client have queried the RD lookup service and got back some info about this endpoint? If so, what will it get? It can't get a CoAP entry showing the uri path to the resources on the endpoint because it doesn't know them yet. Most of these issues go away if the initial 5.1 POST is allowed to be non-empty. In section 6.3 POST is used both for new entries and for updating existing ones. I know that REST is not prescriptive on this, but I am of the camp that says updates should be done by PUT and that POST is reserved for new resources only. You don't give PUT as an option. It seems to have been in version 5, but vanished later and the CHANGES don't mention this change. In section 6 it uses 'rd' for registering and updating resources using POST, but a separate resource 'rd-lookup' to GET resources. Normal REST usage would use GET on 'rd'. Why is there a separate resource? It is not clear why it is mandatory that an endpoint have a name. I can see it is often convenient, but mandatory? Regards Jan -- Dr Jan Newmarch, Head of Higher Education (ICT) @ Box Hill, Adjunct Professor @ University of Canberra P 61 3 9286 9971 M +61 4 0117 0509 F 61 3 9286 9100 W www.boxhill.edu.au W jan.newmarch.name E j.newmarch@boxhill.edu.au E jan@newmarch.name From nobody Sun Dec 4 23:13:14 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AC41296BE; Sun, 4 Dec 2016 23:13:12 -0800 (PST) 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 8B8-o7sgcn5R; Sun, 4 Dec 2016 23:13:10 -0800 (PST) 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 99ED5129450; Sun, 4 Dec 2016 23:13:08 -0800 (PST) X-AuditID: c1b4fb3a-d644398000007918-d7-584513828cf9 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id DE.9F.31000.28315485; Mon, 5 Dec 2016 08:13:07 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Mon, 5 Dec 2016 08:13:06 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" Thread-Topic: Comments on draft-ietf-core-object-security-06 Thread-Index: AQHSTMKRsYUSb6rTBE+1HiU83i+oUaD1cmKAgAOCIwA= Date: Mon, 5 Dec 2016 07:13:06 +0000 Message-ID: References: <083101d24ad0$3b071aa0$b1154fe0$@augustcellars.com> <044101d24d0e$57fbdb10$07f39130$@augustcellars.com> In-Reply-To: <044101d24d0e$57fbdb10$07f39130$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <0F07632F52C72C48A6BAAC2845941DB7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7t26zsGuEwbltXBb73q5ntpj27wyL xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsEroy2pllMBc+8K07M3czYwPjGs4uR k0NCwETi4e5/TF2MXBxCAusYJV613GKHcBYzSmxq62IDqWITcJF40PAIrEpEoIlR4vHcPmaQ BLOAssTx2YdZQWxhAWuJzmkgoziBimwkln45zgJhW0m8uXASrJ5FQEXi2veDYHFeAQuJg6ef sEBsW8IoseTRJbBBnAIOErvbr4A1MAqISXw/tYYJYpm4xK0n85kg7haQWLLnPDOELSrx8vE/ sF5RAT2J2VMa2CHiShKNS54AxTmAejUl1u/ShxhjLXHw4RN2CFtRYkr3Q3aIewQlTs58wjKB UXwWkm2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECY+/glt9W OxgPPnc8xCjAwajEw1ug7xIhxJpYVlyZe4hRgoNZSYR3FZ9rhBBvSmJlVWpRfnxRaU5q8SFG aQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2M8s//5Ks7/nrOs0rZRT5Q9Fuy+d3n6su3 7Vp8Ivu3YffejoZrTxjloo+YZ6ZKaNcfeSGlIPLnppiXQniuSaKj6KrZJ5f4CJf/j1qqaHPt QtZtNTan1NftEU61r4RvPqgpMDgqtejw93bFgjf+ItJqHLHl7S1fZ3NZLFG/NKF6shTfkyYD 7l1KLMUZiYZazEXFiQDN1G7ouQIAAA== Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Comments on draft-ietf-core-object-security-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 07:13:12 -0000 DQoNCk9uIDIwMTYtMTItMDMgMDM6MzgsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDAyLCAyMDE2IDEyOjMxIEFNDQo+PiBUbzogSmlt IFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGRyYWZ0LWlldGYtY29yZS1vYmplY3Qt DQo+PiBzZWN1cml0eUBpZXRmLm9yZw0KPj4gQ2M6IGNvcmVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6 IFJlOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTA2DQo+PiAN Cj4+DQo+PiA+QXBwZW5kaXggQyAtIEkgYW0gaGF2aW5nIGEgaGFyZCB0aW1lIHdpdGggdGhlIGZp cnN0IHBhcmFncmFwaCBoZXJlLiAgSQ0KPj4gPmRvIG5vdCBiZWxpZXZlIHRoYXQgeW91IGhhdmUg Y29ycmVjdGx5IGNoYXJhY3Rlcml6ZWQgdGhlIHByb2JsZW0uICBUaGUNCj4+ID5yZWFzb24gdGhh dCB5b3UgY2Fubm90IHVzZSBPU0NPQVAgZm9yIHRoaXMgaGFzIG1vcmUgdG8gZG8gd2l0aCBob3cg eW91DQo+PiA+ZGVjaWRlZCB3aGljaCByZWNvcmRzIGluIHRoZSBoZWFkZXIgdG8gYXV0aGVudGlj YXRlIHJhdGhlciB0aGFuIHRoZQ0KPj4gPmZhY3QgdGhhdCB0aGlzIGlzIGdvaW5nIHRvIGJlIGRp c3RyaWJ1dGVkIHRvIG11bHRpcGxlIHJlY2lwaWVudHMuDQo+PiANCj4+IFRoZSBpbnRlbmRlZCBs b2dpYyBpcyB0aGUgZm9sbG93aW5nOg0KPj4gDQo+PiBUaGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRz IGRyYWZ0DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFydGtlLWNvcmUt ZTJlLXNlY3VyaXR5LXJlcXMNCj4+Y3VycmVudGx5DQo+PiBkZXNjcmliZXMgdGhyZWUgdXNlIGNh c2VzIOKAnHByb3h5IGZvcndhcmRpbmfigJ0sIOKAnHByb3h5IGNhY2hpbmfigJ0gYW5kDQo+PuKA nHB1Ymxpc2gtDQo+PiBzdWJzY3JpYmXigJ0uIFRoZSBzb2x1dGlvbnMgdG8gdGhlc2UgcmVxdWly ZW1lbnRzIHByb3RlY3QgYXMgbXVjaCBhcyBpcw0KPj5wb3NzaWJsZSwNCj4+IHdoaWxlIHN0aWxs IGFsbG93aW5nIHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSB1c2UgY2FzZS4NCj4+IE9TQ09BUCBh ZGRyZXNzZXMgdGhlICJwcm94eSBmb3J3YXJkaW5n4oCdIHVzZSBjYXNlLCB3aGljaCBpcyBhIGJh c2ljIENvQVANCj4+IHJlcXVlc3QtcmVzcG9uc2Ugd2l0aCBvcHRpb25hbCBmb3J3YXJkIHByb3h5 IGZ1bmN0aW9uYWxpdHkuIFRoaXMgaXMgYQ0KPj51c2UgY2FzZQ0KPj4gd2UgaGF2ZSBiZWVuIHJl cXVlc3RlZCB0byBzdXBwb3J0LCBhbmQgaXQgaXMgYW4gaW50ZXJlc3RpbmcgY2FzZSBhbHNvDQo+ PmJlY2F1c2UNCj4+IGVzc2VudGlhbGx5IGFsbCBvcHRpb25zIGFuZCBoZWFkZXJzIHRoYXQgYXJl IHBhc3NlZCBlbmQtdG8tZW5kIGluIGENCj4+Q29BUCByZXF1ZXN0DQo+PiBhbmQgcmVzcG9uc2Ug Y2FuIGJlIHByb3RlY3RlZCwgcmVzcG9uc2UgY2FuIGJlIGJvdW5kIHRvIGEgcmVxdWVzdCwgYW5k DQo+PnNvbWUNCj4+IG90aGVyIHNlY3VyaXR5IGZlYXR1cmVzIGNhbiBiZSBzdXBwb3J0ZWQuDQo+ PiANCj4+IE9TQ09OIGFkZHJlc3NlcyBvdGhlciB1c2UgY2FzZXMgd2l0aCBhIGNvbW1vbiBzb2x1 dGlvbiwgaW5jbHVkaW5nIHRoZQ0KPj50d28NCj4+IHJlbWFpbmluZyB1c2UgY2FzZXMgbWVudGlv bmVkIGFib3ZlLiBJbiB0aGVzZSBjYXNlcyBsZXNzIG9mIHRoZSByZWNvcmRzDQo+PmNhbiBiZQ0K Pj4gcHJvdGVjdGVkLCBlLmcuIGJlY2F1c2UgYSBzaW5nbGUgcmVzcG9uc2Ugc2hvdWxkIGJlIG1l YW5pbmdmdWwgdG8NCj4+bXVsdGlwbGUNCj4+IHJlcXVlc3RzLiBUaGlzIHNvbHV0aW9uIHRodXMg dGFyZ2V0cyBhIGZvcm1hdCB3aGVyZSBtdWx0aXBsZSB1c2UgY2FzZXMNCj4+Y2FuIGJlDQo+PiBz dXBwb3J0ZWQgcmF0aGVyIHRoYW4gb3B0aW1pc2luZyBzZWN1cml0eSBmb3IgYSBwYXJ0aWN1bGFy IHVzZSBjYXNlLg0KPj4gDQo+PiBJIHdpbGwgbWFrZSBhbiBpc3N1ZSB0byBjbGFyaWZ5IHRoaXMu DQo+DQo+SXQgaXMgbm90IHRoZSBsZWFzdCBiaXQgY2xlYXIgdG8gbWUgdGhhdCBwdWJsaXNoLXN1 YnNjcmliZSBjYXNlIGNhbm5vdCBiZQ0KPmRvbmUgd2l0aCBPU0NPQVAuICBUaGUgcHJveHkgY2Fj aGluZyBwcm9ibGVtIGlzIG1vcmUgZGlmZmljdWx0LCBidXQgaXMNCj5ub3Qgc29sdmVkIGJ5IE9T Q09OIGluIGEgd2F5IHRoYXQgaXMgbm90IGFsc28gc29sdmVkIGluIHRoZSBPU0NPQVAgY2FzZQ0K PmFzIGZhciBhcyBJIGNhbiB0ZWxsLg0KDQpJbiBPU0NPQVAsIHRoZSByZXNwb25zZSBpcyBib3Vu ZCB0byB0aGUgcmVxdWVzdCBieSBpbmNsdWRpbmcgdGhlDQp0cmFuc2FjdGlvbiBpZGVudGlmaWVy IChjaWQsIHNlbmRlciBJRCwgc2VxdWVuY2UgbnVtYmVyKSBvZiB0aGUgcmVxdWVzdCBpbg0KdGhl IGV4dGVybmFsX2FhZCBvZiB0aGUgcmVzcG9uc2UuIFdpdGggdGhpcyB0aGUgY2xpZW50IGlzIGFi bGUgdG8gdmVyaWZ5DQp0aGF0IHRoZSBzZXJ2ZXIgaGFzIHJlY2VpdmVkIHRoZSByZXF1ZXN0IGFu ZCB0aGF0IHRoaXMgbWVzc2FnZSBpcyBhDQpyZXNwb25zZSBvZiB0aGF0IHJlcXVlc3QuIFRoaXMg Y29uc3RydWN0aW9uIGFsc28gd29ya3MgZm9yIG11bHRpcGxlDQpyZXNwb25zZXMgdG8gYSBnaXZl biByZXF1ZXN0IHN1Y2ggYXMgQ29BUCBvYnNlcnZlIChSRkM3NjQxKSBhbmQgZ3JvdXANCmNvbW11 bmljYXRpb24gZm9yIENvQVAgKFJGQzczOTApLiBEaWZmZXJlbnQgb2JzZXJ2ZSBub3RpZmljYXRp b25zIGNhbiBiZQ0KZGlzdGluZ3Vpc2hlZCBieSBkaWZmZXJlbnQgc2VxdWVuY2UgbnVtYmVycyBv ZiBzZXJ2ZXIsIGFuZCBkaWZmZXJlbnQNCnVuaWNhc3QgcmVzcG9uc2VzIHRvIGEgbXVsdGljYXN0 IHJlcXVlc3QgY2FuIGJlIGRpc3Rpbmd1aXNoZWQgYnkgdGhlDQpyZXNwb25kaW5nIG5vZGXigJlz IChzZW5kZXIpIElELg0KDQpIb3dldmVyLCB3aXRoIGNhY2hpbmcgYW5kIHB1Ymxpc2gtc3Vic2Ny aWJlIGEgZ2l2ZW4gcmVzcG9uc2UgaXMgdXNlZCBmb3INCm11bHRpcGxlIHJlcXVlc3RzLCBzbyB0 aGUgcmVzcG9uc2UgY2Fubm90IGJlIGJvdW5kIHRvIGEgcGFydGljdWxhcg0KcmVxdWVzdC4gTW9y ZW92ZXIsIGZvciBjYWNoaW5nIGFuZCBwdWJsaXNoLXN1YnNjcmliZSwgbGVzcyBDb0FQIG9wdGlv bnMNCmFuZCBoZWFkZXJzIGNhbiBiZSBwcm90ZWN0ZWQuIEUuZy4gdGhlIHB1Ymxpc2hlciBjYW4g dXBkYXRlIGEgdG9waWMgd2l0aCBhDQpQVVQsIHdoaWNoIGlzIHByb3ZpZGVkIHdpdGggYSBHRVQg cmVzcG9uc2UgdG8gdGhlIHN1YnNjcmliZXIsIHNvDQp0aGUgQ29BUCBDb2RlIGNhbm5vdCBiZSBp bnRlZ3JpdHkgcHJvdGVjdGVkIGJldHdlZW4gcHVibGlzaGVyIGFuZA0Kc3Vic2NyaWJlci4gTW9y ZSBkZXRhaWxzIGFib3V0IHdoaWNoIG9wdGlvbnMgYW5kIGhlYWRlciBhcmUgcHJvdGVjdGVkIGlu DQpjYWNoaW5nIGFuZCBwdWItc3ViIGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnQ6DQoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJ0a2UtY29yZS1lMmUtc2VjdXJpdHktcmVx cw0KDQpUaHVzIHRoZSBzZXQgb2YgaGVhZGVycyBhbmQgb3B0aW9ucywgYW5kIGhvdyByZXNwb25z ZSBpcyBib3VuZCB0byByZXF1ZXN0DQphcyBkZWZpbmVkIGluIE9TQ09BUCBkb2VzIG5vdCBhcHBs eSB0byBwdWItc3ViLiBCdXQgc2ltaWxhciBjb25zdHJ1Y3Rpb25zDQphcmUgcG9zc2libGUsIG9y IGVsc2UganVzdCBlc3NlbnRpYWxseSBwcm90ZWN0IHRoZSBDb0FQIHBheWxvYWQgYXMgd2l0aA0K T1NDT04uIA0KDQpXZSBkaWQgbm90IHdyaXRlIGFueXRoaW5nIG9mIHRoZSB1bmRlcmx5aW5nIGNv bnN0cnVjdGlvbiBpbiB0aGUgZHJhZnQsDQptYXliZSB3ZSBzaG91bGQ/DQoNCg0KPg0KPj4gDQo+ PiA+DQo+PiA+QXBwZW5kaXggQyAtIFRhbGtpbmcgYWJvdXQgdGhlICJ1bnByb3RlY3RlZCIgYW5k IHRoZSAicHJvdGVjdGVkIiBDb0FQDQo+PiA+bWVzc2FnZSBpcyB2ZXJ5IGNvbmZ1c2luZyBlc3Bl Y2lhbGx5IHNpbmNlIENPU0UgaGFzIHByb3RlY3RlZCBhbmQNCj4+ID51bnByb3RlY3RlZCBvYmpl Y3RzIGFzIHdlbGwuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdXNlIGEgZGlmZmVyZW50DQo+PiA+ dGVybWlub2xvZ3kgc3VjaCBhcyAidGhlIG9yaWdpbmFsIG1lc3NhZ2UiIGFuZCAidGhlIHJlc3Vs dGluZyBtZXNzYWdlIi4NCj4+IA0KPj4gVGhpcyB0ZXJtaW5vbG9neSBpcyBkZWZpbmVkIGluIHRo ZSBib2R5IG9mIHRoZSBkcmFmdC4gKEZXSVcgdGhlDQo+PnRlcm1pbm9sb2d5DQo+PiBwcm9iYWJs eSBwcmVkYXRlcyBDT1NFLikgSWYgd2UgYWx3YXlzIHF1YWxpZnkgd2l0aA0KPj51bnByb3RlY3Rl ZC91bnByb3RlY3RlZA0KPj4gQ29BUCwgcHJvdGVjdGVkL3VucHJvdGVjdGVkIENPU0UgaGVhZGVy LCBJIHN1cHBvc2UgdGhlcmUgd291bGQgbGVzcyBvZg0KPj5hIHJpc2sNCj4+IGZvciBtaXN1bmRl cnN0YW5kaW5nPw0KPg0KPkRvaW5nIHRoZSBmdWxsIHF1YWxpZmljYXRpb24gd291bGQgYmUgbmlj ZS4gIEkgd2lsbCBhZG1pdCB0aGF0IEkgcHJvYmFibHkNCj5taXNzZWQgdGhhdCBzaW5jZSBJIHN0 YXJ0ZWQgaGFsZiB3YXkgZG93biB0aGUgZG9jdW1lbnQuDQoNCk9LLCB3ZeKAmWxsIG1ha2Ugc3Vy ZSBvZiB0aGF0Lg0KDQo+DQo+PiANCj4+ID4NCj4+ID5BcHBlbmRpeCBDIC0gSSBkbyBub3QgdW5k ZXJzdGFuZCB3aGF0IHRoaXMgc2VudGVuY2UgbWVhbnMuICIgT1NDT04NCj4+ID5zaGFsbCBub3Qg YmUgdXNlZCBpbiBjYXNlcyB3aGljaCByZXF1aXJlIGEgc2VjdXJlIGJpbmRpbmcgYmV0d2Vlbg0K Pj4gPnJlcXVlc3QgYW5kIHJlc3BvbnNlLiIgIElzIGl0IGludGVuZGVkIHRvIHNheSB0aGF0IHRo ZSB1c2Ugb2YgYQ0KPj4gPnRyYW5zYWN0aW9uIGlkZW50aWZpZXIgaW4gdGhlIENPU0Ugd3JhcHBl cnMgZm9yIHRoZSByZXF1ZXN0IGFuZA0KPj4gPnJlc3BvbnNlIGlzIG5vdCBwZXJtaXR0ZWQ/ICBU aGVyZSBhcmUgYSBsb3Qgb2Ygd2F5cyB0byBkbyB0aGlzIHRoYXQgZG8NCj4+ID5ub3QgcmVseSBv biBDb0FQLg0KPj4gDQo+PiBBcyBtZW50aW9uZWQsIHRoaXMgZm9ybWF0IGlzIGFkZHJlc3Npbmcg dXNlIGNhc2VzIHdoaWNoIGRvZXMgbm90IGJpbmQNCj4+cmVzcG9uc2UNCj4+IHRvIHJlcXVlc3Qu IEl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIHdyYXBwaW5nIG9mIGEgbWVzc2FnZSBleGNoYW5n ZQ0KPj5pbiBDT1NFDQo+PiB3aGljaCBoYXMgZGlmZmVyZW50IGZlYXR1cmVzLCBidXQgdGhhdCB3 YXMgbm90IHRoZSBpbnRlbnRpb24gaGVyZS4NCj4NCj5UaGlzIGlzIG5vdCBtYWtpbmcgaXQgYW55 IGNsZWFyZXIgdG8gbWUuDQoNCkRvZXMgdGhlIHRleHQgYWJvdmUgbWFrZSB0aGluZ3MgbW9yZSBj bGVhcj8NCg0KPiANCj4NCj4+IA0KPj4gDQo+PiA+DQo+PiA+QXBwZW5kaXggQyAtIEl0IGlzIG5v dCBjbGVhciBpZiB0aGUgQ29udGVudC1Gb3JtYXQgc2hvdWxkIGJlIHNldCBpZg0KPj4gPnRoZXJl IHdhcyBubyBDb250ZW50LUZvcm1hdCBpbiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCj4+IA0KPj4g SXQgc2hvdWxkLCB0byBiZSBjbGFyaWZpZWQuDQo+PiANCj4+ID4NCj4+ID5BcHBlbmRpeCBDLjEg LSBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBzZWN0aW9uIGlzIHRyeWluZyB0bw0KPj4g PmFjY29tcGxpc2guICBJdCBhcHBlYXJzIHRvIGJlIGRvaW5nIHRocmVlIGRpZmZlcmVudCB0aGlu Z3MsIHNvbWUgb2YNCj4+ID53aGljaCBzaG91bGQgYmUgaW4gQXBwZW5kaXggQywgc29tZSBvZiB3 aGljaCBzaG91bGQgYmUgc3RhbmRhbG9uZSBhbmQNCj4+ID5zb21lIG9mIHdoaWNoIGxvb2tzIGxp a2UgaXQgc2hvdWxkIGJlDQo+PiANCj4+IEl0IGlzIGFuIGludHJvZHVjdGlvbiB0byBzZWN0aW9u cyBDLjItQy41LiBXZSBzaG91bGQgY2xhcmlmeSB0aGF0Lg0KPg0KPk1ha2luZyBDLjItQy41IGJl IHN1YiBzZWN0aW9ucyB3b3VsZCBwcm9iYWJseSBhbHNvIGhlbHANCg0KT0suDQoNCg0KR8O2cmFu DQoNCg0KPg0KPkppbQ0KPg0KPj4gDQo+PiA+DQo+PiA+QXBwZW5kaXggQy41IC0gVGhlcmUgc2hv dWxkIGJlIGEgZGlzY3Vzc2lvbiByZWxhdGVkIHRoaXMgdGhpcyBhYm91dCB0aGUNCj4+ID5kaWZm ZXJlbnQgc2VjdXJpdHkgcHJvcGVydGllcyB0aGF0IGFyZSB0byBiZSBmb3VuZCBmb3IgRW5jcnlw dCtTaWduKE0pDQo+PiA+dnMgU2lnbihFbmNyeXB0KE0pKS4NCj4+IA0KPj4gVGhlcmUgYXJlIHBs YW5zIHRvIHdyaXRlIG1vcmUgYWJvdXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgU0VBUywN Cj4+cHJvYmFibHkgaW4NCj4+IGEgZGlmZmVyZW50IGRvY3VtZW50Lg0KPj4gDQo+PiA+DQo+PiA+ QXBwZW5kaXggQiAtIFRoZXNlIGFyZSByZWFsbHkgZXhhbXBsZSBtZXNzYWdlIGZsb3dzIHJhdGhl ciB0aGFuDQo+PiA+ZXhhbXBsZXMgb2YgT1NDT1AgbWVzc2FnZXMuICBUaGlzIHNob3VsZCBiZSBt YWRlIGNsZWFyZXIgaW4gdGhlIHNlY3Rpb24NCj4+ID50aXRsZQ0KPj4gDQo+PiBPSywgSeKAmWxs IG1ha2UgdGhhdCB1cGRhdGUgaW4gLTAxLg0KPj4gDQo+PiA+DQo+PiA+QXBwZW5kaXggQi4xIC0g SG93IGRvZXMgb25lIHNlY3VyZWx5IGJpbmQgdGhlIHJlcXVlc3QgYW5kIHRoZSByZXNwb25zZT8N Cj4+ID5JIGFtIG5vdCBzZWVpbmcgYW55dGhpbmcgZnJvbSB0aGlzIGV4YW1wbGUgdGhhdCB3aWxs IGRvIHNvLg0KPj4gDQo+PiBObywgaXQgaXMgbm90IHZpc2libGUgZnJvbSB0aGUgbWVzc2FnZSBm b3JtYXQuIFNlZSBzZWN0aW9uIDYuMSAidGhlDQo+PnJlc3BvbnNlIGlzDQo+PiB2ZXJpZmllZCB0 byBtYXRjaCBhIHByaW9yIHJlcXVlc3QsIGJ5IGluY2x1ZGluZyB0aGUgdW5pcXVlIHRyYW5zYWN0 aW9uDQo+PmlkZW50aWZpZXINCj4+IG9mIHRoZSByZXF1ZXN0IGluIHRoZSBBZGRpdGlvbmFsIEF1 dGhlbnRpY2F0ZWQgRGF0YSBvZiB0aGUgcmVzcG9uc2UNCj4+bWVzc2FnZS4iDQo+PiANCj4+IEfD tnJhbg0KPj4gDQo+DQo+DQoNCg== From nobody Sun Dec 4 23:47:50 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B891293EE; Sun, 4 Dec 2016 23:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 QGxUG-021WOQ; Sun, 4 Dec 2016 23:47:46 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3BB1293E8; Sun, 4 Dec 2016 23:47:45 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Dec 2016 00:07:15 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <083101d24ad0$3b071aa0$b1154fe0$@augustcellars.com> <044101d24d0e$57fbdb10$07f39130$@augustcellars.com> In-Reply-To: Date: Sun, 4 Dec 2016 23:47:29 -0800 Message-ID: <05d001d24ecb$d60587e0$821097a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKaVnhZja3Zi1ELigv8nmadx6425QH62YMNAmN/aLECumduK58wJFNQ Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: Re: [core] Comments on draft-ietf-core-object-security-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 07:47:48 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Sunday, December 04, 2016 11:13 PM > To: Jim Schaad ; draft-ietf-core-object- > security@ietf.org > Cc: core@ietf.org > Subject: Re: Comments on draft-ietf-core-object-security-06 >=20 >=20 >=20 > On 2016-12-03 03:38, "Jim Schaad" wrote: >=20 > > > > > >> -----Original Message----- > >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> Sent: Friday, December 02, 2016 12:31 AM > >> To: Jim Schaad ; draft-ietf-core-object- > >> security@ietf.org > >> Cc: core@ietf.org > >> Subject: Re: Comments on draft-ietf-core-object-security-06 > >> > >> > >> >Appendix C - I am having a hard time with the first paragraph = here. > >> >I do not believe that you have correctly characterized the = problem. > >> >The reason that you cannot use OSCOAP for this has more to do with > >> >how you decided which records in the header to authenticate rather > >> >than the fact that this is going to be distributed to multiple = recipients. > >> > >> The intended logic is the following: > >> > >> The security requirements draft > >> https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs > >>currently > >> describes three use cases =E2=80=9Cproxy forwarding=E2=80=9D, = =E2=80=9Cproxy caching=E2=80=9D and > >>=E2=80=9Cpublish- > >> subscribe=E2=80=9D. The solutions to these requirements protect as = much as is > >>possible, while still allowing the functionality of the use case. > >> OSCOAP addresses the "proxy forwarding=E2=80=9D use case, which is = a basic > >>CoAP request-response with optional forward proxy functionality. = This > >>is a use case we have been requested to support, and it is an > >>interesting case also because essentially all options and headers > >>that are passed end-to-end in a CoAP request and response can be > >>protected, response can be bound to a request, and some other > >>security features can be supported. > >> > >> OSCON addresses other use cases with a common solution, including = the > >>two remaining use cases mentioned above. In these cases less of the > >>records can be protected, e.g. because a single response should be > >>meaningful to multiple requests. This solution thus targets a = format > >>where multiple use cases can be supported rather than optimising > >>security for a particular use case. > >> > >> I will make an issue to clarify this. > > > >It is not the least bit clear to me that publish-subscribe case = cannot > >be done with OSCOAP. The proxy caching problem is more difficult, = but > >is not solved by OSCON in a way that is not also solved in the OSCOAP > >case as far as I can tell. >=20 > In OSCOAP, the response is bound to the request by including the = transaction > identifier (cid, sender ID, sequence number) of the request in the = external_aad > of the response. With this the client is able to verify that the = server has received > the request and that this message is a response of that request. This > construction also works for multiple responses to a given request such = as CoAP > observe (RFC7641) and group communication for CoAP (RFC7390). = Different > observe notifications can be distinguished by different sequence = numbers of > server, and different unicast responses to a multicast request can be > distinguished by the responding node=E2=80=99s (sender) ID. >=20 > However, with caching and publish-subscribe a given response is used = for > multiple requests, so the response cannot be bound to a particular = request. > Moreover, for caching and publish-subscribe, less CoAP options and = headers can > be protected. E.g. the publisher can update a topic with a PUT, which = is provided > with a GET response to the subscriber, so the CoAP Code cannot be = integrity > protected between publisher and subscriber. More details about which = options > and header are protected in caching and pub-sub in the requirements = draft: >=20 > https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs >=20 > Thus the set of headers and options, and how response is bound to = request as > defined in OSCOAP does not apply to pub-sub. But similar constructions = are > possible, or else just essentially protect the CoAP payload as with = OSCON. >=20 > We did not write anything of the underlying construction in the draft, = maybe we > should? I will send a separate message on some thoughts I had over the weekend = at some point soon. >=20 >=20 > > > >> > > > >> > >> > > >> >Appendix C - I do not understand what this sentence means. " OSCON > >> >shall not be used in cases which require a secure binding between > >> >request and response." Is it intended to say that the use of a > >> >transaction identifier in the COSE wrappers for the request and > >> >response is not permitted? There are a lot of ways to do this = that > >> >do not rely on CoAP. > >> > >> As mentioned, this format is addressing use cases which does not = bind > >>response to request. It is possible to define a wrapping of a = message > >>exchange in COSE which has different features, but that was not the > >>intention here. > > > >This is not making it any clearer to me. >=20 > Does the text above make things more clear? As stated above - no. Jim >=20 >=20 > G=C3=B6ran >=20 >=20 From nobody Mon Dec 5 01:01:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5679C127078; Mon, 5 Dec 2016 01:01:02 -0800 (PST) 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEXwqWtXyidk; Mon, 5 Dec 2016 01:01:01 -0800 (PST) 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 CCCDA12940F; Mon, 5 Dec 2016 00:53:48 -0800 (PST) X-AuditID: c1b4fb3a-d644398000007918-dc-58452b1a6650 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 2A.76.31000.A1B25485; Mon, 5 Dec 2016 09:53:46 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Mon, 5 Dec 2016 09:52:30 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" Thread-Topic: Comments on draft-ietf-core-object-security-00 Thread-Index: AdJLiTeDKEyfsMgGSoOfR4rDJInqcQBFsi+AABfTWIAAdWaaAA== Date: Mon, 5 Dec 2016 08:52:30 +0000 Message-ID: References: <026201d24c15$eebe5180$cc3af480$@augustcellars.com> <043e01d24d07$b13f9650$13bec2f0$@augustcellars.com> In-Reply-To: <043e01d24d07$b13f9650$13bec2f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 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+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7ja6UtmuEwcktVhb73q5ntpj27wyL xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsErowrTRwFP4wrpkxdydzAeMaoi5GT Q0LAROLsmbcsXYxcHEIC6xgllr7oYoZwFjNKHFz8iAWkik3AReJBwyMmkISIQBOjxOO5fcwg CWYBZYnjsw+zgtjCAtYSU9u/M4LYIgI2Eh0TfwPVcADZThJPO4RBwiwCKhIPb11iAgnzClhI 9Jwthdi1hFHi6r4v7CA1nAIOEh/+r2ECsRkFxCS+n4KwmQXEJW49mc8EcbWAxJI955khbFGJ l4//gZ0gKqAnMXtKAztEXEli0e3PYLuYBTQl1u/ShxhjLfH6YR8bhK0oMaX7IVg5r4CgxMmZ T1gmMIrPQrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYNQd 3PLbagfjweeOhxgFOBiVeHgL9F0ihFgTy4orcw8xSnAwK4nwmqm5RgjxpiRWVqUW5ccXleak Fh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAGOiatzbtsqZaEhvjsz1T92x8XGl1 dd2fZr2tHdNFNwvsXmxgukql5VZPXeYjuRuznrcUO8vNcHmdPDPE5LvLZ0HbGInwm0aT/hWt 2c5wvulhqfgfhvqPWt3XF84UfX/vdpnGQU6L5WcfX+RPrnipu2j7L4Gf916aMuYfWrXqyla2 gO6AuortDUosxRmJhlrMRcWJANJpW6W2AgAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Comments on draft-ietf-core-object-security-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 09:01:02 -0000 DQoNCk9uIDIwMTYtMTItMDMgMDI6NTAsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDAyLCAyMDE2IDU6MjkgQU0NCj4+IFRvOiBKaW0g U2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC0N Cj4+IHNlY3VyaXR5QGlldGYub3JnDQo+PiBDYzogY29yZUBpZXRmLm9yZw0KPj4gU3ViamVjdDog UmU6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDANCj4+IA0K Pj4gVGhlIGNvbW1lbnQgd2UgZGlkbuKAmXQgcmVzcG9uZCB0byBpbiB0aGUgcHJldmlvdXMgbWFp bDoNCj4+IA0KPj4gT24gMjAxNi0xMi0wMSAyMjowMCwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3Vz dGNlbGxhcnMuY29tPiB3cm90ZToNCj4+IA0KPj4gPlNlY3Rpb24gMyAtIEkgbGlrZSB0aGUgZmFj dCB0aGF0IHRoZSBzZWN1cml0eSBjb250ZXh0IGlzIGJlaW5nIGRlZmluZWQsDQo+PiA+aG93ZXZl ciBJIHF1ZXN0aW9uIHRoZSB3aXNkb20gb2YgaW5jbHVkaW5nIHRoZSBzZWN0aW9ucyBvbiBob3cg dG8NCj4+ID5kZXJpdmUgYSBjb250ZXh0IGZyb20gYSBzaGFyZWQgc2VjcmV0IGF0IHRoaXMgcG9p bnQuICBJIHRoaW5rIGl0IHdvdWxkDQo+PiA+bWFrZSBtb3JlIHNlbnNlIHRvIHB1dCB0aGlzIGlu dG8gdGhlIEVESE9DIGRvY3VtZW50LCBhbmQgaWYgeW91IGRvIG5vdA0KPj4gPmRvIHRoYXQgdGhl biB0byBhdCBsZWFzdCBtb3ZlIHRoaXMgaW50byBhbiBhcHBlbmRpeC4gIEkgZG8gbm90IGJlbGll dmUNCj4+ID50aGF0IHRoaXMgaXMvc2hvdWxkIGJlIHRoZSBvbmx5IG1ldGhvZCB0byBwb3B1bGF0 ZSBhIGNvbnRleHQuICBJIHdvdWxkDQo+PiA+aG9wZSB0aGF0IGEgbWV0aG9kIG9mIGRvaW5nIHNv IGZyb20gYSBDV1Qgd2lsbCBiZSBkZWZpbmVkIGFzIHRoYXQgbWF5DQo+PiA+aGF2ZSB0aGUgYWR2 YW50YWdlIG9mIGdldHRpbmcgbW9yZSBjb250cm9sbGVkIHJhbmRvbSBudW1iZXJzLiAgRnJvbSBh DQo+PiA+c2VjdXJpdHkgYW5hbHlzaXMgcG9pbnQgb2YgdmlldywgdGhlcmUgaXMgbm8gZGlmZmVy ZW5jZSBiZXR3ZWVuIGdldCB0aGUNCj4+ID5zaGFyZWQgc2VjcmV0IHVzZWQgaGVyZSBvciB0aGUg YWN0dWFsIGtleXMgZnJvbSBhIHRoaXJkIHBhcnR5LiAgVGhlcmUNCj4+ID5pcyBhIGRpZmZlcmVu Y2UgaWYgRURIT0MgaXMgdXNlZC4NCj4+IA0KPj4gSW4gYSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRo ZSBkcmFmdCB3ZSBkaWQgZXhhY3RseSB0aGF0IC0gZGVmaW5lIHRoZQ0KPj5zZWN1cml0eQ0KPj4g Y29udGV4dCBidXQgbm90IGhvdyB0byBhcnJpdmUgYXQgaXQuIFRoaXMgcmFpc2VkIHNvbWUgcXVl c3Rpb25zLCBhbmQgd2UNCj4+ZGVjaWRlZA0KPj4gdGhhdCBoYXZpbmcgZXNzZW50aWFsbHkgYSBz aGFyZWQgYmFzZSBrZXkgLyBtYXN0ZXIgc2VjcmV0IHNlZW1lZCB0byBiZQ0KPj5hIG11Y2gNCj4+ IG1vcmUgbmF0dXJhbCBzdGFydGluZyBwb2ludCBmb3IgT1NDT0FQLCBhbmQgdGhlc2UgcGFyYW1l dGVycyBjb3VsZCBiZQ0KPj4gb2J0YWluZWQgZnJvbSBFREhPQywgQUNFLCBUTFMsIG9yIHdoYXRl dmVyLiBTaW5jZSBFREhPQyBpcyBub3QgdGhlIG9ubHkNCj4+a2V5DQo+PiBleGNoYW5nZSBwcm90 b2NvbCB0aGF0IGNhbiBiZSB1c2VkIHdpdGggT1NDT0FQLCB0aGUgZGVyaXZhdGlvbiBvZiB0aGUN Cj4+c2VjdXJpdHkNCj4+IGNvbnRleHQgbXVzdCBiZSBpbmNsdWRlZCBpbiB0aGlzIGRyYWZ0Lg0K Pj4gDQo+PiANCj4+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBwYXJ0ICJnZXR0aW5nIG1vcmUg Y29udHJvbGxlZCByYW5kb20gbnVtYmVyc+KAnQ0KPj5zaW5jZQ0KPj4gdGhlcmUgbm8gZWxlbWVu dCBvZiByYW5kb21uZXNzIGluIHRoZSBkZXJpdmF0aW9uLiBXaGF0IGlzIHRoZSBhZHZhbnRhZ2UN Cj4+b2YNCj4+IGhhdmluZyBtdWx0aXBsZSB3YXlzIHRvIGRlcml2ZSB0aGUgc2VjdXJpdHkgY29u dGV4dD8NCj4NCj5Cb3RoIEVESE9DIGFuZCBUTFMgKGRlcGVuZGluZyBvbiB3aG8geW91IHRhbGsg dG8pIHJlcXVpcmUgdGhhdCB5b3UgaGF2ZSBhDQo+bGV2ZWwgb2YgcmFuZG9tIG51bWJlcnMgdGhh dCBtaWdodCBvciBtaWdodCBub3QgYmUgd2VsbCBzdWl0ZWQgdG8gYQ0KPmNvbnN0cmFpbmVkIGRl dmljZSB3aGVyZSB5b3UgY2FuIGdldCBpbnRvIHNpdHVhdGlvbnMgdGhhdCBlaXRoZXIgeW91DQo+ ZG9uJ3QgaGF2ZSBhIGdvb2Qgc291cmNlLCBvciB3aGVuIHlvdSByZS1zdGFydCB5b3UgZW5kIHVw IHdpdGggdGhlIHNhbWUNCj5zdHJlYW0uICBPbmx5IGdvaW5nIHdpdGggQUNFIHRva2VucyBjYW4g eW91IGJlIGVuc3VyZWQgb2YgaGF2aW5nIGEgZ29vZA0KPnNvdXJjZSBvZiByYW5kb21uZXNzIGZv ciB0aGVzZSBjYXNlcy4NCg0KWWVzIC4uICBidXQgSSBkb27igJl0IHVuZGVyc3RhbmQgaG93IHRo aXMgaW1wYWN0cyB0aGUgc3RlcCBvZiBkb2luZyBzZWN1cml0eQ0KY29udGV4dCBkZXJpdmF0aW9u IGdpdmVuIGFuIHByZS1lc3RhYmxpc2hlZCBzZWNyZXQga2V5LCB3aGljaCBpcyB3aGF0IEkNCnRo b3VnaHQgd2FzIHdoYXQgdGhlIGNvbW1lbnQgd2FzIGFib3V0Pw0KDQo+PiANCj4+IA0KPj4gWW91 ciBtZW50aW9uaW5nIG9mIENXVCwgaXMgdGhhdCByZWZlcnJpbmcgdG8gaXRzIHVzZSBhcyBhY2Nl c3MgdG9rZW4gaW4NCj4+QUNFPyBJZg0KPj4gc28sIHRoZSBDV1QgY291bGQgY29udGFpbiBhIHN5 bW1ldHJpYyBQT1Ata2V5IGFuZCBzb21lIG90aGVyIGNsYWltcyBhbmQNCj4+Zml0DQo+PiBuYXR1 cmFsIGludG8gdGhlIGN1cnJlbnQgd3JpdGluZy4NCj4NCj5ZZXMsIHRoYXQgaXMgd2hhdCBJIHdh cyB0aGlua2luZyBvZi4gIEkgYWdyZWUgdGhhdCBpdCBjYW4gaG9sZCB0aGUNCj5zeW1tZXRyaWMg UE9QLWtleSwgaG93ZXZlciBpdCBjYW4gYWxzbyBlcXVhbGx5IHdlbGwgaG9sZCB0aGUgZW50aXJl DQo+c2VjdXJpdHkgY29udGV4dC4gIEluIHNvbWUgY2FzZXMgdGhpcyB3aWxsIGJlIGZhciBtb3Jl IHByZWZlcnJlZCB0byB0aGFuDQo+ZG9pbmcgdGhlIGtleSBkZXJpdmF0aW9uIHN0ZXBzLiAgT25l IGNhc2Ugd2hlcmUgdGhpcyB3b3VsZCBiZSB0cnVlIGlzIGlmDQo+eW91IGFyZSBkb2luZyBtdWx0 aWNhc3QuICBBcyBwYXJ0IG9mIHRoZSBqb2luIHJlc3BvbnNlLCB0aGUgdG9rZW4gY291bGQNCj5y ZXR1cm4gdGhlIGZ1bGwgc2V0IG9mIGl0ZW1zIHRoYXQgYXJlIG5lZWRlZC4gIFRoaXMgY291bGQg YmUgZWl0aGVyIGp1c3QNCj50aGUgcmVjZWl2ZSBmaWVsZHMsIGlmIG5vIHJlc3BvbnNlcyBhcmUg Z29pbmcgdG8gbmVlZCB0byBiZSBzZW50IGJhY2ssIG9yDQo+Ym90aCB0aGUgc2VuZCBhbmQgcmVj ZWl2ZSBmaWVsZHMuICBJZiBib3RoIHNldHMgb2YgZmllbGRzIGFyZSBzZW50IGJhY2ssDQo+dGhl biBpdCBpcyBub3QgcG9zc2libGUgZm9yIHRvIHRyeSBhbmQgZ2VuZXJhdGUgYSBuZXcgc2V0IG9m IGtleXMgZm9yIGENCj5kaWZmZXJlbnQgZW5kIHBvaW50IHRoYXQgaXMgcGFydCBvZiB0aGUgbXVs dGktY2FzdC4gICBZb3UgaGF2ZSB2ZXJ5DQo+ZGlmZmVyZW50IHNlY3VyaXR5IHByb3BlcnRpZXMg aW4gdGhlc2UgY2FzZXMuDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kLiBJbiBhIHN5bW1ldHJpYyBt dWx0aWNhc3Qgc2V0dGluZyB0aGUg4oCccmVjZWl2ZSBmaWVsZHPigJ0NCmFyZSBlc3NlbnRpYWxs eSB0aGUgInNlbmRlciBmaWVsZHMiIG9mIHRoZSBub2RlIHdoaWNoIHNlbnQgdGhlIG1lc3NhZ2Uu IFNvDQpldmVuIGlmIGEgbm9kZSBoYXMgb25seSDigJxyZWNlaXZlciBmaWVsZHPigJ0gaXQgY2Fu IG1hc3F1ZXJhZGUgYXMgdGhhdA0Kc2VuZGVyLiBDb252ZXJzZWx5LCBpZiBhZGRpdGlvbmFsIGFz eW1tZXRyaWMga2V5cyBhcmUgdXNlZCwgdGhlbiB0aGVyZSBpcw0Kbm8gaXNzdWUgdG8gYmUgYWJs ZSB0byBkZXJpdmUgdGhlIHN5bW1ldHJpYyBzZW5kZXIgY29udGV4dCwgc2luY2Ugb25seSB0aGUN CnNlbmRlciBoYXMgaXRzIHByaXZhdGUga2V5Lg0KDQoNCj4NCj4+IA0KPj4gSSBzZWUgbW9yZSBp c3N1ZXMgZnJvbSBhIGNvbnN0cmFpbmVkbmVzcyBwb2ludCBvZiB2aWV3IHRvIHRyYW5zcG9ydCBh DQo+PmxhcmdlDQo+PiBzZWN1cml0eSBjb250ZXh0IHRoYW4gdG8gZGVyaXZlIHRoZSBzZWN1cml0 eSBjb250ZXh0IG9uIGJvYXJkLg0KPg0KPkl0IHdpbGwgZGVwZW5kIG9uIHdoYXQgc2VjdXJpdHkg cHJvcGVydGllcyB5b3Ugd2FudC4NCg0KV2hhdCBzZWN1cml0eSBwcm9wZXJ0aWVzIGFyZSBkaWZm ZXJlbnQgYmV0d2VlbiB0cmFuc3BvcnRpbmcgYSBrZXkgYW5kDQp0cmFuc3BvcnRpbmcgYSBkZXJp dmVkIGNvbnRleHQ/IE9yIGRvIHlvdSBtZWFuIGFzIGluIHRoZSBzZW5zZSBhYm92ZSwgdGhhdA0K dGhlIGtleSBjYW4gZW50aXRsZSB0byBtb3JlIHRoaW5ncyB0aGFuIHRoZSBjb250ZXh0Pw0KDQo+ DQo+PiANCj4+IEFzc3VtaW5nIHRoYXQgd2Uga2VlcCB0aGUgc2hhcmVkIGtleSBldGMuIGFzIHN0 YXJ0aW5nIHBvaW50IGZvciBPU0NPQVAsDQo+Pml0IGFsc28NCj4+IG1ha2VzIHNlbnNlIHRvIGtl ZXAgdGhlIGRlcml2YXRpb24gb2YgdGhlIHNlY3VyaXR5IGNvbnRleHQgaW4gdGhlIGJvZHkuDQo+ DQo+SSB0aGluayBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIG1vdmUgdG8gYW4gYXBwZW5kaXguDQoN Ck9LLCB3ZSBjb25zaWRlciB0aGF0Lg0KDQo+DQo+SmltDQo+DQo+PiANCj4+IEfDtnJhbg0KPj4g DQo+DQo+DQoNCg== From nobody Mon Dec 5 08:12:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BE7129534 for ; Mon, 5 Dec 2016 08:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eEX48Z2UbvNw for ; Mon, 5 Dec 2016 08:12:30 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A476129AA6 for ; Mon, 5 Dec 2016 08:10:49 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B0C20409CD for ; Mon, 5 Dec 2016 17:10:46 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1F15017E for ; Mon, 5 Dec 2016 17:10:45 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 12E043A9 for ; Mon, 5 Dec 2016 17:10:44 +0100 (CET) Received: (nullmailer pid 5436 invoked by uid 1000); Mon, 05 Dec 2016 16:10:42 -0000 Date: Mon, 5 Dec 2016 17:10:42 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3dutcntiput2gzrg" Content-Disposition: inline User-Agent: NeoMutt/20161104 (1.7.1) Archived-At: Subject: [core] resource-directory: notes from implementing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 16:12:32 -0000 --3dutcntiput2gzrg Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello RD authors, as of bringing my current in-house pseudo-resource-directory up to spec and thereby going through draft-ietf-core-resource-directory-09 in detail, I noticed some minor issues: * 6.2 URL template: This gives a {?rt} template with "MAY contain one or more of the values". By RFC6570 rules, this means that ?rt=3Dcore.rd-lookup,core.rd-group would be what multiple values look like. In contrast, RFC6690 gives the query string template as {?search*}, which would normally expand to `?search=3Done&search=3Dtwo`, but explicitly states that this is a 1-element list. Its matching criteria (Complete or Prefix Value String) have no consideration for any comma-splitting in the value string. Thus, the above example should, by the rules of RFC6690, produce an empty match. I suggest that the number of allowed values be reduced to one (whoever wants to query for both core.rd-lookup and core.rd-group should be able to deal with the overhead of querying for core.rd*). * 6.2 "the resource is application.xml (ct=3D40)", probably should be application/link-format * 6.4, lt definition: The text above says that unchanged lt should not be repeated; this implies that if ?lt=3D600 was sent in the original registration and updates omit lt, the updates are still only valid for 10 minutes after the update was sent. The lt definition describes a default of 86400 (24h), which is only the default when no lt has ever been sent. Update suggestion: "If no lifetime is included, the previous last lifetime set on a previous update or the original registration (falling back to 86400) SHOULD be used." (Possibly also "MUST be used" or "is implied"). Similar for con too. * 6.7 modifying example: I assume that the quotes in `PATCH /rd/4521?href=3D"/sensors/temp"` are an error. * 8 uri template variables: * The `res` parameter is defined, but not part of the URI template. * The `resource-param` parameter was called `source*` in RFC6690. It might make sense to call it the same here or reference to it. =20 Given that unlike RFC6690 (only one element, see above), here many filters can be given, it would make sense to suffix that parameter with a '*'. * Why is `rt` explicitly listed and not subsumed under `resource-param`? Granted, `rt` is defined for group/endpoint/resource lookups while `resoure-param` is only for endpoints, but why is that? * I'm missing guidance on what constitutes the "registry-key" (a la "cache-key") of a registration. 6.3 says that "registering twice with the same endpoint parameter does not create multiple RD entries", but the description of the `ep` parameter later reasonably requires uniqueness only within a domain. What I'm using right now is keying registrations by (ep, d) tuples, where the d may be empty or default to a domain configured for the RD, but I could need some guidance on the intended operation here. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --3dutcntiput2gzrg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlhFkX0ACgkQOY0REtOk veH7Sw//V7YUjK+a7nOhSe8trmiYdKt6hj5Ug+40PxOSrHj4WyjGPZ0RyWFtCxro FXy0nvUqzJOiuQGBHHD+0PE8sE+TZ2lwfdwDBCr3mYmIVvpz/CX0aW1l8QIskqbq PClRX8epmHjX+HLBUusRHULq+doK+6uPvLKEZ8LXS1kqRpyBMb13Y4g7GhCyFG3n YvinizOyQxMzoUg9Kz7VWALhxQXU24/INYf9c3tjU7DO9F5qstK9YoXnilRwzCeQ 4ydfMTlySruKPqp9hT5ak2gUhS+MmsEz5YbFu0splbw+cyQ97vy1bT9x7kfXjZRN V8yRWyJbzf+YvDwQ4fOH34uooHDxCWp5OsENQP7xUJUXV0nu+H60sXl95SzFXx8c N8C0n3GxuIXMWo1JO/emckQCxqU1vWq9bWHA2FrC9UaXuGjAf6SXUy2shxV/EHsh /b718QGy1n0WVlALc3NMr2wi/UakwKQg+clVL4POVx9ysuH/4KWlA7spNXyLhEd/ T0ByqMb/H83oeJc3378WNu6nCgu99DHU8KzAKD/gmmq++umkmUtLHmLtZE7cqynq qkH7HmHoCj1fw9Jl/wmWPZ7n0d1QlbxZg+eJTeImPEWrsBvgWu0tR1VUqLQu1vvt Btrimvyt+4xYKCzD28tc7NGG3qG27jQTfzNCSzRWIoVMHhmwI/0= =u83o -----END PGP SIGNATURE----- --3dutcntiput2gzrg-- From nobody Fri Dec 9 13:09:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C471294BC for ; Fri, 9 Dec 2016 13:09:46 -0800 (PST) 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 tvKWNkM4mRIK for ; Fri, 9 Dec 2016 13:09:45 -0800 (PST) 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 368ED12896F for ; Fri, 9 Dec 2016 13:09:45 -0800 (PST) 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 uB9L9fZl011711 for ; Fri, 9 Dec 2016 22:09:41 +0100 (CET) Received: from [192.168.217.113] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3tb4cP2rxhz8L5b; Fri, 9 Dec 2016 22:09:41 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 503010580.485533-0fc088d71c08e6bdc61eb99b8ee13bed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Fri, 9 Dec 2016 22:09:40 +0100 Message-Id: To: Core X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [core] CoRE Minutes from IETF97 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:09:46 -0000 Draft minutes for CoRE @ IETF97 are now up at: https://www.ietf.org/proceedings/97/minutes/minutes-97-core-00.html As usual, they start with a summary and then are followed by the = detailed notes. Please send any fixes to core-chairs@ietf.org or, if there may be a need = for discussion, to core@ietf.org. We need to have all the fixes in on = 2017-01-09 (Monday), but it can=E2=80=99t hurt to do these earlier. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 12 00:18:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921A0126579 for ; Mon, 12 Dec 2016 00:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 xoqBtVhuH5AQ for ; Mon, 12 Dec 2016 00:18:56 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9935D127078 for ; Mon, 12 Dec 2016 00:18:55 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 00:38:26 -0800 From: Jim Schaad To: Date: Mon, 12 Dec 2016 00:18:42 -0800 Message-ID: <0d0901d25450$5b138b10$113aa130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJUPCxvBes3tabDSouiE7QbNuhEDw== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: [core] draft-ietf-core-coap-pubsub-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 08:18:57 -0000 I have some questions on this draft. 1. I do not understand the correct use of the Max-Age option during the CREATE operation. * Is a CREATE considered to be equivalent to a publish operation? * Is the first publish all that is needed or is this related to the time since the last publish? * The last sentence in the first paragraph is really causing me problems because it seems to imply that the time is both reset on "publish" and has interesting properties as it only talks about create and not about publishing in the tree. 2. For CREATE - is the URI-Reference in the link value restricted in any way or is the full set of values from RFC 6690 allowed? Use of a full URI would be bad news, however would "" be permitted. 3. For PUBLISH - if no content-type was specified on creation, can one be specified at the time of publish or must it be absent? 4. For REMOVE - What is the correct behavior if a node with children is removed? Is this recursive or is it a failure? 5. For DISCOVER - Should the link relation rt="core.ps" be used only for the root of the pubsub tree or for all nodes which allow a create to be done? Jim From nobody Mon Dec 12 13:28:15 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D27DB1289C4; Mon, 12 Dec 2016 13:28:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148157809485.22458.8675632102034906893.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 13:28:14 -0800 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Ben Campbell's No Objection on draft-ietf-core-http-mapping-17: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:28:15 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-http-mapping-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss! From nobody Mon Dec 12 18:19:23 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E254F129857 for ; Mon, 12 Dec 2016 18:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-2.896, 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 Rod_136szbtd for ; Mon, 12 Dec 2016 18:19:19 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3638129554 for ; Mon, 12 Dec 2016 18:19:18 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 18:38:53 -0800 From: Jim Schaad To: Date: Mon, 12 Dec 2016 18:19:09 -0800 Message-ID: <000001d254e7$4b472ce0$e1d586a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJU27aLO2JqRYBZTJCi8/kVJn1Bzg== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: [core] draft-ietf-core-coap-pubsub-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 02:19:21 -0000 You are registering 2.04 as "No Content", however 2.04 already exists as "Changed" Jim From nobody Wed Dec 14 00:20:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80B21299BB for ; Wed, 14 Dec 2016 00:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqkvRhndLW4B for ; Wed, 14 Dec 2016 00:20:10 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99C91299BE for ; Wed, 14 Dec 2016 00:20:08 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id KkL51u00F4Hiz6i01kL5N9; Wed, 14 Dec 2016 09:20:06 +0100 Received: from 2001:983:a264:1:d9eb:f8bd:b030:f73d by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 14 Dec 2016 09:20:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 14 Dec 2016 09:20:05 +0100 From: peter van der Stok To: Jan Newmarch Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <1480754578.4443.186.camel@newmarch.name> References: <1480754578.4443.186.camel@newmarch.name> Message-ID: X-Sender: stokcons@xs4all.nl (HZ9dLr8HrBAq5RnzQxNdcRp6OrV/Zvvy) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Subject: Re: [core] Comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 08:20:15 -0000 Hi Jan, Thanks for your interest. Mailing list is correct medium for these suggestions for improvement. See below. > re: 5.1 Simple publishing to an RD > > This says that POST can be made to ./well-known/core on the RD. It > doesn't say if the required parameter 'ep' in 6.3 is required for this > method of registration. Thanks, this looks like an omission. Unless someone remembers a counter argument I will add the ?ep to the post > > Why does the RD have to support filtering? This remark reads like a major rewrite of the RD Spec. I don't think that will happen. > Section 5.1 POSTS to an RD. POST would normally expect a return value > which is the uri of the newly created resource. > Res: 2.01 Created >    Location: /rd/4521 > The returned location is provided for updates. No updates are expected in this case. > > Before the RD has updated the value in its directory, can a 3rd party > client have queried the RD lookup service and got back some info about > this endpoint? If so, what will it get? It can't get a CoAP entry > showing the uri path to the resources on the endpoint because it > doesn't know them yet. Agree, There is no info. > In section 6.3 POST is used both for new entries and for updating > existing ones. Use of POST and PUT in RD is in agreement with RFC7252 spec, and reflects current consensus. > > In section 6 it uses 'rd' for registering and updating resources using > POST, but a separate resource 'rd-lookup' to GET resources. Normal REST > usage would use GET on 'rd'. Why is there a separate resource? Section 3 is supposed to explain these design choices. Anything missing? > Greetings and thanks, Peter From nobody Wed Dec 14 01:14:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB0E129584 for ; Wed, 14 Dec 2016 01:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 hzU2lx3FudUg for ; Wed, 14 Dec 2016 01:14:00 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860C4129515 for ; Wed, 14 Dec 2016 01:14:00 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id KlDy1u00B4Hiz6i01lDynP; Wed, 14 Dec 2016 10:13:59 +0100 Received: from 2001:983:a264:1:d9eb:f8bd:b030:f73d by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 14 Dec 2016 10:13:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Dec 2016 10:13:58 +0100 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> References: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> Message-ID: <70e08696a7f97ae01ba3633e2266f816@xs4all.nl> X-Sender: stokcons@xs4all.nl (SdQIpshrsb3yuA/tcHIXuaJ1RaOx+Sdr) User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] resource-directory: notes from implementing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 09:14:02 -0000 Hi Christian, thanks for your comments. Indeed some are easily repaired, and thanks for pointing them out. I want to react to one specifically, having had problems with this issue as well. > > * I'm missing guidance on what constitutes the "registry-key" (a la > "cache-key") of a registration. 6.3 says that "registering twice with > the same endpoint parameter does not create multiple RD entries", but > the description of the `ep` parameter later reasonably requires > uniqueness only within a domain. > > What I'm using right now is keying registrations by (ep, d) tuples, > where the d may be empty or default to a domain configured for the > RD, > but I could need some guidance on the intended operation here. > Usng the (ep, d) tuple as key for registration sounds difficult as d is optional; and d's may be generated after the generation of multiple ep's. To which d do the earlier ep's belong to is then a valid question. My suggestion is to use ep suffixed with domain name as key in that case "ep1" will be different from "ep1-d1" for example. Zach always insisted that storage issues are the concern of the implementors, and they have the returned location (e.g. /rd/4521) to guide the implementation. That subsumes (IMO) storage uniqueness within one registration and consecutive updates; while additional criteria can be checked without affecting the storage. does that make sense to you? I will react to the other issues later, unless my co-authors beat me to it. Peter From nobody Wed Dec 14 02:34:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCFC129D19 for ; Wed, 14 Dec 2016 02:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlFyisrvRQhH for ; Wed, 14 Dec 2016 02:34:46 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928E9129CFF for ; Wed, 14 Dec 2016 02:34:27 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud3.xs4all.net with ESMTP id KmaR1u00D4WfiVN01maR6X; Wed, 14 Dec 2016 11:34:25 +0100 Received: from 2001:983:a264:1:5484:4d2:bb03:b609 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 14 Dec 2016 11:34:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Dec 2016 11:34:25 +0100 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> References: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> Message-ID: X-Sender: stokcons@xs4all.nl (StBsfybUFrN4HOeCAaiIlwht0JXMpqIl) User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] resource-directory: notes from implementing (2), X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 10:34:49 -0000 Hello Christian, some additional responses below: > > * 6.2 URL template: This gives a {?rt} template with "MAY contain one > or > more of the values". By RFC6570 rules, this means that > ?rt=core.rd-lookup,core.rd-group would be what multiple values look > like. > I suggest that the number of allowed values be reduced to one > (whoever > wants to query for both core.rd-lookup and core.rd-group should be > able to deal with the overhead of querying for core.rd*). I agree, That is how I interpreted the text up till now, where more than one stands for the wild card *. > > * 6.2 "the resource is application.xml (ct=40)", probably should be > application/link-format thanks, that is a clear omission. > > * 6.4, lt definition: The text above says that unchanged lt should not > be repeated; this implies that if ?lt=600 was sent in the original > registration and updates omit lt, the updates are still only valid > for > 10 minutes after the update was sent. The lt definition describes a > default of 86400 (24h), which is only the default when no lt has ever > been sent. > > Update suggestion: "If no lifetime is included, the previous last > lifetime set on a previous update or the original registration > (falling back to 86400) SHOULD be used." (Possibly also "MUST be > used" > or "is implied"). > > Similar for con too. This is fine with me. Reads better. > > * 6.7 modifying example: I assume that the quotes in `PATCH > /rd/4521?href="/sensors/temp"` are an error. And another omission. thanks. > > * 8 uri template variables: > > * The `res` parameter is defined, but not part of the URI template. yeah, Noticed this earlier and then forgot. > > * The `resource-param` parameter was called `source*` in RFC6690. It > might make sense to call it the same here or reference to it. > > Given that unlike RFC6690 (only one element, see above), here many > filters can be given, it would make sense to suffix that parameter > with a '*'. I don't follow; I dont see the similarity between source and resource-param; can you explain a bit more? > > * Why is `rt` explicitly listed and not subsumed under > `resource-param`? Granted, `rt` is defined for > group/endpoint/resource lookups while `resoure-param` is only for > endpoints, but why is that? No answer yet. will look into it. > Greetings and thanks, Peter From nobody Wed Dec 14 03:50:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D652129DE9 for ; Wed, 14 Dec 2016 03:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh2RO6B14NHX for ; Wed, 14 Dec 2016 03:50:25 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFE9129DF0 for ; Wed, 14 Dec 2016 03:50:22 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud3.xs4all.net with ESMTP id KnqM1u00D4WfiVN01nqMZk; Wed, 14 Dec 2016 12:50:21 +0100 Received: from 2001:983:a264:1:5484:4d2:bb03:b609 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 14 Dec 2016 12:50:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Dec 2016 12:50:21 +0100 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> References: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> Message-ID: <9a3a9ad52a9675a12ef4312e857c216b@xs4all.nl> X-Sender: stokcons@xs4all.nl (/cxoVCVwldrKcuyLRrykbeKUQwSgjZEY) User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] resource-directory: notes from implementing (3) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:50:27 -0000 Hi Christian > > * Why is `rt` explicitly listed and not subsumed under > `resource-param`? Granted, `rt` is defined for > group/endpoint/resource lookups while `resoure-param` is only for > endpoints, but why is that? > I think you answered your own question. Subsuming rt under resource-param will not make the text more readable (the contrary I would say) Peter From tobias.kaupat@lobaro.de Wed Dec 14 10:30:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3C12996E for ; Wed, 14 Dec 2016 10:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lobaro.de 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 fJs7m25TwA0e for ; Wed, 14 Dec 2016 10:30:10 -0800 (PST) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [184.154.48.174]) (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 93E4512995B for ; Wed, 14 Dec 2016 10:30:09 -0800 (PST) Received: from ns1.am20.siteground.biz ([107.6.152.202] helo=am20.siteground.biz) by se5.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86) (envelope-from ) id 1cHEJX-0007C0-By for core@ietf.org; Wed, 14 Dec 2016 12:30:08 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lobaro.de; s=dkim; h=Content-Type:To:Subject:Message-ID:Date:From:MIME-Version; bh=QPev+9lFPqEaUfNpvUUIHaxHIp9y4fua4H7XvrsbTVY=; b=nz0sf8LqWT3UrlnYeZdjpTA5Rm B5xFnwN8G/jZjKBl1lRlp9oW7YhD5DIF3Eu5Y9B90zMnfSPxEp8NimBfTV0fi/GZmBNBtILbpbrQB w+8K3pAXr8fs1+nw4JbfIub5vUIQ7QcJKFqHeRs0O0QnX16eZUnmdFlRd0vef4lXNuSk=; Received: from [209.85.213.177] (port=34061 helo=mail-yb0-f177.google.com) by am20.siteground.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1cHEJV-0006Bx-SJ for core@ietf.org; Wed, 14 Dec 2016 19:30:02 +0100 Received: by mail-yb0-f177.google.com with SMTP id d59so22735096ybi.1 for ; Wed, 14 Dec 2016 10:30:01 -0800 (PST) X-Gm-Message-State: AKaTC00BInj/3EcaABfI1UmcYckEr8JcB70qPgIhDkhq0vftDAlfVg+2P3zfNKOUi9UYlIgoJ5kA/eZp04t4DA== X-Received: by 10.37.14.3 with SMTP id 3mr56065746ybo.106.1481740200894; Wed, 14 Dec 2016 10:30:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.215.87 with HTTP; Wed, 14 Dec 2016 10:30:00 -0800 (PST) From: Tobias Kaupat Date: Wed, 14 Dec 2016 19:30:00 +0100 X-Gmail-Original-Message-ID: Message-ID: To: core@ietf.org Content-Type: multipart/related; boundary=001a113e71305313080543a286e1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - am20.siteground.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lobaro.de X-Get-Message-Sender-Via: am20.siteground.biz: none X-Filter-ID: s0sct1PQhAABKnZB5plbIdH40z9tliyPtpXyyHKT/m4RjSEj2nYPqqWQeUf53awNXewBu5TuhjJr gH3eyFBy7sNj8BQqkega5p9fBkeb4oZC/lGsrXcsS0xY0J18f6o7xB66CWvXcfKDfXjTU++u63IG 3S0TT70sbrW0DDzqYRmKYeyxZHraROR8tEU4bdSSZuM7jUXIESohoO51xWmU8f/7RUALN8w5ja3N xpxWDaoY2T47vGK5fezrUhroBI5OFEb1sdJJzGW+9EO+zwnsjXo8fmRB/Nw97k+xvb1cUqA55Spz eRGOV3aY7/PHVUgL647lNwN4qOsSZg+fYhVZGxSHPIfeHGgPjT6rcUajk76mpXXp0Gt2TbF6JjUg D4Z6SWM++pStxxa3FW225wglPaXHp6NpGwzrU5VG2NFRDQwN6A7sYlbJv8IjXJJB4hSigM/q/H2F qjD1scJGaqQs9GWLX2ZbQb3UJKihEmoDuwgTwRKLwC98NjMBcVQD/vDG16ixf05zXFqEd+e8EX60 wCY91scG0mEZL1BA7T8dPySDqE+X/czcI5QK7VzPhB1SqctcLegETCYFq9vtgSjvzw4TCyit5yhm YM6wMN3alVdoh9VoIekQHpwUfpYnEThmUjhy4N+pFLq/P49B7Rru+UHC058PwFZE8dxBN9Jg5CWz UmUscs3xxhDLpGFdlCNL2YbkHRO4G5j9/h8/ME876w== X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com X-Originating-IP: 107.6.152.202 X-SpamExperts-Domain: am20.siteground.biz X-SpamExperts-Username: 107.6.152.202 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=107.6.152.202@am20.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Classification: not-spam/combined X-Recommended-Action: accept Archived-At: Subject: [core] CoAP over Serial URLs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 23:07:38 -0000 --001a113e71305313080543a286e1 Content-Type: multipart/alternative; boundary=001a113e71305313050543a286e0 --001a113e71305313050543a286e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I'm implementing CoAP over a serial RS232 connection and wondering about the URL format. For CoAP over SMS they use a separate scheme "coap+sms" (see: https://www.ietf.org/archive/id/draft-becker-core-coap-sms-gprs-05.txt) so I just took "coap+rs232" for my case. So far the only question I have is: *Is there already some other URL scheme defined that I'm not aware of?* The actual question is regarding the Host. A serial connection is usually a file handle. For Windows something like "COM3" is just fine. On Linux based systems I have to connect to "/dev/ttyS3" which gets more problematic when encoding in URLs. *What is the best way to deal with the slash characters?* https://tools.ietf.org/html/rfc3986#page-21 restricts percent encoding of ASCII characters in the host part but allows system specific host lookups. Thats why I came up with an Implementation that implicitly adds the prefix "/dev/" to the host part of the URL before opening the connection on Linux systems. *Any opinions and suggestions are welcome.* Cheers, Tobias Kaupat --=20 Lobaro UG (haftungsbeschr=C3=A4nkt) Tempowerkring 21d 21079 Hamburg 040 / 22816531-0 www.lobaro.de info@lobaro.de USt.-Identifikationsnr.: DE297198645 WEEE-Reg.-Nr. DE18824018 Gesch=C3=A4ftsf=C3=BChrer: Dipl.-Ing. Tobias Rohde Sitz der Gesellschaft: Hamburg Handelsregister: HRB 134264 Amtsgericht Hamburg --001a113e71305313050543a286e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I'm implementing CoAP over a serial RS232 = connection and wondering about the URL format.

For= CoAP over SMS they use a separate scheme "coap+sms" (see:=C2=A0<= a href=3D"https://www.ietf.org/archive/id/draft-becker-core-coap-sms-gprs-0= 5.txt">https://www.ietf.org/archive/id/draft-becker-core-coap-sms-gprs-05.t= xt) so I just took "coap+rs232" for my case.

So far the only question I have is: Is there already some other= URL scheme defined that I'm not aware of?

The actual question is regarding the Host. A serial connection is usually = a file handle. For Windows something like "COM3" is just fine. On= Linux based systems I have to connect to "/dev/ttyS3" which gets= more problematic when encoding in URLs. What is the best way to deal wi= th the slash characters?


https://tools.ietf.org/ht= ml/rfc3986#page-21 restricts percent encoding of ASCII characters in th= e host part but allows system specific host lookups. Thats why I came up wi= th an Implementation that implicitly adds the prefix "/dev/" to t= he host part of the URL before opening the connection on Linux systems.

Any opinions and suggestions are welcome.

Cheers,
Tobias Kaupat


--
3D"=

<= /font>
Lobaro UG (h= aftungsbeschr=C3=A4nkt)
Tempowerkring 21d
21079 Hamburg
<= div style=3D"font-family:tahoma">=C2=A0
=C2=A0
USt.-Identifikationsnr.: DE297198645
WEEE-R= eg.-Nr. DE18824018
=C2=A0
Gesch=C3=A4ftsf=C3=BChrer: Dipl.-Ing. Tobias Rohde
Sitz der Gesellscha= ft: Hamburg
Handelsregister: HRB 134264
Amtsgericht Hamburg
--001a113e71305313050543a286e0-- --001a113e71305313080543a286e1 Content-Type: image/jpeg; name="lobaro_logo.jpg" Content-Disposition: inline; filename="lobaro_logo.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 8457dcfce885091a_0.1 /9j/4AAQSkZJRgABAQECWAJYAAD/4QCKRXhpZgAATU0AKgAAAAgABwEaAAUAAAABAAAAYgEbAAUA AAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAQAAAAclEQAAEAAAABAQAAAFERAAQAAAABAABcRlES AAQAAAABAABcRgAAAAAACSe+AAAD6AAJJ74AAAPocGFpbnQubmV0IDQuMC45AP/bAEMAAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB Af/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAf/AABEIADsAyAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0 4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery 8/T19vf4+fr/2gAMAwEAAhEDEQA/AP64v+CQUss3/BKf/gm7LNJJLK/7Dn7LjPJK7SSO3/CmPB3L OxLMfckmv0Wr85f+CP3/ACij/wCCbf8A2Y3+y5/6pjwdX6NUAFFFfEf7Tf7RHxS8PfEHwF+zB+y3 4Y8H+Lv2mvih4e1nx3NrXxIbWG+EfwA+Dvh/UbPQ9X+MvxXsvDd1p/iTxN/aPiPULXwn8L/hboGr +HNa+KPiiPXFj8VeFPCvgvxt4r0AA+3KK/N5P2Pf2zL+L+19c/4KxftLWXi0gSnTvAP7PP7CXh74 Rw3H3nt7TwV40/Zn+JnxG/shnyq22o/GzU9Zjt8Rr4h88fajpfCL46ftB/CL45+FP2Vv2zLrwJ4z 1L4rad4kvv2Z/wBp/wCGXhnUPAPhb4yan4J0mfxF4x+EHxK+GWo694sX4bfHfQfB1nqHj3SD4e8U 6z4F+K/grQfG3iDw3ZeCNQ8Fa14QiAKvx/lkX/gpJ/wTojWR1jl+FP7eXmxqzBJNmh/s5snmKDtf Y3K7gdp5GDX6M1+MP/BR39oTQ/2Zv2zf+Ce/xI1Lw5rvjzxBd+BP2z/Anwz+F/hM2Y8YfFn4s+P0 /Zn8L/Dv4beFzqE0Gn22oeJvEeoWkN9rWpzQaH4T8Pw6z4w8SXVj4c8P6vfW3uGk/s6f8FBvivaw +KvjX+374g/Zx1rVEF6Pg9+xT8Hv2eb3wb4HWUboPD2ofFX9q/4MftB+MfijqOmrtj1Lxjpvhj4Q 6Xrt2JZ7HwFoFm0VoAD9LqK/Kbxp47/a/wD2BbSL4pfHP4y2X7ZP7HmlXVpH8ZvH+v8Awx8HfC79 pf8AZy8MXNxHa3Pxq1k/CLT/AA18IfjJ8IfB/mx6l8VdM0T4WfDDxr4B8Hwax8QNMu/Hdjot/wCG Yf1IvdY0nTdIu9f1DU9PsdCsNOn1i+1m7vLe30qz0m1tnvbnU7nUJZEtINPt7ON7qa8llW3itkad 5BGpYAGjRX5UeBvEf7aP7eGkW/xf+Gvxqk/Yd/ZS8Up/aPwQuPCnwp8C/ET9qn40eA7rLaH8Y/Ee ofHLQ/Gnwn+C/hDx3p4g8Q/Dz4dy/B3x744uPCOp6P4k8Z+JvCetalc+ANC6XWfgJ/wUO+C9nP4w +Cf7b2rftZXujRtf3PwL/bN+FvwB8L2Pj+1gHmXXhvwr8b/2WfhB8B9R+FfiPUEV49E8VeLfh78Y PDtjfNDDq/haTT5ZLyyAP0yorwn9mz9oDwl+058HvDHxe8I6drvh1NWuNf8AD3ivwN4ttYLDxt8M /iP4H8Qan4M+JXwv8c6bbXF3b2HjH4eeONC13wn4ghtLu806e+0t77R7/UdHu9P1C6/Ib9j/APbG /bP/AG7Ph1F8OfgN4z8DeGNb+GXi74oeGf2pf2yPiF8PrLxjZeE/F1v8V/HK+CPgP8EPhF4cvfAv hTxd8WtF+EqeBPEHjvxl4s1KLwR8N9H8R+DhqHhn4neMfEet6T4dAP3vor83Zv2QP20tJhOr+FP+ Cr37RWq+LkUyrpnxd/Z1/Yd8X/CG6uh80cGoeDPhj+zp8D/iUNID4je20f43aNq0luSra4bnF0PT f2WP2kPiH498WfEv9nb9pLwf4Y+Hf7U/wRsvDOveKrDwNfapffC74ufC7xtNrNn4E+PXwYuPEAHi GLwX4k1Xw14m8M+JfB3iCS+8S/C/x54c1jwprGreItJm8J+NfF4B9q0V8cftU/tG+OPhhq3wy+CP wB8FaF8Tf2pfj3N4m/4Vn4X8W6pf6L8PPA/gnwPHo7/En47/ABi1fSLe71uy+F3w2bxL4V0ubS/D 9tJ4m8d+OvGPgj4f6BJpc3iS78S+HvJIP2RP21tdhGs+Nv8Agqx8f9B8XSqJ5NH+BX7On7E/gn4P 2N23zyW+meEvjF+z7+0N8TpdIV/3UUGufGzWdT+zqP8AibLcs1xQB9hfH5viGvwb+IDfCv8AtX/h ORoTf2SfDyaTJ4rW0+1Ww8QP4Jj8QBvD0nj5PDf9rv4Cj8RK3h2TxiuiJrytpDXgP56f8Et0/aqg 0Lxdb/tA3XxbvtPj8P8Ag6W4uPi/F8XC4+Id1DdXetwfD+/+PFjovxV1LSrfTLi2tvF5v/DmheAN K1C38M6F4BbxZremfEr4heMfSPA/xo/aU/Zu+M3w4+A37Y3iHwT8XvAHxy1i88HfAH9rPwP4Nk+F 93cfFGz0bUvEtr8E/wBoT4bR614h8M+HvGXi7w9o2vX3wy+JvgPVdL8E+PtU0HUPBV/4E8A+Lbrw haeOP0joA+d7r/hIvjJ4u8VaJZ+Jdc8IfDDwHq3/AAi+pz+E7+TRvE/jzxfDZ2l9rdmviO3xqnh7 wt4cW+tdLlbQZbDWdX15NTi/ta0sdNEN9ZvvgYmhQPqfwn8Z+NfBfim1Uz2a61428Y+OvCGs3EY3 LY+KvDfjHXNdhubG75gudQ0d9K8QWyym5s9TWWMI8Xwz1S18FeO/iF8LdflTT9V13xp4k+JPgWa6 YQw+LvDni+ePWtYj0maTat3qvhbxFcarp2saZGWu7TTTo2pGM2d+ki+w+LPFvh3wPoGoeJ/FWq2u jaLpkRluby6fG5jxDa2sKhpry/u5NtvY2FpHNeXty8dtawyzSIjfKYTB5bjcHicfmbhLG062LWNx latKliMpqUKtS9DC4nnhUyyjhKSg6U8NOgq1Llxs5VZ4mder+AcP8PcFcTcOZ1xZxzLDVeJsHmfE seJuI8wzOpl+b+H+KyrMMYqmV5FnccTh8XwTl3D+X08K8BicmxGVQzLL1h+KMVVx2IznE5pjsb4Z +NT8QPBumeI5tPbRtUM+qaN4i0OSUTvofinw5ql5oHiXRzMoXz47DW9NvYLa5KRm7tFt7sRos4Ud 5X5eWXx/+Kn7JWr6r40/aa8E6ZpX7J3xd8Vat47tfjN4YtdTXVf2Vte8aapLeHwx+1ToM95qS2Xw 5v8AzbW9i+P3hoWnhX4e6rfX3hr4u+HvCnh/Sbf4o679QeKf2vPhRo3iS+8GeDrLx/8AG7xdpEVn P4g0P4FeBta+JcXheLULWK+09fFPifSI4/BPhu+v7GeC+sdH1nxPZ63eWM0N9babLZyxzt9Nw7hc 1zbL8C44bEYrGPAYfEYtxoOEoJwpqeIxUVGNPCKU5xdVVPZ06NWoqTadkfoHCPEdWlwDwbm/GWOj g81zLIMmnjKmZUoZdjcdmWIy6nXm55YqdGdDM8XGM8Xicpw+GVTB1XXw8aMY4eXL9R0V4H8Lf2k/ hl8V9f1HwTpsnijwd8SdH09dX1T4XfFDwf4h+HPxBt9GaZbca7Y+H/FFjYt4j8Oid4oJPEnhS413 QIbmaG1m1OO6lSEld2KweKwNZ4fGYethqyjGfs69OVOThNc1OpFSS56dSLUqdSN4VItShJxaZ9lg MywGa4ZYvLcZhsdhnOdP22FrQrQjVpS5atGbg37OtRmnCtRny1aU04VIRkml8w/8Efv+UUf/AATb /wCzG/2XP/VMeDq/Rqvzl/4I/f8AKKP/AIJt/wDZjf7Ln/qmPB1fo1XMdoV+cf7LGNd/bt/4Ki+K tSH2nWvDfxC/ZT+CWkXknzS2fw88Kfsq+A/jJo2gwO2Wjs7fx9+0J8T9cECbY/tfiC6mKmSR2P6O V+cf7IXy/tm/8FYkbh2/aX/Z1nVTwzQP+wP+y5AkwB5MbzWtzErj5TJBMgO6NwAD9HK/OT/gqAq6 V8BPhB8Q7NRH4n+F37eX/BOnxD4S1AfLLYXXjP8Abe+BPwW8XxRyD544/EXwu+Kvj/wdqJjZWl0j xJqFuSUmdW/Ruvzn/wCCqALfsoeH4lBaWf8AbY/4JhQQRqCXmmk/4KYfsjrHFEgyzyOeERQWY8AE 0Acb+1P4I8O+Lv8Agp1/wSr1bXtPgv7v4deF/wBvnxv4XaeNZVsPET/DT4PeCl1CNXBUTw6J4z1u KCTG6GWdZoyskaMv6lV+cH7QciJ/wUp/4Jwq7qrS/Cz9vaOJWIBkceHv2dpSiA8swjjkkKjJ2I7d FJH6P0AYfifw3oXjPw14h8H+KNMtdb8M+K9D1bw14i0a/iE1jq+ha7YXGl6vpl5C3yy2t/p91cWt xG3Dwyup4Nfj78BPhr8T/wBrr/ghZ8D/AILaJ4xsrHx18Zf2IvhZ8H9Y8ZeKtQ1a0W/8MX/hLQPA fjy81bVdGsNT1ZNb8SfD238QQG/s7N5X17U0uGe1jZ7iD9nq/A/4YfE/xn8IP+DeH4b+Pfhvq8vh zx9/wxJ4K8PeAvFsGTJ4R8TfEyz0vwF4W8eW+GVZB4R1DxbY+L7diwglTS0Z28hy1AH2Tc/tnfEv 4g+I/Efw5/YE/ZZsf2gPDfwu1vUPhz4m+NvxD+K9j+zf+ypovi7wlcvoOu/D/wAB+NdM+H/xh+In xQ1TwJqFjd6B4rufhl8F9b+HnhrXdNvPB9x46TxVpWs6FpVPW/2sf23fgVZzeLf2pP2GPCmo/CXS ozeeLviJ+xL+0R4h/ae8QeA9EQFr3xN4i+CvxE/Z6/Zr+JfiDQdEiButZh+EVn8VfGS6ek95pvgv UhbzRL92fB/4T+BfgR8Kvh38F/hjokHhz4ffC3wb4e8CeD9GgCkWWg+GtMt9L09Z5QqNd300NsLn UtQmButR1Ca5v7uSW6uZpG9HoA/Lf9gLxx4M8X/tE/8ABR+++FHiXRfFfwd8b/Gr9nf49eAta8M3 9vqfhfVT8bP2NfgTf654i8NXto8ltLpHjGbwxZeMJWtn8m713Xdb1dh9r1W7d2/8EafA/h3wP+wP 4Gi8PafBZP4p+Mn7WfjjxBcRxotxq3iPxN+1d8Z7y+1C+lUB7meO3Wy0u2klLPDpem6fZKRDaRKv mf8AwTQ+B3hr9nn9sL/gr38PfBD/AGfwNd/tQ/Br4h+FfDqSs1n4Nh+K37OXgj4k+I/C+kWgbyNI 0Cy8c+KfFd54e0Oxjt9O0bRNQsNPsLaC0t4o196/4JM/8mG/Cb/sdv2kP/Wn/jLQB+jlfKHxB+An ibxB+2B+zb+0r4V1TQNJsPhh8L/2hvhD8UbO7m1GHXfF/gv4uT/CjxR4X0/TYbTTrjT9QHhrx98K dL1ffrF/YNpNpqGr/wBkGeTV9Rt5vq+igD84vhIB4i/4KmftrazqwF1d/Df9kv8AYd8A+DDJyuha J418c/td+OfGn2FekNx4s1nT/Cv9uSrze2/gvwvFJxpkVfo7X5x/An5f+CnH/BQ5G4dv2fv+Ce86 qeGaB7v9sSBJgDyY3mtbmJXHymSCZAd0bgfo5QB+c3/BWSNbb9gf43eLoB5Wv/Cu9+E/xp8Fainy 3Wi+Pvg38Z/h78S/BOs2U64lt7iw8SeGNOkZ4mRpbY3FrIWguJo3/Rmvzq/4K1c/8E5P2r0HLy/D q3giX+KSe48VeHYIIUHVpZppI4okGWkkdUUFmAP6K0Acv4t8E+EvHmljRvGPh7S/EOnJPHdwQalb JM9neRZ8m+0+5G2602/hyfJvrCe3u4dzeXMu45+Dv2F/C2h+L9J+MXjHxfaS+LvE3w+/bB/au+HH gjWPFV/qPiO68K+Dfhz8a/FnhLwXpOh/21d30WnyaH4d02y0yPVbeNNZvIoTLqOoXlzLNNJrSaLr v7ZXxT+Kuk+IPF3i/wALfsw/BPxpc/CiPwX4C8Ta14H1n45/E7QtP068+IOq+OPGPhi90vxXa/DX wVqGqp4H0nwV4f1fSYvFHiXSfFGp+LLrUNHtdG0h9bUv2BPhL4Q0+61n9mG61/8AZh+KVo9xqWh+ MPh54h8SS+G9S1lma58j4m/DbVdZvfBPxL8Pate7D4htfEOkSa7PE01xo3iDRdX8rUovGq4TB4uu sc8nwGLqUpJU8XXpUHjH9Xm+WWHlUw83aE1J0JTxFFN+9FxhKM39fmngf4Of2zlWI8RMbkuF8Rqm EybHQxtTwyyzijCcKvF0KOZZHh+I+Laua4biLLsbl1LE4fG5nhuG+GuJa/D/ALZ4enDE57hsflGD 9o/a18d6p8Mv2X/2gfH+h29nc614T+EHj/WNIj1G1ivdMXU7bw1qH2G41SzuI5re70u0umiutStp 4nhnsYbiKVfLdq6H9n74HfD/APZv+D3gL4MfDLRdO0Xwn4H8P6fpNsmnWVtZf2rfRW0S6n4gv0tU SKXVNdvhNqWoT4w09wUjCQRwxJ+d+n/FH9qb9v3wRr/wR8O+Abf9mjwHZr4q+DH7XPx18T2nh7xh qeoeMtFmv/BvxZ+E37Jvw+1k61putxy3MWpWF78b/jHpTeEPCVpfW+neHfhz8V/EKa5L4M+iPBvj j47fs26LYfDD4m/CX4lfHrwh4UtYdE8A/HD4QW/h7xT4h13wtp6La6FY/Fn4fahrugeKNL8eadps dvY6t4j8K2Xinwx4qntm16WXw3eX82i2/wBxl3/CpkX1LAVqMMT9fWPrYatXo4WeZYaphaVLBuk8 ROlCrWyyosX/ALJz/WZLNJzoUakaWJlS/M+MMqxvAviBmNDijBV1LKcPjOF6mIwdGpmtDIc3y7Ns T/bEZ1cuhirYLPIwwDp5tRU8snHIaPtsXT+tYD6zt/t4aXaaT8Bdf+OWmxJZ/Ej9msp8Z/hv4ht1 Eeq2moeF5re68ReFIrlcSzaJ8SvC8eqeBPEmiuz2erWGtJ5sDXlnp89sVia7YfFn9rbUfD3hvxN8 L/EvwP8A2b9G8SaB4t8ZWnxHu/D8fxU+NV14U1a01/w94KtvCHhfWvEdt4G+HD+ItM0/U/GN/wCJ 9Zh8WeKbCwi8L23hfStJ1TU9Ucr7/hvP+EOGcsjlvGPDlHizHfWK2IwsaGNoVo5PhKqpXwUsRTqT oupWrxr4uphaNScMNKs3V5MXWxNKn+Jca8JeInG+eSzvw34zxPAGV/VMPhMfPFZbi8NU4kx+HlVa zSGDrUKddUcNhJ4fLqOPxFKlUx9PDpUVVy/DYHEVvDP+CRvxg+Eulf8ABLH/AIJzaZqnxR+HWm6l p/7En7Mdnf6ff+NvDVnfWN5bfBzwhDcWl3aXGpxz21zbyo8U0E0aSxSKySKrKQP0P/4Xf8F/+ivf C/8A8L/wp/8ALavB2/4J0/8ABPl2Z3/YT/Y3Z2YszN+zD8E2ZmY5ZmY+CCSxJJJJyTyab/w7n/4J 7/8ARiP7Gv8A4jB8Ev8A5h6/IT+ij6a8O/EPwB4vu5rDwn458H+KL+3tzeXFl4d8TaLrd3BaLLFC 11Nbabe3M0Vus00MRndFiEssUZbdIoP53fHPV9S/Yn/ap179sK88O+JNf/Ze/aB+Hngj4d/tV6j4 P0HVvFer/An4g/CK68Rf8Ko/aL1XwtoFpqXiHVPhj4g8G+LtX+GPxs1vRNP1C68BWvg74ReML/TY /BWn+P8AxDoP2J8Kv2Uv2XPgTr994r+CH7NnwC+DfijU9Hm8Pal4k+FXwd+Hnw81/UNAub2w1K40 O+1jwj4d0jUbvR59R0vTL+bTJ7mSylvdOsLp4GntLeSP32gD5z8PfthfsleLfB8PxC8L/tQfs8+I fAc9mNRi8Z6N8aPhzqPhZrFoxL9qOvWviSXTEgWM7nd7lRGM79pBA+JNQ+KPh7/gpD8c/gp4d+A1 3/wnP7G37NvxW0X4+/Fz9oXSo5ZPhf8AGn4yfC+S6vPgZ8Ffgh4odP7L+KmkeCPiU+lfGv4n/Enw ZJq3gjw9rPw18CeAtM8Rar4g8ReKbPwp9p67+xj+x74o8Vy+PPE37KH7NfiLxxPdm/m8Z678Cvhf q/iua+aTzWvZfEWoeFrjV5LsykyG4a8MxkO8vu5r6NtbW2sba3srK2gs7OzgitbS0tYY7e2tba3j WKC3t4IlSKCCGJFjiiiRY441VEUKAAAfh1/wVF0746Qftu/8EwfiP+znpp8W/E/4IWP7aPxZh+FP 22x0s/G7wZpfhP4IeF/ib8IrHVtVuLbSNI8V+K/hz4t8USfDjU9amh0Kz+J+m+C5ddutP0cX2pWf 6E/Bf9vv9kH476VPdeDPjt4C0nxPpDfY/G3wq+Imu2Hwz+NXww16JFa/8LfFL4Q+OLjQ/H/gHxJp khMV3p3iLQrIShReafNfabPa3s/1Vd+HfD9/rWj+JL7QtGvfEXh221az8P6/d6XZXOtaFaa8tiuu 2uj6rNA99pltrS6Zpq6tBZTwRaiun2IvFmFpB5flnxS/Zp/Zy+ON1Z33xr/Z/wDgn8YL7T4lgsLz 4pfCrwJ8QLqxhRmdIbO48WaDq81tErszLHC6IrMzAAkmgD4n/aU/bZ8O/FHT/E37J/7CPxC8L/Gn 9rb4kaVceCxrnww1Wy8e+Bv2T9E8Twy6VrXx8+PvjDwzdXvhrwNB8PdIuLzxH4J+Hms6xZePPi14 ws9B8J+E9CnstQ1jX9B+l/Ev7Hnwn179im//AGELWHUdF+DMn7OMX7M2ivZTL/b3hzwVpvw+h+Hn hzVtLvUWAReJPDdhaafq2lajGsLwa3p9tfR+XJGpX33wN8PfAPww8PW3hL4a+B/B/wAPPClk7yWf hnwN4Z0Xwl4etJJAoke20XQLLT9NgeQIgdorZWYIoYnaMdhQB+aP7On7enhPSIdE/Zy/be8aeC/2 ff20vA+mw+HfGHhz4i6xp/w/8I/H59CSLTf+F6/s1+IfE02l6F8TPht8RUii8Uf2L4X1DUvFnwu1 DVLnwH8RNH0TX9GY3nsPxr/4KBfsk/Ayxt4dd+MnhLxt8QdcLWngD4G/CLV9M+Knx7+K2vvGxsfD Pw0+Efgy91Txh4n1W/mEcBu4tPt/D+ixy/2p4n1vQtDt7zVLb6W8f/DP4b/FjQJPCnxT+H3gj4l+ FppVnm8NeP8AwpoPjLQJZ0VkSaTRvEVhqWnPKiO6rI1sXVXZQQGIPI/Cz9nT9nz4GPev8E/gT8Gv g8+pR+TqL/Cz4YeCfh89/DvWTyr1vCWh6QbqPzEWTZOZF3qrY3AGgD8qv+CTmhfG/Tv2jP8AgqT4 m/aOSy034z/FL49fAT4qeLvBmmahb6xp/wALLHxl+zX4IuvA3weg12zLWXiK7+E3w6g8I+ANe8Ta ex0vxL4l8P6zr2kCPSdRso0+nv8Agkz/AMmG/Cb/ALHb9pD/ANaf+MtfoHYeHfD+lapruuaXoWja brXiiewuvE2sWGl2VnqniK50rT4NJ0y413ULeCO71efTtKtrfTLCbUJriSz0+3gsrdo7aKONTQPD vh/wppUGheFtC0bw1olrLez2ujaBpdlo2lW0+pX1zqmozQafp0FtaQy6hqd7eajeyRwq91fXdzdz mS4nlkcA2aKKKAPzU/aeh8Ufsw/tK+FP28PDfg/xZ48+FOt/Ci0/Z3/bI8NfD/QNU8XeO/Dvw58K +K9f8ffA/wDaB8PeCtAtrvxF43034I+KPHHxY0L4jeGPDOn6x4sk8AfF3UPGehaVqR+Hlzo+rfSv gb9s79kT4m+EYPH3w/8A2of2fvF/gye2+1f8JHofxf8AAN9pdtGF3Sx6jPHrx/su7tCGiv7HUhaX un3EcttfW9vcRSxJ9LV85eMv2PP2R/iL4pl8cfEH9ln9nLx341nuPtc/jDxl8EPhn4n8UzXW7f8A aZfEGt+GL7VpLjd83nPdmTdzuzQB8MfFD4xeDv8AgpH468A/s3fs06zZ/FP9mvwV8WvAXxR/a7/a N8JTLrHwXvNP+CXjLSPiP4P/AGZvhv4/si/h34ofEH4ifFDwt4Qj+LEHgfVNa0H4efCXRvGmheNt T03xZ4y8KaFf/rpVDS9L0zQ9OsdH0XTbDR9I0y1hstN0vS7O30/TtPsrdBHb2ljY2kcNtaWsEarH DbwRRxRIoREVQBV+gD4D+C/jDRv2efjf8Yf2e/ibfWvhVPi58X/Gnx0/Z78Ua1NHp2gfEzTvilcW 3iTx74D0nVblksH+I/gP4hXHiSS68JPdLrGpeDNZ8M6/pNldWi6sdP8AqX4x/G34a/AXwdd+Nvib 4ktdD02NhaaTpsYN94m8Xa5OVj03wp4I8NW2/WPFvizWbp4bLR/D+iWt3qN9dTxokQTfInSePvh1 4A+Kvhm+8F/EzwT4U+IPhHUthv8Aw14z0DS/Emh3TxbvJml0zV7W7tDcW5YvbXAiE9vIfMgkjkAY eR/DX9kD9mD4P+JI/GPw3+Bnw58MeL7eF7ax8VW/h61vfEml2kqsktno2u6oL7VNFspY3aOWz0m6 s7aWMhJImUADijTxVGLpUXRdO8vZ1Kjmp0Yybai6UYctZU7tQ/e0W4KMZNyTnL9ex3EHhvxVi8Px PxbS4ywvEKw2Ap8QZJw/hsmrZVxbjsvwlDCVM0o8SZhmNLG8HYnPIYeGIzeH+rHGNGlmtXHZjl8a ODxeGyTLMj9jzwF4x8E/ByTU/iLpJ8O/EL4sfET4ofHPxn4W8+K5Pg7Vfi9461vxrZeCpZ4C0E17 4N8P6novhnVriCWaC61jStQureeWCaNz9TUUV00qao0qdKLbVOEYJveXKkuaVrLmlu7Jatn59xPx Bi+KuI884kxtHD4bFZ5mmNzOrhcHGpDB4N4yvOtHBYKFWpWqwweDhKOFwlOpWq1IYelThOpOScmU UUVoeEFFFFABX53X3x9+LPhT4q/FvwV4S0PTfiNrnjT9uzw18BfAmm+NPF1/4Z8N/DzwxL/wTt+F /wC0Lreqx3NhoHiO8uNM03WPDvi/XZPDdnZW0utan4k1BYdT0+5uhcD9Ea/NBLG1/wCGpJp/K/e/ 8PLxfb98n/H1/wAOc4tN83bv2/8AHl+52Y8v/lps8395QB6Gn7TnxW+3zfCj/hA/AFz8dF/aPm/Z 4hvIvFHiGD4V+Vbfs46N+1HefE27d/D0/i230+y+Hut2nh0eCoba7u734iy2Wj/8JZZeF7y48Z6X x3wS+NvxQ0X4vfFLwb8UPDumnxB4+/b3X4JiPRvGGra54U8MaBpH/BNb4c/Hmw8QeCjq2kWN9Hpn iO98ByT3/hK5stLGg+IfGniZ/wC1PEMumjWvEny9+3T4q1/4RfCH9tT48fDvUG8OfFf4P/tt/Bjx d8OvFscFrqMnh7X/ABZ+yl+yt8G/EN22j6xBqHh/WINU+G/j7xZ4cm0zXtJ1TSkOpx6xBZRa/pmk 6pYfG0vxr+KOjf8ABNP4k/tlWHi68X9pO0/bK+H3xTtviVc2elahJB448T/B34P/ALO2s6rH4V1C wuvA62dx8GfEWseCLbw8PDP/AAjemWl0mqaXpFlr9pZarbgH7L/FT9rTxZ4P1j4g6PpPhPwpoeh+ AP2gLH4NeJ/i7491LxRJ8NvAOg3f7Nfwy+PUPjv4g/8ACLeHr248O6dqGtfESL4fW9/r+q+GfA2l SW9vrWv+PNP1C/0bwrrdrwh8afjtrnx78S6DOPgvqvwn0D9mH4I/GC4uPCPibXdffUda+IGrftAW d7qvgnxEPDVjaa54f1l/hz4dGmyX7xW0WhqNTs2uLzUJoh/PB4n/AG6P2q/g5+ydo/xu+HfxavNF +KHx7/a08T6l8WPFN74W8C+JZPFN1afspfs6x2QTSvFXhfW9C8PWtjDpenWthp/hfTNFsLGytIbG 0tobRfIP3B4W+IfjD4Y/FD/gl5ovgXVl0DSv2qv2PPElx8erGLTtKvIfHcmhaFcfFbR8DUrG8bwt Hp3j34y/ErW7WHwW3hyGOPxNJowj/sHTNF0vTQD9K/h98d/if4+8P/sU/EX4leDtH8Cx/tG+PtL1 Twz4O8F/EPxFdz+D9D8RfsifHv4tx6d8UL06RpeifEG6t4vC9rBc+G7Wyg8M6L4puNP1zT9X1+68 E6PrGs+BfGf9svUvGHws/ao+Hui+KfhJrl9efsO/tcfGbwP4/wD2ffiP4j8UReEJvhR4f8NeHJtO ufFUnh7Q9P1fVpLz4o+HdY0Hxb4R1CyexvtE1qxvND06a30zUb70tfDGh+I/gd/wTH8MazY/bND1 BtE0W7svtN5bebpup/8ABOn9prRb22+02lxBeR+dpl9dW3nRXCXEXm+dDLHcJHKn4i/sc/HH4q/t K/CX9pjVfjZ4wvPGt18LP+Cb37Y3wv8AASfYdI8OafoHgnWfD3wMn1PS10jwnp+haVqN5dv4V0BX 8QavZX/iNINOjtotWS3muYpgD+lj9pzxN4g8K+EPhze+HNXvtGutT/aO/Zo8M6hcafO0Et34f8Uf HHwNoPiLSJ2Xl7HWdGv73Tb+A/LPaXM0TfK5ryG2/ad+JF9pOhfFe7+H3hCP9njxh8b9I+Bel3Fl 4z19Pi7HbeMfjTB+z14J+KR02Pw5b+GzpXiX4japoN2/g+DX7HXPDvw71hfGcvia68U6fc/Dgep/ tUwRXHgz4ZrMm9U/aa/ZcnUbmXEtv8evAM0LZUqTskRW2nKtjDBlJB/GHwl8UvHt7/wVtvv2G7rx DLN+yt4Z+Lut/GLRPhI1lpg0+y+IOn+DU/aa0vVv+EkWyXxrc6do/wAdL5/iDovhW88S3HhHRtQt dJ0zS9CtNA0PRtJsAD9MPhh8GfD+k/tdfFvQIvHP7Q2oaB8N/hd+zf448I+H/Ef7Vf7TnizQbTxJ 4x8U/tD2Xia61XRfFHxd1jS/FFlq9r4G8LQXGieKbTWtCRNL/cabEb3UTd6f7Rdtr9h8XG8S/FGx /aJ1T9me3+F/h230a+/Zu8Z/FDw/qPw9+Jtp4m8dXHxE8RfE3wx8BfFXhj42eNND8SeFLv4XWPgm Tw3o/wASPD/hWfw149vvEei+EF1Kz1rWvWfBUESftdftDXKpiab4HfsuRSvuY7o7fxb+1C0K7Sdi 7GuJjlVDNvwxYKu38Ov+CxX7e37Wn7NP7UvhL4UfA/4uXPgLwH4j+BngnxJq2kWng/4favdy674h +InxK8N6tqVr4g8ReE9Y8SaZcT6NoelWsJ0vV7JLCW0W+09LW/kmupAD9g5f2gviT4p/4T6f9mfw r8PPix8P/gr4d8HtqHiXxV8S9WttS+Lmv+Ifhj4a+Lth4a+H+taT4d8SaXHBcfDDxt8PfENn8S9f v9W0vxHrfjAaT/ZFnaaXf+JX4T4Y/tIpqvxV8QeIPDx1HxN4I+Ovxg/Z80PwZ/a2o3lmvhjwr4+/ ZDi+Ldpq1hpUqXkVvNdtoURvdIiNlG93q91ezXLXELLcfmH/AMFDPHPi39j/AONf7NX7Pn7Nmu3v wn+EHx5+GXww+F/xS8I6CYrz+3/CHhbWPDnwS0KPT9e12PVvE/hHxHY/Cu4h8GHx14M1rw945utM 0fwxLe+I7m/8JeGLvSPpz9ti7m+B3wN/bZ+IvwnW28FeL/gV8S/2TfEPwm1PTLKzmt/BWqab4P8A hF8PLN9O0bUILzQ7iyi8EeI9b8MtpOpabfaTPpWpXEE9lLlGQA+vPjD+0T8Z4fiJp/w9+EWi+ArK 70b9qvwN8FNe1DxtqWrvba/4c8T/ALNrfG+SWGHS9CvptIuRql5Do8ssL3Eq2emrPBIsmpSLYXX+ PvjGx+JvxG+E/gPwzaa38TNd/aPPw+0ybxx478Qz+A/Dui6D+yV8EfjH4u8bRWkWj32o6P4e0t/F mmeG9L+HPhtIR4h8a66fEl3rGgQa/wCJtU0b8OfC3x++L9//AME2v2iP2xL3xre3f7Rtn+2N8FPH lj8RLjT9FlFh4ohsPg18CEvLDwg+mnwHY2X/AAqq5uvDEmh2nheHQZnvL3xBLpj+J7261qb69/ar +IXjD4a/sz/tNftMeCNZfQfjh8PP2qfgH4v8IeOoLLTrqbTNd+If7IH7JHw18ZyzaFqFnd+F9X07 XvBvi/XNOudB1rRNR0CG8k0zX7PTLfxF4f8AD+raWAffd1+1R8ZJta8LfCnR/hX4Bk+M1x+0d4j/ AGdPHtxf+Ptcj+GPhZ9I/Zwn/ac0r4k6JqEHg1vFPifT9b+H2peCYD4Il0jQ77TfGPiLUPC8/iuX SNAfxxqGT4k/bA+JPhvSYbHxJ4V+GPgDUvDfxL+I3wz+LPxe8XeIPGd38APAWpeDNK8I+JfCF7qW uaX4Wh1Hw9bfFTwt4103ULLUfiBe+DfBfgjWNK8R+FNQ8c+JNe/4Qm18e/Pf7Fer6j8RPhP+wL8b PGd0+u/FL41/HL43fEv4oeLp1jt7vxZ41j+Bnxt+HFtrFzZWKWulWCWHgTwT4S8J6ZpWkWGn6Npe h+HtLsdO061itUFfF3/BSv8AbA/aK/ZD1zUZv2ePiH/wr2T4i/tL/Ht/GR/4RLwN4tXWW8MfBf8A ZXbQyU8c+GfEyWH2E6xqX/ILWyFyLki7+0COERgH9JnhjUL7VvDXh7VNTOhnUtS0PSdQ1A+GNVm1 3w0b68sLe4uz4e1y4sdLn1nQzPJJ/ZOqz6Zp02o2H2e7ksbR5mt49yvAv2U9F0zw7+zD+zroei2i 2OlaZ8DvhVa2FmjzSR21ungfQ9kMbzySy+WmdqK0jbFARcKqge+0AFFFFABRRRQB/9k= --001a113e71305313080543a286e1-- From nobody Wed Dec 14 21:47:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D88A12955F for ; Wed, 14 Dec 2016 21:47:29 -0800 (PST) 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 YxsvOO6lWKz8 for ; Wed, 14 Dec 2016 21:47:27 -0800 (PST) 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 1A1B7128DF6 for ; Wed, 14 Dec 2016 21:47:26 -0800 (PST) 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 uBF5lN0I022310; Thu, 15 Dec 2016 06:47:23 +0100 (CET) Received: from [192.168.217.102] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3tfMsR1zXjz8Kl4; Thu, 15 Dec 2016 06:47:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: Date: Thu, 15 Dec 2016 06:47:24 +0100 X-Mao-Original-Outgoing-Id: 503473644.272101-97d89d11fc66e3e40b5b73207df67bc5 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tobias Kaupat X-Mailer: Apple Mail (2.3251) Archived-At: Cc: core@ietf.org Subject: Re: [core] CoAP over Serial URLs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 05:47:29 -0000 Hi Tobias, > On 14 Dec 2016, at 19:30, Tobias Kaupat = wrote: >=20 > Hi all, > I'm implementing CoAP over a serial RS232 connection Interesting =E2=80=94 we had a brief discussion about this at the T2TRG = meeting in Ludwigsburg, and I=E2=80=99d sure like to know more about = this. > and wondering about the URL format. When we started to think about the bluetooth URI format = (draft-bormann-t2trg-ble-uri) we ran into a similar discussion. A URI = for a =E2=80=9Clocal interconnect=E2=80=9D isn=E2=80=99t really a = =E2=80=9CU=E2=80=9DRI, as its meaning is dependent on that local = context. There is precedence in the file:// URI, but there is still = some uneasiness around. (There are also authority-based URIs with = link-local addresses; similar problem.) > For CoAP over SMS they use a separate scheme "coap+sms" (see: = https://www.ietf.org/archive/id/draft-becker-core-coap-sms-gprs-05.txt) = so I just took "coap+rs232" for my case. Are the voltage levels on the serial line (which is what =E2=80=9CRS232" = is about) really important? Do you need a different URI for TTL-level UARTs? Maybe more like = coap+serial or coap+uart. How do you decide the bit rate? The CoAP over Serial specification = could align on a strong default (say, 115200 bit/s as in 6lobac), but = there may occasionally be a need to deviate even from such a strong = default. > So far the only question I have is: Is there already some other URL = scheme defined that I'm not aware of? Not for serial. > The actual question is regarding the Host. A serial connection is = usually a file handle. For Windows something like "COM3" is just fine. = On Linux based systems I have to connect to "/dev/ttyS3" which gets more = problematic when encoding in URLs. What is the best way to deal with the = slash characters? >=20 >=20 > https://tools.ietf.org/html/rfc3986#page-21 restricts percent encoding = of ASCII characters in the host part but allows system specific host = lookups. Thats why I came up with an Implementation that implicitly adds = the prefix "/dev/" to the host part of the URL before opening the = connection on Linux systems. That is probably the right approach. Again, compare the link-local = addresses which would need a % character (which need to percent-encoded) = =E2=80=94 endless discussion. I=E2=80=99m definitely interested in also nailing down the data format = over serial. Let=E2=80=99s discuss this tomorrow... Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Dec 15 09:31:22 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7391D129423 for ; Thu, 15 Dec 2016 09:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeW5L6gyt68F for ; Thu, 15 Dec 2016 09:31:19 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0094.outbound.protection.outlook.com [104.47.36.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 F1A4E129600 for ; Thu, 15 Dec 2016 09:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=06HnGDFFtlp9T5P9P33PJowsTAyvOJ9W67u12nBIjbw=; b=Zym8HipWUD7ovcnoMfJn4DqNxxWm2C2ejeW2+16dWVRN72lPgbFfvxp+d8Xk82Uh4etfdNOf4BJN1yVLRgIkFvpQd5vTMK2gGqm5akJ58GNM0cLCQLJQKJwm/Wv+xvEOgtk2FZZfbCoJJq2aHVaktTwOQpWwZP7gT1MwNzt4NP0= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BL2PR06MB2083.namprd06.prod.outlook.com (10.167.99.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Thu, 15 Dec 2016 17:31:15 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0771.014; Thu, 15 Dec 2016 17:31:15 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhA== Date: Thu, 15 Dec 2016 17:31:15 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BL2PR06MB2083; 7:Elg2c0geqTBq68i+yhCClwd6BMCSud2vum/r1Jnt9HAD0lP+jLyYrocAXrjIrhuahXNxnIzUWamXZlzhjfMWqJF4P7S2GrG8lZUemYsfbzWd693to2SxgnzsW994tSZ7LGm83ifv7ZT88BKPENoM47bB9Yb9ZFS+s7cyCQLeiNbXf5g//iX1q6ddAn5xE+na+tP+L/McoNj4VU91N01rnThBl/PFJauj12k7b82HUnQoDzhoLpnqwC9lyWAJucBAZWms882fCGKpiuaC/UuxNRKPTYh0V/WKhSTsWgHPVmN+KPLom9JN5obSnEL+L7e/zE9QXknVJo2UR4Vg0XhxrNDFyL9iVr3D3DkVWXJa41k3dpHLrOWSaXVsqlOHfV926yHt7x7oE4EvcyUouiUlu2fRWJG4MKhNtxs8d4LZVYDtadfMokS8rS6mX/ZTNMBPZL0QZmelRHxgpDtGcMK7GQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(189002)(199003)(9686002)(122556002)(76576001)(6506006)(81156014)(81166006)(6436002)(305945005)(5640700002)(7696004)(1730700003)(8936002)(4326007)(5660300001)(7736002)(86362001)(77096006)(66066001)(3846002)(92566002)(74316002)(54356999)(110136003)(38730400001)(101416001)(2900100001)(102836003)(2906002)(189998001)(6916009)(6116002)(8676002)(2351001)(97736004)(68736007)(25786008)(50986999)(99286002)(106356001)(105586002)(3660700001)(2501003)(3280700002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR06MB2083; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: b7d59e71-2bef-4071-0d1c-08d425102c26 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BL2PR06MB2083; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BL2PR06MB2083; BCL:0; PCL:0; RULEID:; SRVR:BL2PR06MB2083; x-forefront-prvs: 0157DEB61B received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 17:31:15.4156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR06MB2083 Archived-At: Cc: Core Subject: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 17:31:21 -0000 Hi Peter The current CoMI draft rely on the observe mechanism [RFC 7641] to transfe= r YANG notifications. A common use of these YANG notifications is the implementation of what was = called in SNMP, traps. Traps are typically sent to a management station (e.g. NMS) to notify this = station of significant events. This mechanism typically require a long term relationship between network e= lements (CoMI servers) and a management station (CoMI client). However, RFC 7641 section 4.5. Tran= smission, required that this relationship is terminated at the first unsuccessful transmission. "or if the last attempt to retransmit a confirmable notification times out, then the client is considered no longer interested and the server MUST remove the associated entry from the list of observers." How this concept of long term relationship between network elements and a = management station should be addresed? Should the CoMI draft redefine how the list of observers is managed by the = observe mechanism? Should CoMI clients send notifications only with non-confirmable CoAP messa= ge? Should CoMI servers (i.e. management stations) periodically re-register as = an observer (e.g. every day)? Should we adopt a different method to transfer notifications? Regards, Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109 From nobody Thu Dec 15 09:52:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2B4129B82 for ; Thu, 15 Dec 2016 09:52:18 -0800 (PST) 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 NXCgv85xwRl5 for ; Thu, 15 Dec 2016 09:52:16 -0800 (PST) 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 46C99120725 for ; Thu, 15 Dec 2016 09:52:16 -0800 (PST) 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 uBFHqD5C019704; Thu, 15 Dec 2016 18:52:13 +0100 (CET) Received: from [192.168.217.113] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3tfgxn2Mpfz8L7n; Thu, 15 Dec 2016 18:52:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: Date: Thu, 15 Dec 2016 18:52:12 +0100 X-Mao-Original-Outgoing-Id: 503517132.664803-f21f7a838530dec2852d87011b6aa607 Content-Transfer-Encoding: quoted-printable Message-Id: <00A2C066-0F47-4E77-ACB7-9412E5CF09F3@tzi.org> References: To: Michel Veillette X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 17:52:18 -0000 > On 15 Dec 2016, at 18:31, Michel Veillette = wrote: >=20 > How this concept of long term relationship between network elements = and a management station > should be addresed? COMI is not the only CoAP user that is running into the need for = long-term observation. I think we should solve this in a more general way. (Note that there is a proposal about =E2=80=9Cdelegated observe=E2=80=9D = right now; there also was some discussion about good ways to use Observe = at the Ludwigsburg T2TRG meeting.) > Should the CoMI draft redefine how the list of observers is managed by = the observe mechanism? The COMI draft could be a place to do this, but an independent draft = sounds better. > Should CoMI clients send notifications only with non-confirmable CoAP = message? Unreliability was a big problem with SNMP traps; we probably don=E2=80=99t= want to repeat that problem. > Should CoMI servers (i.e. management stations) periodically = re-register as an observer (e.g. every day)? Most likely, something like this will need to be done anyway (management = will want to know that the device is still there). But we should define = the details in a way that is as useful as possible to management = applications. > Should we adopt a different method to transfer notifications? For people used to HTTP, using a POST from the server to the client = always seems the obvious solution =E2=80=94 after all, that=E2=80=99s = all that classic HTTP can do. HTTP is growing new functionality in this = space now (e.g., RFC8030 Webpush), and we should pay attention. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Dec 15 10:22:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEE7129B88 for ; Thu, 15 Dec 2016 10:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 R1Vj703-QpLX for ; Thu, 15 Dec 2016 10:22:06 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0109.outbound.protection.outlook.com [104.47.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1DC129443 for ; Thu, 15 Dec 2016 10:22:05 -0800 (PST) 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=k2p+Gux+dGJqUBVWNJfXglEEJa3aDgPw86DSBsX9+cE=; b=cWXVOVykTfDBK3WpryJy1NwDvd6CBdMxGkcrKHkWCuCrX6ThRhsna8T3S0d4c0lyt4MRfS5i3XqMsoYn//YDiy+TKupLmNtrprWj596JEz7Kl/KvJHu/qIVsMpwpk8+/0IbCETqNTL1K412FH8LSf7sKj5Fsc6aFXYxZWhVeqlw= Received: from HE1PR01MB1546.eurprd01.prod.exchangelabs.com (10.164.30.156) by HE1PR01MB1547.eurprd01.prod.exchangelabs.com (10.164.30.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Thu, 15 Dec 2016 18:22:01 +0000 Received: from HE1PR01MB1546.eurprd01.prod.exchangelabs.com ([10.164.30.156]) by HE1PR01MB1546.eurprd01.prod.exchangelabs.com ([10.164.30.156]) with mapi id 15.01.0761.022; Thu, 15 Dec 2016 18:22:01 +0000 From: "Turner, Randy" To: Carsten Bormann Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAABNvwAAAEKSYA= Date: Thu, 15 Dec 2016 18:22:01 +0000 Message-ID: <3D786F04-4AF0-4FCF-BCD8-1F0A255DED4C@landisgyr.com> References: <00A2C066-0F47-4E77-ACB7-9412E5CF09F3@tzi.org> In-Reply-To: <00A2C066-0F47-4E77-ACB7-9412E5CF09F3@tzi.org> 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-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:cb:c000:8248:e09d:f978:b422:d7ad] x-ms-office365-filtering-correlation-id: a1dec53f-dfc0-46f7-791b-08d42517437f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR01MB1547; x-microsoft-exchange-diagnostics: 1; HE1PR01MB1547; 7:0DeVdmVz0UgNQOLjMEP4d7V6GirD6UIZnP0N5IgHCWeNfZT14q+rrGvqkdlagpw5uY0TswzxZBZNWvMYe0G45D2x/4yOqo87FLQfa1LaiLKhLR/00W42eV2tAf48E/1pwjPf7oidgGX2B/+JzbGLAm1BphyLHDXA0Zh/fOditxo1p3pBuFHcwVbZABx97CeZC2ytpNB3fSw5J6EjDon7fSLHLziLdbGh6lB9UJ7eDihY2NROmNRbIABPQf7zfXJRIgi22VHsynhbnWyA9H56Yp7X5kAE5EJXE/iyCaPHu6bJAGN0GuVxsNAI2A1zzoRNyRnRpNek3oblh9y/drxYiVGQPjMfGqwoEMlPmVx15/LC7WBi5xHFOkARLrAEMH2XonsPA73yxrpBew+RlfJh/lS2CZQ02IYGRmAj+hp7UFkVEiyGCU+26a4psPiDFC5bt28b+/9QxtxQ2yQx8sfMig== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558021)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:HE1PR01MB1547; BCL:0; PCL:0; RULEID:; SRVR:HE1PR01MB1547; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(39840400002)(39450400003)(39850400002)(39860400002)(39410400002)(189002)(199003)(24454002)(377454003)(229853002)(3660700001)(561944003)(83716003)(33656002)(122556002)(36756003)(6506006)(6486002)(6512006)(77096006)(50986999)(3280700002)(92566002)(86362001)(76176999)(38730400001)(110136003)(101416001)(2950100002)(6916009)(8936002)(68736007)(81156014)(81166006)(8676002)(54356999)(2900100001)(7736002)(4326007)(6436002)(5660300001)(106356001)(102836003)(189998001)(6116002)(305945005)(97736004)(82746002)(2906002)(105586002)(25786008)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR01MB1547; H:HE1PR01MB1546.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9503F636F97E90479882143E77A20741@eurprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 18:22:01.1224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR01MB1547 Archived-At: Cc: "core@ietf. org WG" Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 18:22:08 -0000 U05NUCB0cmFwcyBhbmQgaW5mb3JtcyBkbyBub3QgbmVjZXNzYXJpbHkgcmVxdWlyZSBhIGxvbmct dGVybSDigJxyZWxhdGlvbnNoaXDigJ0gLSB0aGVpciByZWxhdGlvbnNoaXAgaXMgaGlzdG9yaWNh bGx5IHN0YXRpY2FsbHkgY29uZmlndXJlZCBhbmQgbWFpbnRhaW5lZCBzdGF0ZWxlc3NseSAtIHRo ZXJl4oCZcyBubyDigJxyZWxhdGlvbnNoaXDigJ0gbGlrZSBhbiBhY3RpdmUgVENQIHNlc3Npb24g dGhhdCBoYXMgdG8gYmUga2VwdCBhbGl2ZS4NCk1heWJlIHdlIHNob3VsZCBkZWNpZGUgb24gdGhl IGRlZmluaXRpb24gb2Yg4oCccmVsYXRpb25zaGlw4oCdDQoNClIuDQoNCg0KPiBPbiBEZWMgMTUs IDIwMTYsIGF0IDEyOjUyIFBNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6 DQo+IA0KPiANCj4+IE9uIDE1IERlYyAyMDE2LCBhdCAxODozMSwgTWljaGVsIFZlaWxsZXR0ZSA8 TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPiB3cm90ZToNCj4+IA0KPj4gSG93IHRo aXMgY29uY2VwdCBvZiBsb25nIHRlcm0gcmVsYXRpb25zaGlwIGJldHdlZW4gbmV0d29yayBlbGVt ZW50cyAgYW5kIGEgbWFuYWdlbWVudCBzdGF0aW9uDQo+PiBzaG91bGQgYmUgYWRkcmVzZWQ/DQo+ IA0KPiBDT01JIGlzIG5vdCB0aGUgb25seSBDb0FQIHVzZXIgdGhhdCBpcyBydW5uaW5nIGludG8g dGhlIG5lZWQgZm9yIGxvbmctdGVybSBvYnNlcnZhdGlvbi4NCj4gSSB0aGluayB3ZSBzaG91bGQg c29sdmUgdGhpcyBpbiBhIG1vcmUgZ2VuZXJhbCB3YXkuDQo+IChOb3RlIHRoYXQgdGhlcmUgaXMg YSBwcm9wb3NhbCBhYm91dCDigJxkZWxlZ2F0ZWQgb2JzZXJ2ZeKAnSByaWdodCBub3c7IHRoZXJl IGFsc28gd2FzIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCBnb29kIHdheXMgdG8gdXNlIE9ic2VydmUg YXQgdGhlIEx1ZHdpZ3NidXJnIFQyVFJHIG1lZXRpbmcuKQ0KPiANCj4+IFNob3VsZCB0aGUgQ29N SSBkcmFmdCByZWRlZmluZSBob3cgdGhlIGxpc3Qgb2Ygb2JzZXJ2ZXJzIGlzIG1hbmFnZWQgYnkg dGhlIG9ic2VydmUgbWVjaGFuaXNtPw0KPiANCj4gVGhlIENPTUkgZHJhZnQgY291bGQgYmUgYSBw bGFjZSB0byBkbyB0aGlzLCBidXQgYW4gaW5kZXBlbmRlbnQgZHJhZnQgc291bmRzIGJldHRlci4N Cj4gDQo+PiBTaG91bGQgQ29NSSBjbGllbnRzIHNlbmQgbm90aWZpY2F0aW9ucyBvbmx5IHdpdGgg bm9uLWNvbmZpcm1hYmxlIENvQVAgbWVzc2FnZT8NCj4gDQo+IFVucmVsaWFiaWxpdHkgd2FzIGEg YmlnIHByb2JsZW0gd2l0aCBTTk1QIHRyYXBzOyB3ZSBwcm9iYWJseSBkb27igJl0IHdhbnQgdG8g cmVwZWF0IHRoYXQgcHJvYmxlbS4NCj4gDQo+PiBTaG91bGQgQ29NSSBzZXJ2ZXJzIChpLmUuIG1h bmFnZW1lbnQgc3RhdGlvbnMpIHBlcmlvZGljYWxseSByZS1yZWdpc3RlciBhcyBhbiBvYnNlcnZl ciAoZS5nLiBldmVyeSBkYXkpPw0KPiANCj4gTW9zdCBsaWtlbHksIHNvbWV0aGluZyBsaWtlIHRo aXMgd2lsbCBuZWVkIHRvIGJlIGRvbmUgYW55d2F5IChtYW5hZ2VtZW50IHdpbGwgd2FudCB0byBr bm93IHRoYXQgdGhlIGRldmljZSBpcyBzdGlsbCB0aGVyZSkuICBCdXQgd2Ugc2hvdWxkIGRlZmlu ZSB0aGUgZGV0YWlscyBpbiBhIHdheSB0aGF0IGlzIGFzIHVzZWZ1bCBhcyBwb3NzaWJsZSB0byBt YW5hZ2VtZW50IGFwcGxpY2F0aW9ucy4NCj4gDQo+PiBTaG91bGQgd2UgYWRvcHQgYSBkaWZmZXJl bnQgbWV0aG9kIHRvIHRyYW5zZmVyIG5vdGlmaWNhdGlvbnM/DQo+IA0KPiBGb3IgcGVvcGxlIHVz ZWQgdG8gSFRUUCwgdXNpbmcgYSBQT1NUIGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50IGFs d2F5cyBzZWVtcyB0aGUgb2J2aW91cyBzb2x1dGlvbiDigJQgYWZ0ZXIgYWxsLCB0aGF04oCZcyBh bGwgdGhhdCBjbGFzc2ljIEhUVFAgY2FuIGRvLiAgSFRUUCBpcyBncm93aW5nIG5ldyBmdW5jdGlv bmFsaXR5IGluIHRoaXMgc3BhY2Ugbm93IChlLmcuLCBSRkM4MDMwIFdlYnB1c2gpLCBhbmQgd2Ug c2hvdWxkIHBheSBhdHRlbnRpb24uDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxp bmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZQ0KDQo= From nobody Thu Dec 15 10:52:45 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CD7129457 for ; Thu, 15 Dec 2016 10:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bit-9c2CW_SD for ; Thu, 15 Dec 2016 10:52:36 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0116.outbound.protection.outlook.com [104.47.42.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67238129422 for ; Thu, 15 Dec 2016 10:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Yhzdlam7BrMD+5ojak4DYeCDDfOnGITF18cZZqeGBQ=; b=nnpK3j9n/f3z39jkxjfKbxNwF5MSGJ8oyiQovC6KdiD+UfK2i/CwQzl//i3KLuuAb0Z/q4hsKoWZEQXTcLj+9tymq9r4rJjbsDXQPgiUoqOg6dWA27DleZz3Kl68O7cjnayBCGOqKqyQBnYCLJQMd2EnABDnJJZQPuJJQ/hJk0U= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Thu, 15 Dec 2016 18:52:35 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0771.014; Thu, 15 Dec 2016 18:52:35 +0000 From: Michel Veillette To: "Turner, Randy" , Carsten Bormann Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAABNvwAAAEKSYAAAOHYAA== Date: Thu, 15 Dec 2016 18:52:34 +0000 Message-ID: References: <00A2C066-0F47-4E77-ACB7-9412E5CF09F3@tzi.org> <3D786F04-4AF0-4FCF-BCD8-1F0A255DED4C@landisgyr.com> In-Reply-To: <3D786F04-4AF0-4FCF-BCD8-1F0A255DED4C@landisgyr.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 21d49249-2518-489a-50ca-08d4251b887e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2305; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 7:A1kvx7oYyE9VznQvSNGqgj+2HboCcJp1ep8IFYs04CPyVJAGRlxPw15ZFdOj2gdFPtXlrSkZ4C63Y0denHALMohDjIPk9UVegMIWahupVlQ7M4Ah4ketPvU6ytCGZ92+qLv2FvlcHMN4mtbV+EKX5aBs/sv12WTaWib1NvmXNMSaYHWhPRWix9YM0duI33QmqTz62YFE1wL6x1suvKnP7cGt7McKO7wged3HDN7UDdyx9mpPFzCpQ6LTVA6Kg2byjbrvgqU9/JR8Qevj0e7mfXtLQB5C143FzRUOsw/oD1oqXYKahp0quvwn8ecsETEme55YEvdYhZpD70S9lbSG5StioC/gdein8lndDp6CIVuB5Q9zQLu/+jpsDfNakqbpvBTbmqiDwHVeRd/t9mwRkqBqmk6BibkEw0yTsbM1uqIefJ7+fsJKY/x2ro1deI6iWjK8JoJGhaCNiQ8Ivo7bDA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(131327999870524)(144836121648609); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123558021)(20161123560025)(20161123555025)(6072148); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(189002)(13464003)(24454002)(377454003)(199003)(50986999)(101416001)(76176999)(4326007)(8666005)(7736002)(6436002)(74316002)(6116002)(102836003)(25786008)(76576001)(77096006)(3846002)(6506006)(2906002)(189998001)(5660300001)(305945005)(38730400001)(7696004)(2950100002)(66066001)(3660700001)(99286002)(81156014)(8676002)(81166006)(106356001)(2900100001)(229853002)(9686002)(54356999)(561944003)(8936002)(92566002)(68736007)(105586002)(3280700002)(86362001)(97736004)(122556002)(33656002)(5001770100001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 18:52:34.7184 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Cc: "core@ietf. org WG" Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 18:52:45 -0000 SGkgUmFuZHkNCg0KSW4gdGhlIGNhc2Ugb2YgdGhlIGN1cnJlbnQgQ29NSSBzb2x1dGlvbiwgdGhp cyByZWxhdGlvbnNoaXAgaXMgaW1wbGVtZW50ZWQgdXNpbmcNCmFuIG9ic2VydmVycyBsaXN0IGFz IGRlZmluZWQgYnkgUkZDIDc2NDEgYW5kIGEgRFRMUyBzZXNzaW9uLiBJZiBib3RoIGFyZSBoZWFs dGh5LA0Kbm90aWZpY2F0aW9ucyBjYW4gYmUgdHJhbnNmZXJyZWQuDQoNCk90aGVyIHNvbHV0aW9u cyBtYXkgaW52b2x2ZSBvdGhlciBtZWNoYW5pc21zLg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFR1cm5lciwgUmFuZHkgW21haWx0bzpS YW5keS5UdXJuZXJAbGFuZGlzZ3lyLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTUs IDIwMTYgMToyMiBQTQ0KVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KQ2M6IE1p Y2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT47IGNvcmVA aWV0Zi4gb3JnIFdHIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBDb01JIC0g bG9uZyB0ZXJtIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIG5ldHdvcmsgZWxlbWVudHMgYW5kIG1hbmFn ZW1lbnQgc3RhdGlvbg0KDQpTTk1QIHRyYXBzIGFuZCBpbmZvcm1zIGRvIG5vdCBuZWNlc3Nhcmls eSByZXF1aXJlIGEgbG9uZy10ZXJtIOKAnHJlbGF0aW9uc2hpcOKAnSAtIHRoZWlyIHJlbGF0aW9u c2hpcCBpcyBoaXN0b3JpY2FsbHkgc3RhdGljYWxseSBjb25maWd1cmVkIGFuZCBtYWludGFpbmVk IHN0YXRlbGVzc2x5IC0gdGhlcmXigJlzIG5vIOKAnHJlbGF0aW9uc2hpcOKAnSBsaWtlIGFuIGFj dGl2ZSBUQ1Agc2Vzc2lvbiB0aGF0IGhhcyB0byBiZSBrZXB0IGFsaXZlLg0KTWF5YmUgd2Ugc2hv dWxkIGRlY2lkZSBvbiB0aGUgZGVmaW5pdGlvbiBvZiDigJxyZWxhdGlvbnNoaXDigJ0NCg0KUi4N Cg0KDQo+IE9uIERlYyAxNSwgMjAxNiwgYXQgMTI6NTIgUE0sIENhcnN0ZW4gQm9ybWFubiA8Y2Fi b0B0emkub3JnPiB3cm90ZToNCj4gDQo+IA0KPj4gT24gMTUgRGVjIDIwMTYsIGF0IDE4OjMxLCBN aWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+IHdyb3Rl Og0KPj4gDQo+PiBIb3cgdGhpcyBjb25jZXB0IG9mIGxvbmcgdGVybSByZWxhdGlvbnNoaXAgYmV0 d2VlbiBuZXR3b3JrIGVsZW1lbnRzICANCj4+IGFuZCBhIG1hbmFnZW1lbnQgc3RhdGlvbiBzaG91 bGQgYmUgYWRkcmVzZWQ/DQo+IA0KPiBDT01JIGlzIG5vdCB0aGUgb25seSBDb0FQIHVzZXIgdGhh dCBpcyBydW5uaW5nIGludG8gdGhlIG5lZWQgZm9yIGxvbmctdGVybSBvYnNlcnZhdGlvbi4NCj4g SSB0aGluayB3ZSBzaG91bGQgc29sdmUgdGhpcyBpbiBhIG1vcmUgZ2VuZXJhbCB3YXkuDQo+IChO b3RlIHRoYXQgdGhlcmUgaXMgYSBwcm9wb3NhbCBhYm91dCDigJxkZWxlZ2F0ZWQgb2JzZXJ2ZeKA nSByaWdodCBub3c7IA0KPiB0aGVyZSBhbHNvIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgZ29v ZCB3YXlzIHRvIHVzZSBPYnNlcnZlIGF0IHRoZSANCj4gTHVkd2lnc2J1cmcgVDJUUkcgbWVldGlu Zy4pDQo+IA0KPj4gU2hvdWxkIHRoZSBDb01JIGRyYWZ0IHJlZGVmaW5lIGhvdyB0aGUgbGlzdCBv ZiBvYnNlcnZlcnMgaXMgbWFuYWdlZCBieSB0aGUgb2JzZXJ2ZSBtZWNoYW5pc20/DQo+IA0KPiBU aGUgQ09NSSBkcmFmdCBjb3VsZCBiZSBhIHBsYWNlIHRvIGRvIHRoaXMsIGJ1dCBhbiBpbmRlcGVu ZGVudCBkcmFmdCBzb3VuZHMgYmV0dGVyLg0KPiANCj4+IFNob3VsZCBDb01JIGNsaWVudHMgc2Vu ZCBub3RpZmljYXRpb25zIG9ubHkgd2l0aCBub24tY29uZmlybWFibGUgQ29BUCBtZXNzYWdlPw0K PiANCj4gVW5yZWxpYWJpbGl0eSB3YXMgYSBiaWcgcHJvYmxlbSB3aXRoIFNOTVAgdHJhcHM7IHdl IHByb2JhYmx5IGRvbuKAmXQgd2FudCB0byByZXBlYXQgdGhhdCBwcm9ibGVtLg0KPiANCj4+IFNo b3VsZCBDb01JIHNlcnZlcnMgKGkuZS4gbWFuYWdlbWVudCBzdGF0aW9ucykgcGVyaW9kaWNhbGx5 IHJlLXJlZ2lzdGVyIGFzIGFuIG9ic2VydmVyIChlLmcuIGV2ZXJ5IGRheSk/DQo+IA0KPiBNb3N0 IGxpa2VseSwgc29tZXRoaW5nIGxpa2UgdGhpcyB3aWxsIG5lZWQgdG8gYmUgZG9uZSBhbnl3YXkg KG1hbmFnZW1lbnQgd2lsbCB3YW50IHRvIGtub3cgdGhhdCB0aGUgZGV2aWNlIGlzIHN0aWxsIHRo ZXJlKS4gIEJ1dCB3ZSBzaG91bGQgZGVmaW5lIHRoZSBkZXRhaWxzIGluIGEgd2F5IHRoYXQgaXMg YXMgdXNlZnVsIGFzIHBvc3NpYmxlIHRvIG1hbmFnZW1lbnQgYXBwbGljYXRpb25zLg0KPiANCj4+ IFNob3VsZCB3ZSBhZG9wdCBhIGRpZmZlcmVudCBtZXRob2QgdG8gdHJhbnNmZXIgbm90aWZpY2F0 aW9ucz8NCj4gDQo+IEZvciBwZW9wbGUgdXNlZCB0byBIVFRQLCB1c2luZyBhIFBPU1QgZnJvbSB0 aGUgc2VydmVyIHRvIHRoZSBjbGllbnQgYWx3YXlzIHNlZW1zIHRoZSBvYnZpb3VzIHNvbHV0aW9u IOKAlCBhZnRlciBhbGwsIHRoYXTigJlzIGFsbCB0aGF0IGNsYXNzaWMgSFRUUCBjYW4gZG8uICBI VFRQIGlzIGdyb3dpbmcgbmV3IGZ1bmN0aW9uYWxpdHkgaW4gdGhpcyBzcGFjZSBub3cgKGUuZy4s IFJGQzgwMzAgV2VicHVzaCksIGFuZCB3ZSBzaG91bGQgcGF5IGF0dGVudGlvbi4NCj4gDQo+IEdy w7zDn2UsIENhcnN0ZW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Thu Dec 15 10:55:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF212943D for ; Thu, 15 Dec 2016 10:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 GB6QtpVEAbvJ for ; Thu, 15 Dec 2016 10:55:09 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0091.outbound.protection.outlook.com [104.47.2.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EAEC129C28 for ; Thu, 15 Dec 2016 10:55:08 -0800 (PST) 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=2DqhDtFKkKe5oa4VYkwpcx/UlmsKSMrPeX6OvEOghAo=; b=GMM+bdtvr8J5wxapI+Dv/C4KDnteCIYKP11rNEmQ2oHs9Mjz+ayYBNlhtS5SNfWUbnUkhQSGMrVfJRdc2ZS5tHQ3yRlrA6bUMD3RdAOUejAznHEAPU7R4kHzIhE6HJuNrHge755UrK8dL7nTJCyBqOa2Bw6d0ZM/ofkALj6D+zg= Received: from HE1PR01MB1546.eurprd01.prod.exchangelabs.com (10.164.30.156) by HE1PR01MB1548.eurprd01.prod.exchangelabs.com (10.164.30.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Thu, 15 Dec 2016 18:55:04 +0000 Received: from HE1PR01MB1546.eurprd01.prod.exchangelabs.com ([10.164.30.156]) by HE1PR01MB1546.eurprd01.prod.exchangelabs.com ([10.164.30.156]) with mapi id 15.01.0761.022; Thu, 15 Dec 2016 18:55:04 +0000 From: "Turner, Randy" To: Michel Veillette Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAABNvwAAAEKSYAAAOHYAAAARcuA Date: Thu, 15 Dec 2016 18:55:04 +0000 Message-ID: <7A4DFA52-53D4-4EC8-807E-7B390523C133@landisgyr.com> References: <00A2C066-0F47-4E77-ACB7-9412E5CF09F3@tzi.org> <3D786F04-4AF0-4FCF-BCD8-1F0A255DED4C@landisgyr.com> In-Reply-To: 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-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:cb:c000:8248:e09d:f978:b422:d7ad] x-ms-office365-filtering-correlation-id: 798829d6-8b1a-4588-d03b-08d4251be19a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR01MB1548; x-microsoft-exchange-diagnostics: 1; HE1PR01MB1548; 7:FsLqN+lNW0OjTxX1bdOkpnuJlJqeI5NeZZpBRzlax/5TQIaH6DHtecz9G11FKZ+jtsb3geK4gHOIR84xq0YiH32xFEniCpejydTdfVWyrg1FppEY+8/q52kYba/V/2oZ5t8iarGDRvIAEa/0AWm6Xm2qB3+9A4Jnk/uR+5aZK+iqLJNFAZCgGF0j7hWrCIHSUXJQki9Z58ntlMPIuOLJvW8IOD09nm3tIKwmoZ2YUbuwIAH6P6ZLlZg1mv2E9IMRBWXSVTH0zzds+uFEf+7jE6BK40K/s4Pn33buyb2i2PHirOOzC/uk1LPgaWoO77BXKOs7HhNlZhfvDjurhdb7sQauDV0rmwy3vE9RwtaQhtBg46FiEngMhFJPgGiiKAF9Xm7ZM8nGjVvOPZ1WUsNzDPbV5VR/dwCPgQK16STfUjIe8lVb+CCVaQJrDje54vppgT4WwEem89vFPkeuxaue3A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(131327999870524)(144836121648609); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:HE1PR01MB1548; BCL:0; PCL:0; RULEID:; SRVR:HE1PR01MB1548; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(24454002)(199003)(51694002)(13464003)(377454003)(189002)(101416001)(8676002)(86362001)(8936002)(3280700002)(76176999)(54356999)(6486002)(6512006)(2900100001)(33656002)(305945005)(122556002)(77096006)(561944003)(81156014)(81166006)(36756003)(229853002)(3660700001)(6506006)(92566002)(7736002)(50986999)(68736007)(6436002)(38730400001)(110136003)(5660300001)(93886004)(2950100002)(82746002)(189998001)(102836003)(97736004)(6916009)(6116002)(105586002)(106356001)(83716003)(4326007)(2906002)(25786008)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR01MB1548; H:HE1PR01MB1546.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: text/plain; charset="utf-8" Content-ID: <44E711C3376776418C51CC5A10BA1002@eurprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 18:55:04.3214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR01MB1548 Archived-At: Cc: "core@ietf. org WG" Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 18:55:11 -0000 WWVzLCBJIHVuZGVyc3RhbmQgLSBJIGp1c3Qgd2FudGVkIHRvIGNsYXJpZnkgdGhhdCBpdCBtYXkg YmUgZGlmZmljdWx0IHRvIGNyZWF0ZSBhIHJlbGF0aW9uc2hpcCB3aXRoIENvQVAgdGhhdCByZXNl bWJsZXMgU05NUCAtIHRoZXkgbWF5IHNlcnZlIHRoZSBzYW1lIHB1cnBvc2UsIGJ1dCB0aGVpciBp bXBsZW1lbnRhdGlvbnMgbWF5IGJlIHF1aXRlIGRpZmZlcmVudC4NCg0KSSBhZ3JlZSB3aXRoIENh cnN0ZW4gdGhhdCBhIG1vcmUgZ2VuZXJhbCBzb2x1dGlvbiBtaWdodCBiZSB0aGUgd2F5IHRvIGdv LCB3aXRoIENvTUkgYSBmaXJzdC1jdXQgYXQgdGhpcyBnZW5lcmFsIHNvbHV0aW9uLg0KDQpSLg0K DQoNCj4gT24gRGVjIDE1LCAyMDE2LCBhdCAxOjUyIFBNLCBNaWNoZWwgVmVpbGxldHRlIDxNaWNo ZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+IHdyb3RlOg0KPiANCj4gSGkgUmFuZHkNCj4g DQo+IEluIHRoZSBjYXNlIG9mIHRoZSBjdXJyZW50IENvTUkgc29sdXRpb24sIHRoaXMgcmVsYXRp b25zaGlwIGlzIGltcGxlbWVudGVkIHVzaW5nDQo+IGFuIG9ic2VydmVycyBsaXN0IGFzIGRlZmlu ZWQgYnkgUkZDIDc2NDEgYW5kIGEgRFRMUyBzZXNzaW9uLiBJZiBib3RoIGFyZSBoZWFsdGh5LA0K PiBub3RpZmljYXRpb25zIGNhbiBiZSB0cmFuc2ZlcnJlZC4NCj4gDQo+IE90aGVyIHNvbHV0aW9u cyBtYXkgaW52b2x2ZSBvdGhlciBtZWNoYW5pc21zLg0KPiANCj4gUmVnYXJkcywNCj4gTWljaGVs DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVHVybmVyLCBS YW5keSBbbWFpbHRvOlJhbmR5LlR1cm5lckBsYW5kaXNneXIuY29tXSANCj4gU2VudDogVGh1cnNk YXksIERlY2VtYmVyIDE1LCAyMDE2IDE6MjIgUE0NCj4gVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fi b0B0emkub3JnPg0KPiBDYzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmls bGlhbnRpbmMuY29tPjsgY29yZUBpZXRmLiBvcmcgV0cgPGNvcmVAaWV0Zi5vcmc+DQo+IFN1Ympl Y3Q6IFJlOiBbY29yZV0gQ29NSSAtIGxvbmcgdGVybSByZWxhdGlvbnNoaXAgYmV0d2VlbiBuZXR3 b3JrIGVsZW1lbnRzIGFuZCBtYW5hZ2VtZW50IHN0YXRpb24NCj4gDQo+IFNOTVAgdHJhcHMgYW5k IGluZm9ybXMgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcXVpcmUgYSBsb25nLXRlcm0g4oCccmVsYXRp b25zaGlw4oCdIC0gdGhlaXIgcmVsYXRpb25zaGlwIGlzIGhpc3RvcmljYWxseSBzdGF0aWNhbGx5 IGNvbmZpZ3VyZWQgYW5kIG1haW50YWluZWQgc3RhdGVsZXNzbHkgLSB0aGVyZeKAmXMgbm8g4oCc cmVsYXRpb25zaGlw4oCdIGxpa2UgYW4gYWN0aXZlIFRDUCBzZXNzaW9uIHRoYXQgaGFzIHRvIGJl IGtlcHQgYWxpdmUuDQo+IE1heWJlIHdlIHNob3VsZCBkZWNpZGUgb24gdGhlIGRlZmluaXRpb24g b2Yg4oCccmVsYXRpb25zaGlw4oCdDQo+IA0KPiBSLg0KPiANCj4gDQo+PiBPbiBEZWMgMTUsIDIw MTYsIGF0IDEyOjUyIFBNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+ PiANCj4+IA0KPj4+IE9uIDE1IERlYyAyMDE2LCBhdCAxODozMSwgTWljaGVsIFZlaWxsZXR0ZSA8 TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPiB3cm90ZToNCj4+PiANCj4+PiBIb3cg dGhpcyBjb25jZXB0IG9mIGxvbmcgdGVybSByZWxhdGlvbnNoaXAgYmV0d2VlbiBuZXR3b3JrIGVs ZW1lbnRzICANCj4+PiBhbmQgYSBtYW5hZ2VtZW50IHN0YXRpb24gc2hvdWxkIGJlIGFkZHJlc2Vk Pw0KPj4gDQo+PiBDT01JIGlzIG5vdCB0aGUgb25seSBDb0FQIHVzZXIgdGhhdCBpcyBydW5uaW5n IGludG8gdGhlIG5lZWQgZm9yIGxvbmctdGVybSBvYnNlcnZhdGlvbi4NCj4+IEkgdGhpbmsgd2Ug c2hvdWxkIHNvbHZlIHRoaXMgaW4gYSBtb3JlIGdlbmVyYWwgd2F5Lg0KPj4gKE5vdGUgdGhhdCB0 aGVyZSBpcyBhIHByb3Bvc2FsIGFib3V0IOKAnGRlbGVnYXRlZCBvYnNlcnZl4oCdIHJpZ2h0IG5v dzsgDQo+PiB0aGVyZSBhbHNvIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgZ29vZCB3YXlzIHRv IHVzZSBPYnNlcnZlIGF0IHRoZSANCj4+IEx1ZHdpZ3NidXJnIFQyVFJHIG1lZXRpbmcuKQ0KPj4g DQo+Pj4gU2hvdWxkIHRoZSBDb01JIGRyYWZ0IHJlZGVmaW5lIGhvdyB0aGUgbGlzdCBvZiBvYnNl cnZlcnMgaXMgbWFuYWdlZCBieSB0aGUgb2JzZXJ2ZSBtZWNoYW5pc20/DQo+PiANCj4+IFRoZSBD T01JIGRyYWZ0IGNvdWxkIGJlIGEgcGxhY2UgdG8gZG8gdGhpcywgYnV0IGFuIGluZGVwZW5kZW50 IGRyYWZ0IHNvdW5kcyBiZXR0ZXIuDQo+PiANCj4+PiBTaG91bGQgQ29NSSBjbGllbnRzIHNlbmQg bm90aWZpY2F0aW9ucyBvbmx5IHdpdGggbm9uLWNvbmZpcm1hYmxlIENvQVAgbWVzc2FnZT8NCj4+ IA0KPj4gVW5yZWxpYWJpbGl0eSB3YXMgYSBiaWcgcHJvYmxlbSB3aXRoIFNOTVAgdHJhcHM7IHdl IHByb2JhYmx5IGRvbuKAmXQgd2FudCB0byByZXBlYXQgdGhhdCBwcm9ibGVtLg0KPj4gDQo+Pj4g U2hvdWxkIENvTUkgc2VydmVycyAoaS5lLiBtYW5hZ2VtZW50IHN0YXRpb25zKSBwZXJpb2RpY2Fs bHkgcmUtcmVnaXN0ZXIgYXMgYW4gb2JzZXJ2ZXIgKGUuZy4gZXZlcnkgZGF5KT8NCj4+IA0KPj4g TW9zdCBsaWtlbHksIHNvbWV0aGluZyBsaWtlIHRoaXMgd2lsbCBuZWVkIHRvIGJlIGRvbmUgYW55 d2F5IChtYW5hZ2VtZW50IHdpbGwgd2FudCB0byBrbm93IHRoYXQgdGhlIGRldmljZSBpcyBzdGls bCB0aGVyZSkuICBCdXQgd2Ugc2hvdWxkIGRlZmluZSB0aGUgZGV0YWlscyBpbiBhIHdheSB0aGF0 IGlzIGFzIHVzZWZ1bCBhcyBwb3NzaWJsZSB0byBtYW5hZ2VtZW50IGFwcGxpY2F0aW9ucy4NCj4+ IA0KPj4+IFNob3VsZCB3ZSBhZG9wdCBhIGRpZmZlcmVudCBtZXRob2QgdG8gdHJhbnNmZXIgbm90 aWZpY2F0aW9ucz8NCj4+IA0KPj4gRm9yIHBlb3BsZSB1c2VkIHRvIEhUVFAsIHVzaW5nIGEgUE9T VCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCBhbHdheXMgc2VlbXMgdGhlIG9idmlvdXMg c29sdXRpb24g4oCUIGFmdGVyIGFsbCwgdGhhdOKAmXMgYWxsIHRoYXQgY2xhc3NpYyBIVFRQIGNh biBkby4gIEhUVFAgaXMgZ3Jvd2luZyBuZXcgZnVuY3Rpb25hbGl0eSBpbiB0aGlzIHNwYWNlIG5v dyAoZS5nLiwgUkZDODAzMCBXZWJwdXNoKSwgYW5kIHdlIHNob3VsZCBwYXkgYXR0ZW50aW9uLg0K Pj4gDQo+PiBHcsO8w59lLCBDYXJzdGVuDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBjb3JlIG1haWxpbmcgbGlzdA0KPj4gY29yZUBp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+ IA0KDQo= From nobody Thu Dec 15 23:30:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9C129C6A for ; Thu, 15 Dec 2016 23:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f597IksZzHAF for ; Thu, 15 Dec 2016 23:30:00 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4976D129AA9 for ; Thu, 15 Dec 2016 23:30:00 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id LXVw1u0054K0fSy01XVwTR; Fri, 16 Dec 2016 08:29:58 +0100 Received: from 2001:983:a264:1:7800:e1c4:c8d2:128a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 16 Dec 2016 08:29:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 16 Dec 2016 08:29:56 +0100 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <00A2C066-0F47-4E77-ACB7-9412E5CF09F3@tzi.org> References: <00A2C066-0F47-4E77-ACB7-9412E5CF09F3@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl (SKiTFVlaifsmTXhSOL8ivn38bo47ChX9) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 07:30:02 -0000 > >> Should the CoMI draft redefine how the list of observers is managed by >> the observe mechanism? > > The COMI draft could be a place to do this, but an independent draft > sounds better. I am in favour of an independent draft. These long term relationships might be very loose indeed like let's wait some time and see what happens, or very tight where every packet loss is a disaster. > >> Should CoMI clients send notifications only with non-confirmable CoAP >> message? > > Unreliability was a big problem with SNMP traps; we probably don’t > want to repeat that problem. I expect that unnecessary repetitions caused by lost acks are not an issue. > >> Should CoMI servers (i.e. management stations) periodically >> re-register as an observer (e.g. every day)? > > Most likely, something like this will need to be done anyway > (management will want to know that the device is still there). But we > should define the details in a way that is as useful as possible to > management applications. > As far as I know, all relations between computers are restricted in time. How often reminders (extensions) need to be sent should be an application parameter in many cases. Cheerio, Peter From nobody Thu Dec 15 23:47:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2FC129EC6 for ; Thu, 15 Dec 2016 23:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZROKzQGkvCiC for ; Thu, 15 Dec 2016 23:47:23 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF1A129EBB for ; Thu, 15 Dec 2016 23:47:22 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id LXnM1u0014K0fSy01XnMcq; Fri, 16 Dec 2016 08:47:21 +0100 Received: from 2001:983:a264:1:7800:e1c4:c8d2:128a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 16 Dec 2016 08:47:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 16 Dec 2016 08:47:21 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> X-Sender: stokcons@xs4all.nl (A1nmOqIJVmp46pT2oaOTxwenwChwu4IS) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 07:47:25 -0000 Hi Michel, Interesting subject. I remember the long discussions taking place with respect to the observe draft. Given the wide set of interests, these discussions were not easy and sometimes ran in loops. See my comments below. Michel Veillette schreef op 2016-12-15 18:31: > Hi Peter > > The current CoMI draft rely on the observe mechanism [RFC 7641] to > transfer YANG notifications. > A common use of these YANG notifications is the implementation of what > was called in SNMP, traps. > Traps are typically sent to a management station (e.g. NMS) to notify > this station of significant events. > > This mechanism typically require a long term relationship between > network elements (CoMI servers) > and a management station (CoMI client). However, RFC 7641 section 4.5. > Transmission, required that > this relationship is terminated at the first unsuccessful transmission. > > "or if the last attempt to retransmit a confirmable > notification times out, then the client is considered no longer > interested and the server MUST remove the associated entry from the > list of observers." I find this text perfectly reasonable and probably covers a wide range of network problems. As far as I know deciding whether the processor is faced with a network problem or a failing communication partner is unsolvable; unless we start incorporating stable storage. > > How this concept of long term relationship between network elements > and a management station > should be addresed? Good question. > > Should the CoMI draft redefine how the list of observers is managed by > the observe mechanism? > Should CoMI clients send notifications only with non-confirmable CoAP > message? Seems undesirable to me; you really want to know when there is a cmmunication problem to take other analysis or recovery actions. > Should CoMI servers (i.e. management stations) periodically > re-register as an observer (e.g. every day)? Sounds reasonable to me. Applications can decide how often and under which conditions. > Should we adopt a different method to transfer notifications? For the moment I am reluctant to choose this option. By the way, we have a connected probem in the bootstrap where a processor waits for a response but the time to wait is undetermined (2 seconds to hours) > > Regards, > > Michel Veillette cheerio, Peter From nobody Fri Dec 16 01:19:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCA4129462 for ; Fri, 16 Dec 2016 01:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_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 tHIevofFqZPh for ; Fri, 16 Dec 2016 01:19:30 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C7C129461 for ; Fri, 16 Dec 2016 01:19:30 -0800 (PST) Received: from [IPv6:2001:660:7301:3728:20ec:fd41:a94c:4d3f] (unknown [IPv6:2001:660:7301:3728:20ec:fd41:a94c:4d3f]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 99A891720A4; Fri, 16 Dec 2016 10:19:24 +0100 (CET) From: Alexander Pelov Message-Id: <6EAC8028-7274-4BB0-A6EA-62096B4EEF23@ackl.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE399EE-8CD8-43D5-A7B8-C766CC6B2669" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Fri, 16 Dec 2016 10:19:25 +0100 In-Reply-To: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> To: consultancy@vanderstok.org References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 09:19:33 -0000 --Apple-Mail=_FBE399EE-8CD8-43D5-A7B8-C766CC6B2669 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, This indeed is a good question we need to address. Personally, I=E2=80=99d= be in favor of having a more lean CoMI document and handle the more = advanced functions in a separate document (ideally, through a YANG = module). I don=E2=80=99t have strong feelings in either direction, = though. I wouldn=E2=80=99t block a call for adoption for a question like this, = e.g. ideally it would be up to the group to decide. Best, Alexander > Le 16 d=C3=A9c. 2016 =C3=A0 08:47, peter van der Stok = a =C3=A9crit : >=20 > Hi Michel, >=20 > Interesting subject. > I remember the long discussions taking place with respect to the = observe draft. > Given the wide set of interests, these discussions were not easy and = sometimes ran in loops. >=20 > See my comments below. >=20 > Michel Veillette schreef op 2016-12-15 18:31: >> Hi Peter >> The current CoMI draft rely on the observe mechanism [RFC 7641] to >> transfer YANG notifications. >> A common use of these YANG notifications is the implementation of = what >> was called in SNMP, traps. >> Traps are typically sent to a management station (e.g. NMS) to notify >> this station of significant events. >> This mechanism typically require a long term relationship between >> network elements (CoMI servers) >> and a management station (CoMI client). However, RFC 7641 section = 4.5. >> Transmission, required that >> this relationship is terminated at the first unsuccessful = transmission. >> "or if the last attempt to retransmit a confirmable >> notification times out, then the client is considered no longer >> interested and the server MUST remove the associated entry from the >> list of observers." >=20 > I find this text perfectly reasonable and probably covers a wide range = of network problems. > As far as I know deciding whether the processor is faced with a = network problem or a failing communication partner is unsolvable; unless = we start incorporating stable storage. >=20 >> How this concept of long term relationship between network elements >> and a management station >> should be addresed? >=20 > Good question. >> Should the CoMI draft redefine how the list of observers is managed = by >> the observe mechanism? >> Should CoMI clients send notifications only with non-confirmable CoAP = message? >=20 > Seems undesirable to me; you really want to know when there is a = cmmunication problem to take other analysis or recovery actions. >=20 >> Should CoMI servers (i.e. management stations) periodically >> re-register as an observer (e.g. every day)? >=20 > Sounds reasonable to me. Applications can decide how often and under = which conditions. >> Should we adopt a different method to transfer notifications? >=20 > For the moment I am reluctant to choose this option. > By the way, we have a connected probem in the bootstrap where a = processor waits for a response but the time to wait is undetermined (2 = seconds to hours) >=20 >> Regards, >> Michel Veillette >=20 > cheerio, >=20 > Peter >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_FBE399EE-8CD8-43D5-A7B8-C766CC6B2669 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all,

This indeed is a good question we need = to address. Personally, I=E2=80=99d be in favor of having a more lean = CoMI document and handle the more advanced functions in a separate = document (ideally, through a YANG module). I don=E2=80=99t have strong = feelings in either direction, though.

I wouldn=E2=80=99t block a call for = adoption for a question like this, e.g. ideally it would be up to the = group to decide.

Best,
Alexander



Le = 16 d=C3=A9c. 2016 =C3=A0 08:47, peter van der Stok <stokcons@xs4all.nl> = a =C3=A9crit :

Hi Michel,

Interesting subject.
I remember the long = discussions taking place with respect to the observe draft.
Given the wide set = of interests, these discussions were not easy and sometimes ran in = loops.

See my comments = below.

Michel Veillette = schreef op 2016-12-15 18:31:
Hi Peter
The = current CoMI draft rely on the observe mechanism [RFC 7641]  to
transfer YANG notifications.
A common use of = these YANG notifications is the implementation of what
was = called in SNMP, traps.
Traps are typically sent to a = management station (e.g. NMS) to notify
this station of = significant events.
This mechanism typically require a = long term relationship between
network elements (CoMI = servers)
and a management station (CoMI client). However, = RFC 7641 section 4.5.
Transmission, required that
this relationship is terminated at the first unsuccessful = transmission.
  "or if the last attempt to = retransmit a confirmable
  notification times = out, then the client is considered no longer
  interested and the server MUST remove the = associated entry from the
  list of = observers."

I find this text perfectly reasonable and = probably covers a wide range of network problems.
As far as I know = deciding whether the processor is faced with a network problem or a = failing communication partner is unsolvable; unless we start = incorporating stable storage.

How this concept of long = term relationship between network elements
and a = management station
should be addresed?

Good question.
Should the CoMI draft = redefine how the list of observers is managed by
the = observe mechanism?
Should CoMI clients send notifications = only with non-confirmable CoAP message?

Seems undesirable = to me; you really want to know when there is a cmmunication problem to = take other analysis or recovery actions.

Should CoMI servers (i.e. = management stations) periodically
re-register as an = observer (e.g. every day)?

Sounds reasonable = to me. Applications can decide how often and under which = conditions.
Should we adopt a different = method to transfer notifications?

For the moment I am = reluctant to choose this option.
By the way, we have a connected probem in = the bootstrap where a processor waits for a response but the time to = wait is undetermined (2 seconds to hours)

Regards,
Michel = Veillette

cheerio,

Peter

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

= --Apple-Mail=_FBE399EE-8CD8-43D5-A7B8-C766CC6B2669-- From nobody Fri Dec 16 08:18:11 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6258129883 for ; Fri, 16 Dec 2016 08:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2cmsUQNcuTC for ; Fri, 16 Dec 2016 08:18:04 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0127.outbound.protection.outlook.com [104.47.41.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819A41296E3 for ; Fri, 16 Dec 2016 08:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L7kadGO18GiS9+2mOaY7l/jlmaIVzwbf7msIjUYXarM=; b=YnhwQ586ohqry/zul6WnlUX0AQs53CpnHsRMnVjtG5fREiSqbQrKAnvIb0izFdFhtjQV/+psaaICPAkBcnyTOX7b0NkdUHGQ1Tt5VnW2u0zlmdpT37kd85xjuywK1MDmk3bJfYrRZ2ZwztW+Wswaq6EnFRjn4QwVRvOtKlkw6FY= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2306.namprd06.prod.outlook.com (10.173.19.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Fri, 16 Dec 2016 16:17:19 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0771.017; Fri, 16 Dec 2016 16:17:19 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAAeYc+AABGsPEA= Date: Fri, 16 Dec 2016 16:17:18 +0000 Message-ID: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> In-Reply-To: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 3aba5e67-613e-4765-4377-08d425cf0234 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2306; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2306; 7:LCJXOrZrfPxtE+CW+1pvzhjlaYNnpsrP02TG7tV+gx/g9TLIS9jZY4oE8PbGxpDgFIF0s5nGmufYJ309hh5MIoJgr6MapbejmiZmnkMXP0aSwWrZbV2WWji7Gha4JjR8Ve+BBh+gQuQdzxCn34NIt8M1Ck58y17sVbjxNSkT32b2nS8l5vAnPEZqD7VtsJpOucA780qmlPDBInkPkidccYN940CCzzuK9JiW3UMWH6/sfen7q+qrts6hL5HAAkPyh5sPs3+nZwDiD2uUOXnmA7wiuZFS113+sTK4J6ZQUEjyysbGKBOzSnNFsRwavvxgVHn+dcxbhnlXmPHE7DEENAr7Y1xLnPb1IR09LDWBRVnJfd5RU7hYAz1yiY/m6LDLRfsqh0YGLI5PuUFqI6tWpN4y594D/DNJ0Ai8h5oqffPBFbnKeaxviRTbLqRlPecQ9AYrnOquHttbJ/AhJ7lo0A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(278428928389397)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN6PR06MB2306; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2306; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39450400003)(377454003)(199003)(189002)(377424004)(13464003)(3660700001)(97736004)(81156014)(1730700003)(81166006)(2900100001)(99286002)(8676002)(106356001)(105586002)(50986999)(8936002)(54356999)(74316002)(101416001)(76176999)(9686002)(4001150100001)(66066001)(102836003)(5660300001)(4326007)(3846002)(68736007)(92566002)(189998001)(76576001)(6116002)(7736002)(305945005)(2351001)(110136003)(7696004)(2950100002)(6916009)(33656002)(86362001)(3280700002)(2906002)(229853002)(77096006)(6436002)(6506006)(2501003)(38730400001)(25786008)(5640700003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2306; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 16:17:19.0038 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2306 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 16:18:10 -0000 Hi Peter About " By the way, we have a connected probem in the bootstrap where a=20 processor waits for a response but the time to wait is undetermined (2=20 seconds to hours)" What king of problems are you anticipating in this case? On the CoAP side, I see no issues about waiting for a response multiple hou= rs, see section 5.2.2. "Note also that, while the CoAP protocol itself does not make any specific demands here, there is an expectation that the response will come within a time frame that is reasonable from an application point of view. As there is no underlying transport protocol that could be instructed to run a keep-alive mechanism, the requester may want to set up a timeout that is unrelated to CoAP's retransmission timers in case the server is destroyed or otherwise unable to send the response." Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Friday, December 16, 2016 2:47 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: Re: CoMI - long term relationship between network elements and man= agement station Hi Michel, Interesting subject. I remember the long discussions taking place with respect to the observe dr= aft. Given the wide set of interests, these discussions were not easy and someti= mes ran in loops. See my comments below. Michel Veillette schreef op 2016-12-15 18:31: > Hi Peter >=20 > The current CoMI draft rely on the observe mechanism [RFC 7641] to=20 > transfer YANG notifications. > A common use of these YANG notifications is the implementation of what=20 > was called in SNMP, traps. > Traps are typically sent to a management station (e.g. NMS) to notify=20 > this station of significant events. >=20 > This mechanism typically require a long term relationship between=20 > network elements (CoMI servers) and a management station (CoMI=20 > client). However, RFC 7641 section 4.5. > Transmission, required that > this relationship is terminated at the first unsuccessful transmission. >=20 > "or if the last attempt to retransmit a confirmable > notification times out, then the client is considered no longer > interested and the server MUST remove the associated entry from the > list of observers." I find this text perfectly reasonable and probably covers a wide range of n= etwork problems. As far as I know deciding whether the processor is faced with a network pro= blem or a failing communication partner is unsolvable; unless we start inco= rporating stable storage. >=20 > How this concept of long term relationship between network elements > and a management station > should be addresed? Good question. >=20 > Should the CoMI draft redefine how the list of observers is managed by > the observe mechanism? > Should CoMI clients send notifications only with non-confirmable CoAP=20 > message? Seems undesirable to me; you really want to know when there is a=20 cmmunication problem to take other analysis or recovery actions. > Should CoMI servers (i.e. management stations) periodically > re-register as an observer (e.g. every day)? Sounds reasonable to me. Applications can decide how often and under=20 which conditions. > Should we adopt a different method to transfer notifications? For the moment I am reluctant to choose this option. By the way, we have a connected probem in the bootstrap where a=20 processor waits for a response but the time to wait is undetermined (2=20 seconds to hours) >=20 > Regards, >=20 > Michel Veillette cheerio, Peter From nobody Fri Dec 16 09:05:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897E812986F for ; Fri, 16 Dec 2016 09:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLYJ02xWwNrq for ; Fri, 16 Dec 2016 09:05:53 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0121.outbound.protection.outlook.com [104.47.34.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418921296F8 for ; Fri, 16 Dec 2016 08:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tWOwPuAtyXy/Vwx+ur6VmlKR+qy9U5ttpTyqPXeKzk8=; b=Vc4ELsAmcK8Bk5TKxpkNRGQ2R1qUTZsmyVtMqfcN1PIdjeP9mvLEZfHik1kjK6mWcsx/53FG0k1Yi9MRmuhPbbt3+znGj6sbUXC+QFCuWSnVUVvzz7ww3H907Z+FFnbJ4ZPMHjSgODiaxTzkKshpAS+z3gpTenRs4mIX+7IdtKE= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Fri, 16 Dec 2016 16:56:28 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0771.017; Fri, 16 Dec 2016 16:56:28 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAAeYc+AABHhG3A= Date: Fri, 16 Dec 2016 16:56:28 +0000 Message-ID: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> In-Reply-To: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 7465ef55-258b-4e3e-b356-08d425d47a63 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2307; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 7:JY5USJAClJzdLou9ZuX5KgvAEhtAAVI1xh4nDQvH+pyJjnu36+SUHIWNqEpMasQPL4+F9odTtKrod6KJDzyogoHefDlvr1j+b+NRy4vDqQ4wS1B5CEyp02xulfh4Yu1Bau1LmxZQd4ycBjQdtdHi76t0JgTrlokJfYxNz5NCUkHJBfavgEQm6Pg2ksUPZVfCOklIbCKle/SILCGC3jKZKMacsRDFPGdykMj6JQbVTZnIGliagTwYG3sl6Bglg3L1SXYPwtFPnHFrLELTjUrTwnnu2s5MflDrokHIicIUDPyxsx80F0hfmT8IeNy8P3AiWoiD1eAVruNLe80q1ASidw0H+SSfpvMPhFF6gkmFG2TRZQpIkAR9IzMH0E2tvw2NG4CKmSBg4eTFQ6i6jKTYJo5iP+0GDU2DsxaOiNd1WWzfDUp7TK2JvyDJPPxGb3b9NveJ14vBnJcEt69PnXZOww== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(278428928389397)(192374486261705)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39450400003)(189002)(377454003)(377424004)(199003)(13464003)(2501003)(2950100002)(99286002)(6916009)(106356001)(76176999)(50986999)(54356999)(105586002)(7696004)(38730400001)(3660700001)(122556002)(110136003)(4326007)(97736004)(86362001)(76576001)(101416001)(2906002)(5660300001)(189998001)(305945005)(2900100001)(68736007)(66066001)(3846002)(8676002)(6116002)(7736002)(2351001)(102836003)(1730700003)(81156014)(92566002)(25786008)(6436002)(5640700003)(81166006)(4001150100001)(74316002)(9686002)(33656002)(8936002)(6506006)(77096006)(3280700002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 16:56:28.0519 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:05:54 -0000 Hi Peter To resolve this issue (long term relationship between network elements and = management station), my personal preference is to extend the current observe mechanism to make = it more resilient to transmission failures. For example, a new set of attributes can be added to implement an applicati= on level retry mechanism on top of the already existing CoAP retry mechanism. SKIP_ON_TX_ERROR If true, the current notification is dropped on transmission failure. Th= e subsequent attempt is performed with the next notification. If false, the subsequent attempt is performed with the same notificatio= n. MIN_DELAY_BETWEEN_TX_ERROR Minimum delay in seconds before sending the next notification after a tr= ansmission failure. This value is double after each consecutive transmission failure. MAX_DELAY_BETWEEN_TX_ERROR Maximum delay in seconds before sending the next notification after a tr= ansmission failure. MAX_CONSECUTIVE_TX_ERROR Number of consecutive transmission failures after which the client is re= moved form the list of observers. This resilience is required to address use cases like: - Maintenance of the management system (NMS). It is not desirable to see al= l nodes sending a notification during a down time of the management system be automatical= ly un-registered. - When security critical notifications are transferred. The drop of a singl= e of these notifications should not prevent all subsequent notifications to be at lest attempted. Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Friday, December 16, 2016 2:47 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: Re: CoMI - long term relationship between network elements and man= agement station Hi Michel, Interesting subject. I remember the long discussions taking place with respect to the observe dr= aft. Given the wide set of interests, these discussions were not easy and someti= mes ran in loops. See my comments below. Michel Veillette schreef op 2016-12-15 18:31: > Hi Peter >=20 > The current CoMI draft rely on the observe mechanism [RFC 7641] to=20 > transfer YANG notifications. > A common use of these YANG notifications is the implementation of what=20 > was called in SNMP, traps. > Traps are typically sent to a management station (e.g. NMS) to notify=20 > this station of significant events. >=20 > This mechanism typically require a long term relationship between=20 > network elements (CoMI servers) and a management station (CoMI=20 > client). However, RFC 7641 section 4.5. > Transmission, required that > this relationship is terminated at the first unsuccessful transmission. >=20 > "or if the last attempt to retransmit a confirmable > notification times out, then the client is considered no longer > interested and the server MUST remove the associated entry from the > list of observers." I find this text perfectly reasonable and probably covers a wide range of n= etwork problems. As far as I know deciding whether the processor is faced with a network pro= blem or a failing communication partner is unsolvable; unless we start inco= rporating stable storage. >=20 > How this concept of long term relationship between network elements > and a management station > should be addresed? Good question. >=20 > Should the CoMI draft redefine how the list of observers is managed by > the observe mechanism? > Should CoMI clients send notifications only with non-confirmable CoAP=20 > message? Seems undesirable to me; you really want to know when there is a=20 cmmunication problem to take other analysis or recovery actions. > Should CoMI servers (i.e. management stations) periodically > re-register as an observer (e.g. every day)? Sounds reasonable to me. Applications can decide how often and under=20 which conditions. > Should we adopt a different method to transfer notifications? For the moment I am reluctant to choose this option. By the way, we have a connected probem in the bootstrap where a=20 processor waits for a response but the time to wait is undetermined (2=20 seconds to hours) >=20 > Regards, >=20 > Michel Veillette cheerio, Peter From nobody Fri Dec 16 09:38:56 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95B129962 for ; Fri, 16 Dec 2016 09:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lobaro.de 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 lMG1spshsFTK for ; Fri, 16 Dec 2016 09:38:52 -0800 (PST) Received: from se9.mailspamprotection.com (delivery.mailspamprotection.com [108.163.228.170]) (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 377AD1279EB for ; Fri, 16 Dec 2016 09:38:51 -0800 (PST) Received: from ns1.am20.siteground.biz ([107.6.152.202] helo=am20.siteground.biz) by se9.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86) (envelope-from ) id 1cHwT1-0002QN-IY for core@ietf.org; Fri, 16 Dec 2016 11:38:51 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lobaro.de; s=dkim; h=Content-Type:To:Subject:Message-ID:Date:From:References: In-Reply-To:MIME-Version; bh=7xSCZresYsNoBGmRAuqVBzGIpNP0TmFFhwkMeX2cQKk=; b= WVRNRCMVvy28n6t11Z5zNz7MjSZBLn7ZeIYIrIuGMV4Bpsq6CqmJyW/N2GlIkzbuVyuvI7pXpaW70 7VEVHlGppswEJKvKa5JmfYxYvl/zMpX3taj3KU+7+pzmSPUlvvQrbqtOHAbV7wD15jNeEp+fVlUuU NP0OkOjadI36SAJnM=; Received: from [209.85.213.181] (port=33365 helo=mail-yb0-f181.google.com) by am20.siteground.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1cHwSz-0001yy-NU for core@ietf.org; Fri, 16 Dec 2016 18:38:45 +0100 Received: by mail-yb0-f181.google.com with SMTP id v132so41041653yba.0 for ; Fri, 16 Dec 2016 09:38:45 -0800 (PST) X-Gm-Message-State: AIkVDXJ4s5Cn/5DQlHkK3vH1r3WmIhk6MYOmPvPEJHHhyUafErF02ccP58b5zp/hAK1F6BvEbDsvNtXQR2WUPg== X-Received: by 10.37.192.82 with SMTP id c79mr3163165ybf.123.1481909924600; Fri, 16 Dec 2016 09:38:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.215.87 with HTTP; Fri, 16 Dec 2016 09:38:44 -0800 (PST) In-Reply-To: References: From: Tobias Kaupat Date: Fri, 16 Dec 2016 18:38:44 +0100 X-Gmail-Original-Message-ID: Message-ID: To: core@ietf.org Content-Type: multipart/related; boundary=001a11465b06a56ba70543ca0af6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - am20.siteground.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lobaro.de X-Get-Message-Sender-Via: am20.siteground.biz: none X-Filter-ID: s0sct1PQhAABKnZB5plbIdH40z9tliyPtpXyyHKT/m4RjSEj2nYPqqWQeUf53awNXewBu5TuhjJr gH3eyFBy7sNj8BQqkega5p9fBkeb4oZC/lGsrXcsS0xY0J18f6o7xB66CWvXcfKDfXjTU++u69YB Xb6jfjohFJ7g32xIXrUO57I/5BFVuhfqQQ7qOU0oZuM7jUXIESohoO51xWmU8f/7RUALN8w5ja3N xpxWDaoY2T47vGK5fezrUhroBI5OFEb1sdJJzGW+9EO+zwnsjXo8fmRB/Nw97k+xvb1cUqA55Spz eRGOV3aY7/PHVUgL647lNwN4qOsSZg+fYhVZGxSHPIfeHGgPjT6rcUajk76mpXXp0Gt2TbF6JjUg D4Z6SWM++pStxxa3FW225wglPaXHp6NpGwzrU5VG2NFRDQwN6A7sYlbJv8IjXJJB4hSigM/q/H2F qjD1scJGaqQs9GWLX2ZbQb3UJKihEmoDuwgTwRKLwC98NjMBcVQD/vDG16ixf05zXFqEd+e8EX60 wCY91scG0mEZL1BA7T8dPySDqE+X/czcI5QK7VzPhB1Sg6GtgRRwcPDQPLQ2Uignxg4TCyit5yhm YM6wMN3alVdoh9VoIekQHpwUfpYnEThmZu6ZIenY1SsGgzhhrFGQ2CLu9GpLUBpx3AZCWLaUmHoo xJjsUHcLs2RiH4lguH1mIMVutWjqmYwF9L8ga6E8vQ== X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com X-Originating-IP: 107.6.152.202 X-SpamExperts-Domain: am20.siteground.biz X-SpamExperts-Username: 107.6.152.202 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=107.6.152.202@am20.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Classification: not-spam/combined X-Recommended-Action: accept Archived-At: Subject: Re: [core] CoAP over Serial URLs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:38:54 -0000 --001a11465b06a56ba70543ca0af6 Content-Type: multipart/alternative; boundary=001a11465b06a56ba20543ca0af5 --001a11465b06a56ba20543ca0af5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, it was an interesting chat today. You can find our current Go CoAP client implementation that supports only CoAP over URAT here: https://github.com/Lobaro/coap-go (the repo also contains the Go warpper for our C CoAP server/client lib) There is a basic transport implementation for the coap+uart scheme: https://github.com/Lobaro/coap-go/blob/master/coap/transport_uart.go Currently we use standard parameters for the uart, but let the user override them if needed: Baud: 115200, Parity: ParityNone, Size: 0, ReadTimeout: time.Millisecond * 500, StopBits: Stop1, MessageID's are simply counted up and tokens are random 4-bytes. I'm thinking about using a 1 Byte counter + random 3 bytes to avoid even the chance for collisions. I also support a special host "any" where the implementation just takes the first free COM port oder ttyS* - in many cases you have only one serial connection (or only one that supports CoAP) and just don't want to bother looking it up before creating a URI. Further implementations to select the "any" connection could be more clever, but it's a start. The Package oriented transport is currently based on SLIP. Since I did not found any Go implementation we made our own, it's also OpenSource: https://github.com/Lobaro/slip I'm looking forward to extend the (usage of the) slip library with the ideas discussed today. Briefly: 1-Bytes packet headers and checksums. The whole coap client is build after the go http package to make it easy to use for developers who know the Go standard lib. The CoAP client will be able to select the correct Transport based on the URI scheme. Cheers, Tobias K. On Thu, Dec 15, 2016 at 6:47 AM, Carsten Bormann wrote: > Hi Tobias, > > > > On 14 Dec 2016, at 19:30, Tobias Kaupat wrote= : > > > > Hi all, > > I'm implementing CoAP over a serial RS232 connection > > Interesting =E2=80=94 we had a brief discussion about this at the T2TRG m= eeting in > Ludwigsburg, and I=E2=80=99d sure like to know more about this. > > > and wondering about the URL format. > > When we started to think about the bluetooth URI format > (draft-bormann-t2trg-ble-uri) we ran into a similar discussion. A URI fo= r > a =E2=80=9Clocal interconnect=E2=80=9D isn=E2=80=99t really a =E2=80=9CU= =E2=80=9DRI, as its meaning is dependent on > that local context. There is precedence in the file:// URI, but there is > still some uneasiness around. (There are also authority-based URIs with > link-local addresses; similar problem.) > > > For CoAP over SMS they use a separate scheme "coap+sms" (see: > https://www.ietf.org/archive/id/draft-becker-core-coap-sms-gprs-05.txt) > so I just took "coap+rs232" for my case. > > Are the voltage levels on the serial line (which is what =E2=80=9CRS232" = is about) > really important? > Do you need a different URI for TTL-level UARTs? Maybe more like > coap+serial or coap+uart. > > How do you decide the bit rate? The CoAP over Serial specification could > align on a strong default (say, 115200 bit/s as in 6lobac), but there may > occasionally be a need to deviate even from such a strong default. > > > So far the only question I have is: Is there already some other URL > scheme defined that I'm not aware of? > > Not for serial. > > > The actual question is regarding the Host. A serial connection is > usually a file handle. For Windows something like "COM3" is just fine. On > Linux based systems I have to connect to "/dev/ttyS3" which gets more > problematic when encoding in URLs. What is the best way to deal with the > slash characters? > > > > > > https://tools.ietf.org/html/rfc3986#page-21 restricts percent encoding > of ASCII characters in the host part but allows system specific host > lookups. Thats why I came up with an Implementation that implicitly adds > the prefix "/dev/" to the host part of the URL before opening the > connection on Linux systems. > > That is probably the right approach. Again, compare the link-local > addresses which would need a % character (which need to percent-encoded) = =E2=80=94 > endless discussion. > > I=E2=80=99m definitely interested in also nailing down the data format ov= er > serial. Let=E2=80=99s discuss this tomorrow... > > Gr=C3=BC=C3=9Fe, Carsten > > --=20 Lobaro UG (haftungsbeschr=C3=A4nkt) Tempowerkring 21d 21079 Hamburg 040 / 22816531-0 www.lobaro.de info@lobaro.de USt.-Identifikationsnr.: DE297198645 WEEE-Reg.-Nr. DE18824018 Gesch=C3=A4ftsf=C3=BChrer: Dipl.-Ing. Tobias Rohde Sitz der Gesellschaft: Hamburg Handelsregister: HRB 134264 Amtsgericht Hamburg --001a11465b06a56ba20543ca0af5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,
it was an interesting chat today.

You can find our current Go CoAP client implementation th= at supports only CoAP over URAT here:=C2=A0https://github.com/Lobaro/coap-go (the repo also contains= the Go warpper for our C CoAP server/client lib)
There is a basi= c transport implementation for the coap+uart scheme:=C2=A0https://git= hub.com/Lobaro/coap-go/blob/master/coap/transport_uart.go
Currently we use standard parameters for the uart, but let the = user override them if needed:
Baud: =C2=A0 =C2=A0 =C2=A0 =C2=A0= 115200,
Parity: =C2=A0 =C2=A0 =C2=A0ParityNone,
Size: =C2=A0 = =C2=A0 =C2=A0 =C2=A00,
ReadTimeout: time.Millisecond * 500,
S= topBits: =C2=A0 =C2=A0Stop1,

MessageID's= are simply counted up and tokens are random 4-bytes. I'm thinking abou= t using a 1 Byte counter + random 3 bytes to avoid even the chance for coll= isions.

I also support a special host "any&qu= ot; where the implementation just takes the first free COM port oder ttyS* = - in many cases you have only one serial connection (or only one that suppo= rts CoAP) and just don't want to bother looking it up before creating a= URI. Further implementations to select the "any" connection coul= d be more clever, but it's a start.

The Packag= e oriented transport is currently based on SLIP. Since I did not found any = Go implementation we made our own, it's also OpenSource:=C2=A0https://github.com/Lobaro/slip
I'm looking forward to extend the (usage of the) slip library wit= h the ideas discussed today. Briefly: 1-Bytes packet headers and checksums.=

The whole coap client is build after the go http = package to make it easy to use for developers who know the Go standard lib.=
The CoAP client will be able to select the correct Transport bas= ed on the URI scheme.=C2=A0

Cheers, Tobias K.


On Thu, Dec 15, 2016 at 6:47 AM, Carsten Bormann <= ;cabo@tzi.org> wrote:
Hi Tobias,


> On 14 Dec 2016, at 19:30, Tobias Kaupat <tobias.kaupat@lobaro.de> wrote:
>
> Hi all,
> I'm implementing CoAP over a serial RS232 connection

Interesting =E2=80=94 we had a brief discussion about this at the T2= TRG meeting in Ludwigsburg, and I=E2=80=99d sure like to know more about th= is.

> and wondering about the URL format.

When we started to think about the bluetooth URI format (draft-borma= nn-t2trg-ble-uri) we ran into a similar discussion.=C2=A0 A URI for a =E2= =80=9Clocal interconnect=E2=80=9D isn=E2=80=99t really a =E2=80=9CU=E2=80= =9DRI, as its meaning is dependent on that local context.=C2=A0 There is pr= ecedence in the file:// URI, but there is still some uneasiness around.=C2= =A0 (There are also authority-based URIs with link-local addresses; similar= problem.)

> For CoAP over SMS they use a separate scheme "coap+sms" (see= : https://www.ietf.org/archive= /id/draft-becker-core-coap-sms-gprs-05.txt) so I just took &q= uot;coap+rs232" for my case.

Are the voltage levels on the serial line (which is what =E2=80=9CRS= 232" is about) really important?
Do you need a different URI for TTL-level UARTs?=C2=A0 Maybe more like coap= +serial or coap+uart.

How do you decide the bit rate?=C2=A0 The CoAP over Serial specification co= uld align on a strong default (say, 115200 bit/s as in 6lobac), but there m= ay occasionally be a need to deviate even from such a strong default.

> So far the only question I have is: Is there already some other URL sc= heme defined that I'm not aware of?

Not for serial.

> The actual question is regarding the Host. A serial connection is usua= lly a file handle. For Windows something like "COM3" is just fine= . On Linux based systems I have to connect to "/dev/ttyS3" which = gets more problematic when encoding in URLs. What is the best way to deal w= ith the slash characters?
>
>
> https://tools.ietf.org/html/rfc3986#page-21= restricts percent encoding of ASCII characters in the host part but allows= system specific host lookups. Thats why I came up with an Implementation t= hat implicitly adds the prefix "/dev/" to the host part of the UR= L before opening the connection on Linux systems.

That is probably the right approach.=C2=A0 Again, compare the link-l= ocal addresses which would need a % character (which need to percent-encode= d) =E2=80=94 endless discussion.

I=E2=80=99m definitely interested in also nailing down the data format over= serial.=C2=A0 Let=E2=80=99s discuss this tomorrow...

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




--
3D""

Lobaro UG (haft= ungsbeschr=C3=A4nkt)
Tempowerkring 21d
21079 Hamburg
=C2=A0
=C2=A0
USt.-Identifikationsnr.: DE297198645
WEEE-Reg.= -Nr. DE18824018
=C2=A0
G= esch=C3=A4ftsf=C3=BChrer: Dipl.-Ing. Tobias Rohde
Sitz der Gesellschaft:= Hamburg
Handelsregister: HRB 134264
Amtsgericht Hamburg
=
--001a11465b06a56ba20543ca0af5-- --001a11465b06a56ba70543ca0af6 Content-Type: image/jpeg; name="lobaro_logo.jpg" Content-Disposition: inline; filename="lobaro_logo.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 8457dcfce885091a_0.1 /9j/4AAQSkZJRgABAQECWAJYAAD/4QCKRXhpZgAATU0AKgAAAAgABwEaAAUAAAABAAAAYgEbAAUA AAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAQAAAAclEQAAEAAAABAQAAAFERAAQAAAABAABcRlES AAQAAAABAABcRgAAAAAACSe+AAAD6AAJJ74AAAPocGFpbnQubmV0IDQuMC45AP/bAEMAAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB Af/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAf/AABEIADsAyAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0 4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery 8/T19vf4+fr/2gAMAwEAAhEDEQA/AP64v+CQUss3/BKf/gm7LNJJLK/7Dn7LjPJK7SSO3/CmPB3L OxLMfckmv0Wr85f+CP3/ACij/wCCbf8A2Y3+y5/6pjwdX6NUAFFFfEf7Tf7RHxS8PfEHwF+zB+y3 4Y8H+Lv2mvih4e1nx3NrXxIbWG+EfwA+Dvh/UbPQ9X+MvxXsvDd1p/iTxN/aPiPULXwn8L/hboGr +HNa+KPiiPXFj8VeFPCvgvxt4r0AA+3KK/N5P2Pf2zL+L+19c/4KxftLWXi0gSnTvAP7PP7CXh74 Rw3H3nt7TwV40/Zn+JnxG/shnyq22o/GzU9Zjt8Rr4h88fajpfCL46ftB/CL45+FP2Vv2zLrwJ4z 1L4rad4kvv2Z/wBp/wCGXhnUPAPhb4yan4J0mfxF4x+EHxK+GWo694sX4bfHfQfB1nqHj3SD4e8U 6z4F+K/grQfG3iDw3ZeCNQ8Fa14QiAKvx/lkX/gpJ/wTojWR1jl+FP7eXmxqzBJNmh/s5snmKDtf Y3K7gdp5GDX6M1+MP/BR39oTQ/2Zv2zf+Ce/xI1Lw5rvjzxBd+BP2z/Anwz+F/hM2Y8YfFn4s+P0 /Zn8L/Dv4beFzqE0Gn22oeJvEeoWkN9rWpzQaH4T8Pw6z4w8SXVj4c8P6vfW3uGk/s6f8FBvivaw +KvjX+374g/Zx1rVEF6Pg9+xT8Hv2eb3wb4HWUboPD2ofFX9q/4MftB+MfijqOmrtj1Lxjpvhj4Q 6Xrt2JZ7HwFoFm0VoAD9LqK/Kbxp47/a/wD2BbSL4pfHP4y2X7ZP7HmlXVpH8ZvH+v8Awx8HfC79 pf8AZy8MXNxHa3Pxq1k/CLT/AA18IfjJ8IfB/mx6l8VdM0T4WfDDxr4B8Hwax8QNMu/Hdjot/wCG Yf1IvdY0nTdIu9f1DU9PsdCsNOn1i+1m7vLe30qz0m1tnvbnU7nUJZEtINPt7ON7qa8llW3itkad 5BGpYAGjRX5UeBvEf7aP7eGkW/xf+Gvxqk/Yd/ZS8Up/aPwQuPCnwp8C/ET9qn40eA7rLaH8Y/Ee ofHLQ/Gnwn+C/hDx3p4g8Q/Dz4dy/B3x744uPCOp6P4k8Z+JvCetalc+ANC6XWfgJ/wUO+C9nP4w +Cf7b2rftZXujRtf3PwL/bN+FvwB8L2Pj+1gHmXXhvwr8b/2WfhB8B9R+FfiPUEV49E8VeLfh78Y PDtjfNDDq/haTT5ZLyyAP0yorwn9mz9oDwl+058HvDHxe8I6drvh1NWuNf8AD3ivwN4ttYLDxt8M /iP4H8Qan4M+JXwv8c6bbXF3b2HjH4eeONC13wn4ghtLu806e+0t77R7/UdHu9P1C6/Ib9j/APbG /bP/AG7Ph1F8OfgN4z8DeGNb+GXi74oeGf2pf2yPiF8PrLxjZeE/F1v8V/HK+CPgP8EPhF4cvfAv hTxd8WtF+EqeBPEHjvxl4s1KLwR8N9H8R+DhqHhn4neMfEet6T4dAP3vor83Zv2QP20tJhOr+FP+ Cr37RWq+LkUyrpnxd/Z1/Yd8X/CG6uh80cGoeDPhj+zp8D/iUNID4je20f43aNq0luSra4bnF0PT f2WP2kPiH498WfEv9nb9pLwf4Y+Hf7U/wRsvDOveKrDwNfapffC74ufC7xtNrNn4E+PXwYuPEAHi GLwX4k1Xw14m8M+JfB3iCS+8S/C/x54c1jwprGreItJm8J+NfF4B9q0V8cftU/tG+OPhhq3wy+CP wB8FaF8Tf2pfj3N4m/4Vn4X8W6pf6L8PPA/gnwPHo7/En47/ABi1fSLe71uy+F3w2bxL4V0ubS/D 9tJ4m8d+OvGPgj4f6BJpc3iS78S+HvJIP2RP21tdhGs+Nv8Agqx8f9B8XSqJ5NH+BX7On7E/gn4P 2N23zyW+meEvjF+z7+0N8TpdIV/3UUGufGzWdT+zqP8AibLcs1xQB9hfH5viGvwb+IDfCv8AtX/h ORoTf2SfDyaTJ4rW0+1Ww8QP4Jj8QBvD0nj5PDf9rv4Cj8RK3h2TxiuiJrytpDXgP56f8Et0/aqg 0Lxdb/tA3XxbvtPj8P8Ag6W4uPi/F8XC4+Id1DdXetwfD+/+PFjovxV1LSrfTLi2tvF5v/DmheAN K1C38M6F4BbxZremfEr4heMfSPA/xo/aU/Zu+M3w4+A37Y3iHwT8XvAHxy1i88HfAH9rPwP4Nk+F 93cfFGz0bUvEtr8E/wBoT4bR614h8M+HvGXi7w9o2vX3wy+JvgPVdL8E+PtU0HUPBV/4E8A+Lbrw haeOP0joA+d7r/hIvjJ4u8VaJZ+Jdc8IfDDwHq3/AAi+pz+E7+TRvE/jzxfDZ2l9rdmviO3xqnh7 wt4cW+tdLlbQZbDWdX15NTi/ta0sdNEN9ZvvgYmhQPqfwn8Z+NfBfim1Uz2a61428Y+OvCGs3EY3 LY+KvDfjHXNdhubG75gudQ0d9K8QWyym5s9TWWMI8Xwz1S18FeO/iF8LdflTT9V13xp4k+JPgWa6 YQw+LvDni+ePWtYj0maTat3qvhbxFcarp2saZGWu7TTTo2pGM2d+ki+w+LPFvh3wPoGoeJ/FWq2u jaLpkRluby6fG5jxDa2sKhpry/u5NtvY2FpHNeXty8dtawyzSIjfKYTB5bjcHicfmbhLG062LWNx latKliMpqUKtS9DC4nnhUyyjhKSg6U8NOgq1Llxs5VZ4mder+AcP8PcFcTcOZ1xZxzLDVeJsHmfE seJuI8wzOpl+b+H+KyrMMYqmV5FnccTh8XwTl3D+X08K8BicmxGVQzLL1h+KMVVx2IznE5pjsb4Z +NT8QPBumeI5tPbRtUM+qaN4i0OSUTvofinw5ql5oHiXRzMoXz47DW9NvYLa5KRm7tFt7sRos4Ud 5X5eWXx/+Kn7JWr6r40/aa8E6ZpX7J3xd8Vat47tfjN4YtdTXVf2Vte8aapLeHwx+1ToM95qS2Xw 5v8AzbW9i+P3hoWnhX4e6rfX3hr4u+HvCnh/Sbf4o679QeKf2vPhRo3iS+8GeDrLx/8AG7xdpEVn P4g0P4FeBta+JcXheLULWK+09fFPifSI4/BPhu+v7GeC+sdH1nxPZ63eWM0N9babLZyxzt9Nw7hc 1zbL8C44bEYrGPAYfEYtxoOEoJwpqeIxUVGNPCKU5xdVVPZ06NWoqTadkfoHCPEdWlwDwbm/GWOj g81zLIMmnjKmZUoZdjcdmWIy6nXm55YqdGdDM8XGM8Xicpw+GVTB1XXw8aMY4eXL9R0V4H8Lf2k/ hl8V9f1HwTpsnijwd8SdH09dX1T4XfFDwf4h+HPxBt9GaZbca7Y+H/FFjYt4j8Oid4oJPEnhS413 QIbmaG1m1OO6lSEld2KweKwNZ4fGYethqyjGfs69OVOThNc1OpFSS56dSLUqdSN4VItShJxaZ9lg MywGa4ZYvLcZhsdhnOdP22FrQrQjVpS5atGbg37OtRmnCtRny1aU04VIRkml8w/8Efv+UUf/AATb /wCzG/2XP/VMeDq/Rqvzl/4I/f8AKKP/AIJt/wDZjf7Ln/qmPB1fo1XMdoV+cf7LGNd/bt/4Ki+K tSH2nWvDfxC/ZT+CWkXknzS2fw88Kfsq+A/jJo2gwO2Wjs7fx9+0J8T9cECbY/tfiC6mKmSR2P6O V+cf7IXy/tm/8FYkbh2/aX/Z1nVTwzQP+wP+y5AkwB5MbzWtzErj5TJBMgO6NwAD9HK/OT/gqAq6 V8BPhB8Q7NRH4n+F37eX/BOnxD4S1AfLLYXXjP8Abe+BPwW8XxRyD544/EXwu+Kvj/wdqJjZWl0j xJqFuSUmdW/Ruvzn/wCCqALfsoeH4lBaWf8AbY/4JhQQRqCXmmk/4KYfsjrHFEgyzyOeERQWY8AE 0Acb+1P4I8O+Lv8Agp1/wSr1bXtPgv7v4deF/wBvnxv4XaeNZVsPET/DT4PeCl1CNXBUTw6J4z1u KCTG6GWdZoyskaMv6lV+cH7QciJ/wUp/4Jwq7qrS/Cz9vaOJWIBkceHv2dpSiA8swjjkkKjJ2I7d FJH6P0AYfifw3oXjPw14h8H+KNMtdb8M+K9D1bw14i0a/iE1jq+ha7YXGl6vpl5C3yy2t/p91cWt xG3Dwyup4Nfj78BPhr8T/wBrr/ghZ8D/AILaJ4xsrHx18Zf2IvhZ8H9Y8ZeKtQ1a0W/8MX/hLQPA fjy81bVdGsNT1ZNb8SfD238QQG/s7N5X17U0uGe1jZ7iD9nq/A/4YfE/xn8IP+DeH4b+Pfhvq8vh zx9/wxJ4K8PeAvFsGTJ4R8TfEyz0vwF4W8eW+GVZB4R1DxbY+L7diwglTS0Z28hy1AH2Tc/tnfEv 4g+I/Efw5/YE/ZZsf2gPDfwu1vUPhz4m+NvxD+K9j+zf+ypovi7wlcvoOu/D/wAB+NdM+H/xh+In xQ1TwJqFjd6B4rufhl8F9b+HnhrXdNvPB9x46TxVpWs6FpVPW/2sf23fgVZzeLf2pP2GPCmo/CXS ozeeLviJ+xL+0R4h/ae8QeA9EQFr3xN4i+CvxE/Z6/Zr+JfiDQdEiButZh+EVn8VfGS6ek95pvgv UhbzRL92fB/4T+BfgR8Kvh38F/hjokHhz4ffC3wb4e8CeD9GgCkWWg+GtMt9L09Z5QqNd300NsLn UtQmButR1Ca5v7uSW6uZpG9HoA/Lf9gLxx4M8X/tE/8ABR+++FHiXRfFfwd8b/Gr9nf49eAta8M3 9vqfhfVT8bP2NfgTf654i8NXto8ltLpHjGbwxZeMJWtn8m713Xdb1dh9r1W7d2/8EafA/h3wP+wP 4Gi8PafBZP4p+Mn7WfjjxBcRxotxq3iPxN+1d8Z7y+1C+lUB7meO3Wy0u2klLPDpem6fZKRDaRKv mf8AwTQ+B3hr9nn9sL/gr38PfBD/AGfwNd/tQ/Br4h+FfDqSs1n4Nh+K37OXgj4k+I/C+kWgbyNI 0Cy8c+KfFd54e0Oxjt9O0bRNQsNPsLaC0t4o196/4JM/8mG/Cb/sdv2kP/Wn/jLQB+jlfKHxB+An ibxB+2B+zb+0r4V1TQNJsPhh8L/2hvhD8UbO7m1GHXfF/gv4uT/CjxR4X0/TYbTTrjT9QHhrx98K dL1ffrF/YNpNpqGr/wBkGeTV9Rt5vq+igD84vhIB4i/4KmftrazqwF1d/Df9kv8AYd8A+DDJyuha J418c/td+OfGn2FekNx4s1nT/Cv9uSrze2/gvwvFJxpkVfo7X5x/An5f+CnH/BQ5G4dv2fv+Ce86 qeGaB7v9sSBJgDyY3mtbmJXHymSCZAd0bgfo5QB+c3/BWSNbb9gf43eLoB5Wv/Cu9+E/xp8Fainy 3Wi+Pvg38Z/h78S/BOs2U64lt7iw8SeGNOkZ4mRpbY3FrIWguJo3/Rmvzq/4K1c/8E5P2r0HLy/D q3giX+KSe48VeHYIIUHVpZppI4okGWkkdUUFmAP6K0Acv4t8E+EvHmljRvGPh7S/EOnJPHdwQalb JM9neRZ8m+0+5G2602/hyfJvrCe3u4dzeXMu45+Dv2F/C2h+L9J+MXjHxfaS+LvE3w+/bB/au+HH gjWPFV/qPiO68K+Dfhz8a/FnhLwXpOh/21d30WnyaH4d02y0yPVbeNNZvIoTLqOoXlzLNNJrSaLr v7ZXxT+Kuk+IPF3i/wALfsw/BPxpc/CiPwX4C8Ta14H1n45/E7QtP068+IOq+OPGPhi90vxXa/DX wVqGqp4H0nwV4f1fSYvFHiXSfFGp+LLrUNHtdG0h9bUv2BPhL4Q0+61n9mG61/8AZh+KVo9xqWh+ MPh54h8SS+G9S1lma58j4m/DbVdZvfBPxL8Pate7D4htfEOkSa7PE01xo3iDRdX8rUovGq4TB4uu sc8nwGLqUpJU8XXpUHjH9Xm+WWHlUw83aE1J0JTxFFN+9FxhKM39fmngf4Of2zlWI8RMbkuF8Rqm EybHQxtTwyyzijCcKvF0KOZZHh+I+Laua4biLLsbl1LE4fG5nhuG+GuJa/D/ALZ4enDE57hsflGD 9o/a18d6p8Mv2X/2gfH+h29nc614T+EHj/WNIj1G1ivdMXU7bw1qH2G41SzuI5re70u0umiutStp 4nhnsYbiKVfLdq6H9n74HfD/APZv+D3gL4MfDLRdO0Xwn4H8P6fpNsmnWVtZf2rfRW0S6n4gv0tU SKXVNdvhNqWoT4w09wUjCQRwxJ+d+n/FH9qb9v3wRr/wR8O+Abf9mjwHZr4q+DH7XPx18T2nh7xh qeoeMtFmv/BvxZ+E37Jvw+1k61putxy3MWpWF78b/jHpTeEPCVpfW+neHfhz8V/EKa5L4M+iPBvj j47fs26LYfDD4m/CX4lfHrwh4UtYdE8A/HD4QW/h7xT4h13wtp6La6FY/Fn4fahrugeKNL8eadps dvY6t4j8K2Xinwx4qntm16WXw3eX82i2/wBxl3/CpkX1LAVqMMT9fWPrYatXo4WeZYaphaVLBuk8 ROlCrWyyosX/ALJz/WZLNJzoUakaWJlS/M+MMqxvAviBmNDijBV1LKcPjOF6mIwdGpmtDIc3y7Ns T/bEZ1cuhirYLPIwwDp5tRU8snHIaPtsXT+tYD6zt/t4aXaaT8Bdf+OWmxJZ/Ej9msp8Z/hv4ht1 Eeq2moeF5re68ReFIrlcSzaJ8SvC8eqeBPEmiuz2erWGtJ5sDXlnp89sVia7YfFn9rbUfD3hvxN8 L/EvwP8A2b9G8SaB4t8ZWnxHu/D8fxU+NV14U1a01/w94KtvCHhfWvEdt4G+HD+ItM0/U/GN/wCJ 9Zh8WeKbCwi8L23hfStJ1TU9Ucr7/hvP+EOGcsjlvGPDlHizHfWK2IwsaGNoVo5PhKqpXwUsRTqT oupWrxr4uphaNScMNKs3V5MXWxNKn+Jca8JeInG+eSzvw34zxPAGV/VMPhMfPFZbi8NU4kx+HlVa zSGDrUKddUcNhJ4fLqOPxFKlUx9PDpUVVy/DYHEVvDP+CRvxg+Eulf8ABLH/AIJzaZqnxR+HWm6l p/7En7Mdnf6ff+NvDVnfWN5bfBzwhDcWl3aXGpxz21zbyo8U0E0aSxSKySKrKQP0P/4Xf8F/+ivf C/8A8L/wp/8ALavB2/4J0/8ABPl2Z3/YT/Y3Z2YszN+zD8E2ZmY5ZmY+CCSxJJJJyTyab/w7n/4J 7/8ARiP7Gv8A4jB8Ev8A5h6/IT+ij6a8O/EPwB4vu5rDwn458H+KL+3tzeXFl4d8TaLrd3BaLLFC 11Nbabe3M0Vus00MRndFiEssUZbdIoP53fHPV9S/Yn/ap179sK88O+JNf/Ze/aB+Hngj4d/tV6j4 P0HVvFer/An4g/CK68Rf8Ko/aL1XwtoFpqXiHVPhj4g8G+LtX+GPxs1vRNP1C68BWvg74ReML/TY /BWn+P8AxDoP2J8Kv2Uv2XPgTr994r+CH7NnwC+DfijU9Hm8Pal4k+FXwd+Hnw81/UNAub2w1K40 O+1jwj4d0jUbvR59R0vTL+bTJ7mSylvdOsLp4GntLeSP32gD5z8PfthfsleLfB8PxC8L/tQfs8+I fAc9mNRi8Z6N8aPhzqPhZrFoxL9qOvWviSXTEgWM7nd7lRGM79pBA+JNQ+KPh7/gpD8c/gp4d+A1 3/wnP7G37NvxW0X4+/Fz9oXSo5ZPhf8AGn4yfC+S6vPgZ8Ffgh4odP7L+KmkeCPiU+lfGv4n/Enw ZJq3gjw9rPw18CeAtM8Rar4g8ReKbPwp9p67+xj+x74o8Vy+PPE37KH7NfiLxxPdm/m8Z678Cvhf q/iua+aTzWvZfEWoeFrjV5LsykyG4a8MxkO8vu5r6NtbW2sba3srK2gs7OzgitbS0tYY7e2tba3j WKC3t4IlSKCCGJFjiiiRY441VEUKAAAfh1/wVF0746Qftu/8EwfiP+znpp8W/E/4IWP7aPxZh+FP 22x0s/G7wZpfhP4IeF/ib8IrHVtVuLbSNI8V+K/hz4t8USfDjU9amh0Kz+J+m+C5ddutP0cX2pWf 6E/Bf9vv9kH476VPdeDPjt4C0nxPpDfY/G3wq+Imu2Hwz+NXww16JFa/8LfFL4Q+OLjQ/H/gHxJp khMV3p3iLQrIShReafNfabPa3s/1Vd+HfD9/rWj+JL7QtGvfEXh221az8P6/d6XZXOtaFaa8tiuu 2uj6rNA99pltrS6Zpq6tBZTwRaiun2IvFmFpB5flnxS/Zp/Zy+ON1Z33xr/Z/wDgn8YL7T4lgsLz 4pfCrwJ8QLqxhRmdIbO48WaDq81tErszLHC6IrMzAAkmgD4n/aU/bZ8O/FHT/E37J/7CPxC8L/Gn 9rb4kaVceCxrnww1Wy8e+Bv2T9E8Twy6VrXx8+PvjDwzdXvhrwNB8PdIuLzxH4J+Hms6xZePPi14 ws9B8J+E9CnstQ1jX9B+l/Ev7Hnwn179im//AGELWHUdF+DMn7OMX7M2ivZTL/b3hzwVpvw+h+Hn hzVtLvUWAReJPDdhaafq2lajGsLwa3p9tfR+XJGpX33wN8PfAPww8PW3hL4a+B/B/wAPPClk7yWf hnwN4Z0Xwl4etJJAoke20XQLLT9NgeQIgdorZWYIoYnaMdhQB+aP7On7enhPSIdE/Zy/be8aeC/2 ff20vA+mw+HfGHhz4i6xp/w/8I/H59CSLTf+F6/s1+IfE02l6F8TPht8RUii8Uf2L4X1DUvFnwu1 DVLnwH8RNH0TX9GY3nsPxr/4KBfsk/Ayxt4dd+MnhLxt8QdcLWngD4G/CLV9M+Knx7+K2vvGxsfD Pw0+Efgy91Txh4n1W/mEcBu4tPt/D+ixy/2p4n1vQtDt7zVLb6W8f/DP4b/FjQJPCnxT+H3gj4l+ FppVnm8NeP8AwpoPjLQJZ0VkSaTRvEVhqWnPKiO6rI1sXVXZQQGIPI/Cz9nT9nz4GPev8E/gT8Gv g8+pR+TqL/Cz4YeCfh89/DvWTyr1vCWh6QbqPzEWTZOZF3qrY3AGgD8qv+CTmhfG/Tv2jP8AgqT4 m/aOSy034z/FL49fAT4qeLvBmmahb6xp/wALLHxl+zX4IuvA3weg12zLWXiK7+E3w6g8I+ANe8Ta ex0vxL4l8P6zr2kCPSdRso0+nv8Agkz/AMmG/Cb/ALHb9pD/ANaf+MtfoHYeHfD+lapruuaXoWja brXiiewuvE2sWGl2VnqniK50rT4NJ0y413ULeCO71efTtKtrfTLCbUJriSz0+3gsrdo7aKONTQPD vh/wppUGheFtC0bw1olrLez2ujaBpdlo2lW0+pX1zqmozQafp0FtaQy6hqd7eajeyRwq91fXdzdz mS4nlkcA2aKKKAPzU/aeh8Ufsw/tK+FP28PDfg/xZ48+FOt/Ci0/Z3/bI8NfD/QNU8XeO/Dvw58K +K9f8ffA/wDaB8PeCtAtrvxF43034I+KPHHxY0L4jeGPDOn6x4sk8AfF3UPGehaVqR+Hlzo+rfSv gb9s79kT4m+EYPH3w/8A2of2fvF/gye2+1f8JHofxf8AAN9pdtGF3Sx6jPHrx/su7tCGiv7HUhaX un3EcttfW9vcRSxJ9LV85eMv2PP2R/iL4pl8cfEH9ln9nLx341nuPtc/jDxl8EPhn4n8UzXW7f8A aZfEGt+GL7VpLjd83nPdmTdzuzQB8MfFD4xeDv8AgpH468A/s3fs06zZ/FP9mvwV8WvAXxR/a7/a N8JTLrHwXvNP+CXjLSPiP4P/AGZvhv4/si/h34ofEH4ifFDwt4Qj+LEHgfVNa0H4efCXRvGmheNt T03xZ4y8KaFf/rpVDS9L0zQ9OsdH0XTbDR9I0y1hstN0vS7O30/TtPsrdBHb2ljY2kcNtaWsEarH DbwRRxRIoREVQBV+gD4D+C/jDRv2efjf8Yf2e/ibfWvhVPi58X/Gnx0/Z78Ua1NHp2gfEzTvilcW 3iTx74D0nVblksH+I/gP4hXHiSS68JPdLrGpeDNZ8M6/pNldWi6sdP8AqX4x/G34a/AXwdd+Nvib 4ktdD02NhaaTpsYN94m8Xa5OVj03wp4I8NW2/WPFvizWbp4bLR/D+iWt3qN9dTxokQTfInSePvh1 4A+Kvhm+8F/EzwT4U+IPhHUthv8Aw14z0DS/Emh3TxbvJml0zV7W7tDcW5YvbXAiE9vIfMgkjkAY eR/DX9kD9mD4P+JI/GPw3+Bnw58MeL7eF7ax8VW/h61vfEml2kqsktno2u6oL7VNFspY3aOWz0m6 s7aWMhJImUADijTxVGLpUXRdO8vZ1Kjmp0Yybai6UYctZU7tQ/e0W4KMZNyTnL9ex3EHhvxVi8Px PxbS4ywvEKw2Ap8QZJw/hsmrZVxbjsvwlDCVM0o8SZhmNLG8HYnPIYeGIzeH+rHGNGlmtXHZjl8a ODxeGyTLMj9jzwF4x8E/ByTU/iLpJ8O/EL4sfET4ofHPxn4W8+K5Pg7Vfi9461vxrZeCpZ4C0E17 4N8P6novhnVriCWaC61jStQureeWCaNz9TUUV00qao0qdKLbVOEYJveXKkuaVrLmlu7Jatn59xPx Bi+KuI884kxtHD4bFZ5mmNzOrhcHGpDB4N4yvOtHBYKFWpWqwweDhKOFwlOpWq1IYelThOpOScmU UUVoeEFFFFABX53X3x9+LPhT4q/FvwV4S0PTfiNrnjT9uzw18BfAmm+NPF1/4Z8N/DzwxL/wTt+F /wC0Lreqx3NhoHiO8uNM03WPDvi/XZPDdnZW0utan4k1BYdT0+5uhcD9Ea/NBLG1/wCGpJp/K/e/ 8PLxfb98n/H1/wAOc4tN83bv2/8AHl+52Y8v/lps8395QB6Gn7TnxW+3zfCj/hA/AFz8dF/aPm/Z 4hvIvFHiGD4V+Vbfs46N+1HefE27d/D0/i230+y+Hut2nh0eCoba7u734iy2Wj/8JZZeF7y48Z6X x3wS+NvxQ0X4vfFLwb8UPDumnxB4+/b3X4JiPRvGGra54U8MaBpH/BNb4c/Hmw8QeCjq2kWN9Hpn iO98ByT3/hK5stLGg+IfGniZ/wC1PEMumjWvEny9+3T4q1/4RfCH9tT48fDvUG8OfFf4P/tt/Bjx d8OvFscFrqMnh7X/ABZ+yl+yt8G/EN22j6xBqHh/WINU+G/j7xZ4cm0zXtJ1TSkOpx6xBZRa/pmk 6pYfG0vxr+KOjf8ABNP4k/tlWHi68X9pO0/bK+H3xTtviVc2elahJB448T/B34P/ALO2s6rH4V1C wuvA62dx8GfEWseCLbw8PDP/AAjemWl0mqaXpFlr9pZarbgH7L/FT9rTxZ4P1j4g6PpPhPwpoeh+ AP2gLH4NeJ/i7491LxRJ8NvAOg3f7Nfwy+PUPjv4g/8ACLeHr248O6dqGtfESL4fW9/r+q+GfA2l SW9vrWv+PNP1C/0bwrrdrwh8afjtrnx78S6DOPgvqvwn0D9mH4I/GC4uPCPibXdffUda+IGrftAW d7qvgnxEPDVjaa54f1l/hz4dGmyX7xW0WhqNTs2uLzUJoh/PB4n/AG6P2q/g5+ydo/xu+HfxavNF +KHx7/a08T6l8WPFN74W8C+JZPFN1afspfs6x2QTSvFXhfW9C8PWtjDpenWthp/hfTNFsLGytIbG 0tobRfIP3B4W+IfjD4Y/FD/gl5ovgXVl0DSv2qv2PPElx8erGLTtKvIfHcmhaFcfFbR8DUrG8bwt Hp3j34y/ErW7WHwW3hyGOPxNJowj/sHTNF0vTQD9K/h98d/if4+8P/sU/EX4leDtH8Cx/tG+PtL1 Twz4O8F/EPxFdz+D9D8RfsifHv4tx6d8UL06RpeifEG6t4vC9rBc+G7Wyg8M6L4puNP1zT9X1+68 E6PrGs+BfGf9svUvGHws/ao+Hui+KfhJrl9efsO/tcfGbwP4/wD2ffiP4j8UReEJvhR4f8NeHJtO ufFUnh7Q9P1fVpLz4o+HdY0Hxb4R1CyexvtE1qxvND06a30zUb70tfDGh+I/gd/wTH8MazY/bND1 BtE0W7svtN5bebpup/8ABOn9prRb22+02lxBeR+dpl9dW3nRXCXEXm+dDLHcJHKn4i/sc/HH4q/t K/CX9pjVfjZ4wvPGt18LP+Cb37Y3wv8AASfYdI8OafoHgnWfD3wMn1PS10jwnp+haVqN5dv4V0BX 8QavZX/iNINOjtotWS3muYpgD+lj9pzxN4g8K+EPhze+HNXvtGutT/aO/Zo8M6hcafO0Et34f8Uf HHwNoPiLSJ2Xl7HWdGv73Tb+A/LPaXM0TfK5ryG2/ad+JF9pOhfFe7+H3hCP9njxh8b9I+Bel3Fl 4z19Pi7HbeMfjTB+z14J+KR02Pw5b+GzpXiX4japoN2/g+DX7HXPDvw71hfGcvia68U6fc/Dgep/ tUwRXHgz4ZrMm9U/aa/ZcnUbmXEtv8evAM0LZUqTskRW2nKtjDBlJB/GHwl8UvHt7/wVtvv2G7rx DLN+yt4Z+Lut/GLRPhI1lpg0+y+IOn+DU/aa0vVv+EkWyXxrc6do/wAdL5/iDovhW88S3HhHRtQt dJ0zS9CtNA0PRtJsAD9MPhh8GfD+k/tdfFvQIvHP7Q2oaB8N/hd+zf448I+H/Ef7Vf7TnizQbTxJ 4x8U/tD2Xia61XRfFHxd1jS/FFlq9r4G8LQXGieKbTWtCRNL/cabEb3UTd6f7Rdtr9h8XG8S/FGx /aJ1T9me3+F/h230a+/Zu8Z/FDw/qPw9+Jtp4m8dXHxE8RfE3wx8BfFXhj42eNND8SeFLv4XWPgm Tw3o/wASPD/hWfw149vvEei+EF1Kz1rWvWfBUESftdftDXKpiab4HfsuRSvuY7o7fxb+1C0K7Sdi 7GuJjlVDNvwxYKu38Ov+CxX7e37Wn7NP7UvhL4UfA/4uXPgLwH4j+BngnxJq2kWng/4favdy674h +InxK8N6tqVr4g8ReE9Y8SaZcT6NoelWsJ0vV7JLCW0W+09LW/kmupAD9g5f2gviT4p/4T6f9mfw r8PPix8P/gr4d8HtqHiXxV8S9WttS+Lmv+Ifhj4a+Lth4a+H+taT4d8SaXHBcfDDxt8PfENn8S9f v9W0vxHrfjAaT/ZFnaaXf+JX4T4Y/tIpqvxV8QeIPDx1HxN4I+Ovxg/Z80PwZ/a2o3lmvhjwr4+/ ZDi+Ldpq1hpUqXkVvNdtoURvdIiNlG93q91ezXLXELLcfmH/AMFDPHPi39j/AONf7NX7Pn7Nmu3v wn+EHx5+GXww+F/xS8I6CYrz+3/CHhbWPDnwS0KPT9e12PVvE/hHxHY/Cu4h8GHx14M1rw945utM 0fwxLe+I7m/8JeGLvSPpz9ti7m+B3wN/bZ+IvwnW28FeL/gV8S/2TfEPwm1PTLKzmt/BWqab4P8A hF8PLN9O0bUILzQ7iyi8EeI9b8MtpOpabfaTPpWpXEE9lLlGQA+vPjD+0T8Z4fiJp/w9+EWi+ArK 70b9qvwN8FNe1DxtqWrvba/4c8T/ALNrfG+SWGHS9CvptIuRql5Do8ssL3Eq2emrPBIsmpSLYXX+ PvjGx+JvxG+E/gPwzaa38TNd/aPPw+0ybxx478Qz+A/Dui6D+yV8EfjH4u8bRWkWj32o6P4e0t/F mmeG9L+HPhtIR4h8a66fEl3rGgQa/wCJtU0b8OfC3x++L9//AME2v2iP2xL3xre3f7Rtn+2N8FPH lj8RLjT9FlFh4ohsPg18CEvLDwg+mnwHY2X/AAqq5uvDEmh2nheHQZnvL3xBLpj+J7261qb69/ar +IXjD4a/sz/tNftMeCNZfQfjh8PP2qfgH4v8IeOoLLTrqbTNd+If7IH7JHw18ZyzaFqFnd+F9X07 XvBvi/XNOudB1rRNR0CG8k0zX7PTLfxF4f8AD+raWAffd1+1R8ZJta8LfCnR/hX4Bk+M1x+0d4j/ AGdPHtxf+Ptcj+GPhZ9I/Zwn/ac0r4k6JqEHg1vFPifT9b+H2peCYD4Il0jQ77TfGPiLUPC8/iuX SNAfxxqGT4k/bA+JPhvSYbHxJ4V+GPgDUvDfxL+I3wz+LPxe8XeIPGd38APAWpeDNK8I+JfCF7qW uaX4Wh1Hw9bfFTwt4103ULLUfiBe+DfBfgjWNK8R+FNQ8c+JNe/4Qm18e/Pf7Fer6j8RPhP+wL8b PGd0+u/FL41/HL43fEv4oeLp1jt7vxZ41j+Bnxt+HFtrFzZWKWulWCWHgTwT4S8J6ZpWkWGn6Npe h+HtLsdO061itUFfF3/BSv8AbA/aK/ZD1zUZv2ePiH/wr2T4i/tL/Ht/GR/4RLwN4tXWW8MfBf8A ZXbQyU8c+GfEyWH2E6xqX/ILWyFyLki7+0COERgH9JnhjUL7VvDXh7VNTOhnUtS0PSdQ1A+GNVm1 3w0b68sLe4uz4e1y4sdLn1nQzPJJ/ZOqz6Zp02o2H2e7ksbR5mt49yvAv2U9F0zw7+zD+zroei2i 2OlaZ8DvhVa2FmjzSR21ungfQ9kMbzySy+WmdqK0jbFARcKqge+0AFFFFABRRRQB/9k= --001a11465b06a56ba70543ca0af6-- From nobody Fri Dec 16 12:13:29 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038771296C0 for ; Fri, 16 Dec 2016 12:13:28 -0800 (PST) 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 DfPnf0H8Acpm for ; Fri, 16 Dec 2016 12:13:25 -0800 (PST) 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 6C50A12944C for ; Fri, 16 Dec 2016 12:13:25 -0800 (PST) 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 uBGKDLT7006410 for ; Fri, 16 Dec 2016 21:13:21 +0100 (CET) Received: from mail-wj0-f177.google.com (mail-wj0-f177.google.com [209.85.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tgM294cgJz8LZs for ; Fri, 16 Dec 2016 21:13:21 +0100 (CET) Received: by mail-wj0-f177.google.com with SMTP id v7so100739860wjy.2 for ; Fri, 16 Dec 2016 12:13:21 -0800 (PST) X-Gm-Message-State: AIkVDXK93F09oBGP4oW9p/CQI0tLCeE4Hp39CHiJx26hR7wJ4gKLpwuXnz4g6UoWo4Eq+m4FbLOvj03CN/JKag== X-Received: by 10.194.21.201 with SMTP id x9mr4016376wje.153.1481919201214; Fri, 16 Dec 2016 12:13:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.108.227 with HTTP; Fri, 16 Dec 2016 12:12:40 -0800 (PST) In-Reply-To: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> From: Klaus Hartke Date: Fri, 16 Dec 2016 21:12:40 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 20:13:28 -0000 Michel Veillette wrote: > To resolve this issue (long term relationship between network elements and management station), > my personal preference is to extend the current observe mechanism to make it more resilient > to transmission failures. Using CoAP default parameters [1], a server will transmit a confirmable notification 5 times over a period of 62 to 93 seconds if the client does not react. If that's not enough, the number of retransmissions can be increased: "MAX_RETRANSMIT can be freely adjusted, but a value that is too small will reduce the probability that a Confirmable message is actually received, while a larger value than given here will require further adjustments in the time values (see Section 4.8.2)." [2] So if you want, you can let the server try to reach the client for several hours. However, the idea is that the server gives up after a reasonable amount of time and it becomes the responsibility of the client to try to reach the server. This way, the server (which is often the more constrained node) is freed from wasting resources on clients that are no longer there. Related to the discussion, don't forget that CoAP is a state transfer protocol, not a message queue. The only event that CoAP-Observe can notify is the event that resource state changed. If you need to monitor other kinds of events, you must first convert them to resource state for Observe, e.g., by appending them to a log file. Klaus [1] https://tools.ietf.org/html/rfc7252#section-4.8 [2] https://tools.ietf.org/html/rfc7252#section-4.8.1 From nobody Fri Dec 16 13:02:59 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BD1296CB for ; Fri, 16 Dec 2016 13:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfczXle19eYq for ; Fri, 16 Dec 2016 13:02:56 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0139.outbound.protection.outlook.com [104.47.36.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A81129E3D for ; Fri, 16 Dec 2016 13:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2SR9hLs0dPqG6fJiXK/O3zjMD7nMFcBhRnhIdx04bqc=; b=NbmVMWWHJ7N/uUFbQu4nBWmHB4QleQ/NDP5hO3lgJJXsEf5wlBlnZ9+PgMtCT6YozVwX5x89qVbSlHwJqlbsNwVPkqZ7PzD5K6iMdB7/sZ7XdnZj55uqR94hZSS/rqmAvqufzbnrHAUX60UjEWY31Z/L0o/NcxnKgMSf15VZoQw= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2306.namprd06.prod.outlook.com (10.173.19.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Fri, 16 Dec 2016 21:02:53 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0771.017; Fri, 16 Dec 2016 21:02:53 +0000 From: Michel Veillette To: Klaus Hartke Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAAeYc+AABHhG3AACCaLAAAAuNQg Date: Fri, 16 Dec 2016 21:02:53 +0000 Message-ID: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: a65122c4-7402-4930-98bd-08d425f6e755 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2306; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2306; 7:mrcufrxWaI7o18anp3kzHVsCUecMXpwSQV7pR4IXkUcapJ4VlXXwsea7BMBqFxKzQ1cmkbSNqgF1oYzgJH8mvbRjdgSLYWx54l0yGZFS3NrawCZnCi+2Wy58mW+BFycQf63OpVv5U/JKVwbUeqs/IrefutQr6nQRV2J7EXwGEe9koATeBE1h5HEdTtIdSbvUjumxKfrSHA6hFAhKkAa2PPBy1KqPhwBbmoYBKuwGUnQUcBkfZkTb7GslX3SLZlMAlDJ/rfdSp/wKe6lvZyMCvTt9VJOijL08LnkHkHRF230p9kfrUumwWBc2cRXUcaFpGav4pCix2iajapVmL7coWHrpYp00nOLsQR1ZzjK5x8uKx8vjDkQYddgBfJ3NWvGORGwL/fWOpajK9yZjWUY/kB2B5hHRpbBp4YeMENXmh/Oq6KGacO/b1DQ/Ge1SnW2JP672iBZkkLfl9nrNhFKIFg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BN6PR06MB2306; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2306; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(24454002)(13464003)(199003)(189002)(377454003)(86362001)(229853002)(3280700002)(2906002)(7736002)(110136003)(305945005)(6916009)(33656002)(7696004)(2950100002)(25786008)(122556002)(77096006)(6506006)(38730400001)(6436002)(50986999)(54356999)(8936002)(105586002)(76176999)(9686002)(101416001)(74316002)(81166006)(3660700001)(2900100001)(97736004)(81156014)(99286002)(106356001)(8676002)(3846002)(68736007)(93886004)(6116002)(92566002)(189998001)(76576001)(102836003)(66066001)(4326007)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2306; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 21:02:53.6979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2306 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 21:02:59 -0000 SGkgS2xhdXMNCg0KRWZmZWN0aXZlbHksIHRoZSBDb0FQIHJldHJhbnNtaXNzaW9uIHBhcmFtZXRl cnMgKEFDS19USU1FT1VULCBBQ0tfUkFORE9NX0ZBQ1RPUiwgYW5kIE1BWF9SRVRSQU5TTUlUKSBj YW4gYmUgY2hhbmdlZCBidXQgdGhpcyB3aWxsIGFmZmVjdCBhbGwgQ29BUCBtZXNzYWdlcyB0cmFu c21pdHRlZCBieSB0aGUgQ29BUCBzZXJ2ZXIsIG5vdCBqdXN0IHRoZSBub3RpZmljYXRpb25zLiBD aGFuZ2luZyB0aGVzZSB0aW1pbmdzIGdsb2JhbGx5IGlzIG5vdCBhY2NlcHRhYmxlLg0KDQpGdXJ0 aGVybW9yZSwgdGhlIGdvYWwgaXMgbm90IHRvIGluY3JlYXNlIHRoZSByZWxpYWJpbGl0eSBvZiBh IHNpbmdsZSBub3RpZmljYXRpb24gYnkgc3ByZWFkaW5nIHJldHJpZXMgb24gYSBsb25nZXIgcGVy aW9kIG9yIGJ5IHBlcmZvcm1pbmcgbW9yZSByZXRyaWVzLiBUeXBpY2FsbHksIG5vdGlmaWNhdGlv bnMgbG9zZSB0aGVpciB1c2VmdWxuZXNzIGlmIHRoZXkgYXJlIGRlbGF5ZWQgdG9vIG11Y2guIFRo ZSBnb2FsIGlzIHRvIGtlZXAgdGhlIGNsaWVudCBpbiB0aGUgb2JzZXJ2YWJsZSBsaXN0IGV2ZW4g aW4gdGhlIGNhc2Ugb2YgdHJhbnNtaXNzaW9uIGZhaWx1cmVzIGFuZCB0aGlzIGZvciBhIHJlYXNv bmFibGUgcGVyaW9kLg0KDQpUaGUgZm9sbG93aW5nIHNjZW5hcmlvIHJlcHJlc2VudHMgdGhlIGN1 cnJlbnQgYmVoYXZpb3IgbWFuZGF0ZWQgYnkgUkZDIDc2NDE6DQogIE5vdGlmaWNhdGlvbiAgMSAt LS0+ICAoVHJhbnNtaXNzaW9uIHN1Y2Nlc3NmdWwpDQogIE5vdGlmaWNhdGlvbiAgMiAtLS0+DQog IE5vdGlmaWNhdGlvbiAgMyAtLS1YICAoVHJhbnNtaXNzaW9uIGZhaWx1cmUsIGNsaWVudCByZW1v dmVkIGZyb20gdGhlIGxpc3Qgb2Ygb2JzZXJ2ZXJzKQ0KDQpJJ20gcHJvcG9zaW5nIHRvIGFsc28g c3VwcG9ydCBhIG1vcmUgcmVzaWxpZW50IHNvbHV0aW9uIHdoaWNoIHN1cHBvcnQgdGhlIGZvbGxv d2luZyBzY2VuYXJpbzoNCiAgTm90aWZpY2F0aW9uICAxIC0tLT4gDQogIE5vdGlmaWNhdGlvbiAg MiAtLS1YDQogIE5vdGlmaWNhdGlvbiAgMyAtLS0+DQogIE5vdGlmaWNhdGlvbiAgNCAtLS0+DQog IE5vdGlmaWNhdGlvbiAgNSAtLS1YDQogIE5vdGlmaWNhdGlvbiAgNiAtLS0+DQogIE5vdGlmaWNh dGlvbiAgNyAtLS1YDQogIE5vdGlmaWNhdGlvbiAgOCAtLS1YDQogIE5vdGlmaWNhdGlvbiAgOSAt LS1YICAgICh4IGNvbnNlY3V0aXZlIHRyYW5zbWlzc2lvbiBmYWlsdXJlcywgY2xpZW50IHJlbW92 ZWQgZnJvbSB0aGUgbGlzdCBvZiBvYnNlcnZlcnMpDQoNClJlZ2FyZHMsDQpNaWNoZWwNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEtsYXVzIEhhcnRrZSBbbWFpbHRvOmhhcnRr ZUB0emkub3JnXSANClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTYsIDIwMTYgMzoxMyBQTQ0KVG86 IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT4NCkNj OiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzsgQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbY29yZV0gQ29NSSAtIGxvbmcgdGVybSByZWxhdGlvbnNoaXAgYmV0d2VlbiBuZXR3 b3JrIGVsZW1lbnRzIGFuZCBtYW5hZ2VtZW50IHN0YXRpb24NCg0KTWljaGVsIFZlaWxsZXR0ZSB3 cm90ZToNCj4gVG8gcmVzb2x2ZSB0aGlzIGlzc3VlIChsb25nIHRlcm0gcmVsYXRpb25zaGlwIGJl dHdlZW4gbmV0d29yayBlbGVtZW50cyANCj4gYW5kIG1hbmFnZW1lbnQgc3RhdGlvbiksICBteSBw ZXJzb25hbCBwcmVmZXJlbmNlIGlzIHRvIGV4dGVuZCB0aGUgDQo+IGN1cnJlbnQgb2JzZXJ2ZSBt ZWNoYW5pc20gdG8gbWFrZSBpdCBtb3JlIHJlc2lsaWVudCB0byB0cmFuc21pc3Npb24gZmFpbHVy ZXMuDQoNClVzaW5nIENvQVAgZGVmYXVsdCBwYXJhbWV0ZXJzIFsxXSwgYSBzZXJ2ZXIgd2lsbCB0 cmFuc21pdCBhIGNvbmZpcm1hYmxlIG5vdGlmaWNhdGlvbiA1IHRpbWVzIG92ZXIgYSBwZXJpb2Qg b2YgNjIgdG8gOTMgc2Vjb25kcyBpZiB0aGUgY2xpZW50IGRvZXMgbm90IHJlYWN0LiBJZiB0aGF0 J3Mgbm90IGVub3VnaCwgdGhlIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbnMgY2FuIGJlIGluY3Jl YXNlZDoNCg0KICAgIk1BWF9SRVRSQU5TTUlUIGNhbiBiZSBmcmVlbHkgYWRqdXN0ZWQsIGJ1dCBh IHZhbHVlIHRoYXQgaXMgdG9vIHNtYWxsDQogICB3aWxsIHJlZHVjZSB0aGUgcHJvYmFiaWxpdHkg dGhhdCBhIENvbmZpcm1hYmxlIG1lc3NhZ2UgaXMgYWN0dWFsbHkNCiAgIHJlY2VpdmVkLCB3aGls ZSBhIGxhcmdlciB2YWx1ZSB0aGFuIGdpdmVuIGhlcmUgd2lsbCByZXF1aXJlIGZ1cnRoZXINCiAg IGFkanVzdG1lbnRzIGluIHRoZSB0aW1lIHZhbHVlcyAoc2VlIFNlY3Rpb24gNC44LjIpLiIgWzJd DQoNClNvIGlmIHlvdSB3YW50LCB5b3UgY2FuIGxldCB0aGUgc2VydmVyIHRyeSB0byByZWFjaCB0 aGUgY2xpZW50IGZvciBzZXZlcmFsIGhvdXJzLiBIb3dldmVyLCB0aGUgaWRlYSBpcyB0aGF0IHRo ZSBzZXJ2ZXIgZ2l2ZXMgdXAgYWZ0ZXIgYSByZWFzb25hYmxlIGFtb3VudCBvZiB0aW1lIGFuZCBp dCBiZWNvbWVzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgY2xpZW50IHRvIHRyeSB0byByZWFj aCB0aGUgc2VydmVyLiBUaGlzIHdheSwgdGhlIHNlcnZlciAod2hpY2ggaXMgb2Z0ZW4gdGhlIG1v cmUgY29uc3RyYWluZWQgbm9kZSkgaXMgZnJlZWQgZnJvbSB3YXN0aW5nIHJlc291cmNlcyBvbiBj bGllbnRzIHRoYXQgYXJlIG5vIGxvbmdlciB0aGVyZS4NCg0KUmVsYXRlZCB0byB0aGUgZGlzY3Vz c2lvbiwgZG9uJ3QgZm9yZ2V0IHRoYXQgQ29BUCBpcyBhIHN0YXRlIHRyYW5zZmVyIHByb3RvY29s LCBub3QgYSBtZXNzYWdlIHF1ZXVlLiBUaGUgb25seSBldmVudCB0aGF0IENvQVAtT2JzZXJ2ZSBj YW4gbm90aWZ5IGlzIHRoZSBldmVudCB0aGF0IHJlc291cmNlIHN0YXRlIGNoYW5nZWQuIElmIHlv dSBuZWVkIHRvIG1vbml0b3Igb3RoZXIga2luZHMgb2YgZXZlbnRzLCB5b3UgbXVzdCBmaXJzdCBj b252ZXJ0IHRoZW0gdG8gcmVzb3VyY2Ugc3RhdGUgZm9yIE9ic2VydmUsIGUuZy4sIGJ5IGFwcGVu ZGluZyB0aGVtIHRvIGEgbG9nIGZpbGUuDQoNCktsYXVzDQoNClsxXSBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTQuOA0KWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tNC44LjENCg== From nobody Fri Dec 16 13:32:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA325129F32 for ; Fri, 16 Dec 2016 13:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] 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 KyAnOUjnL5YK for ; Fri, 16 Dec 2016 13:32:35 -0800 (PST) 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 2B482129F4E for ; Fri, 16 Dec 2016 13:32:35 -0800 (PST) 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 uBGLWVgj004551 for ; Fri, 16 Dec 2016 22:32:31 +0100 (CET) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tgNnW4Jj7z8LbK for ; Fri, 16 Dec 2016 22:32:31 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id g23so46466935wme.1 for ; Fri, 16 Dec 2016 13:32:31 -0800 (PST) X-Gm-Message-State: AIkVDXLezfqbEsWaV2uYAR/4Xwqjx79LPCozglkfdOhoSahuJxRQH0pjlMME4fqbQssmPdsKHi6R5VQiAK9NZQ== X-Received: by 10.28.68.195 with SMTP id r186mr4222768wma.105.1481923951155; Fri, 16 Dec 2016 13:32:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.108.227 with HTTP; Fri, 16 Dec 2016 13:31:50 -0800 (PST) In-Reply-To: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> From: Klaus Hartke Date: Fri, 16 Dec 2016 22:31:50 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 21:32:36 -0000 Michel Veillette wrote: > Effectively, the CoAP retransmission parameters (ACK_TIMEOUT, ACK_RANDOM_= FACTOR, and MAX_RETRANSMIT) can be changed but this will affect all CoAP me= ssages transmitted by the CoAP server, not just the notifications. Changing= these timings globally is not acceptable. Then change it only for notifications? > Furthermore, the goal is not to increase the reliability of a single noti= fication by spreading retries on a longer period or by performing more retr= ies. Typically, notifications lose their usefulness if they are delayed too= much. The goal is to keep the client in the observable list even in the ca= se of transmission failures and this for a reasonable period. > > The following scenario represents the current behavior mandated by RFC 76= 41: > Notification 1 ---> (Transmission successful) > Notification 2 ---> > Notification 3 ---X (Transmission failure, client removed from the li= st of observers) (Assuming the transmission failure is the result of 5 transmission attempts. So it looks more like this:) Notification 1 ---> Notification 2 ---> Notification 3 ---X (attempt 0) Notification 3 ---X (attempt 1) Notification 3 ---X (attempt 2) Notification 3 ---X (attempt 3) Notification 3 ---X (attempt 4) (client removed from the list of observ= ers) > I'm proposing to also support a more resilient solution which support the= following scenario: > Notification 1 ---> > Notification 2 ---X > Notification 3 ---> > Notification 4 ---> > Notification 5 ---X > Notification 6 ---> > Notification 7 ---X > Notification 8 ---X > Notification 9 ---X (x consecutive transmission failures, client re= moved from the list of observers) This is what you get when you increase MAX_RETRANSMIT, except that the server will also retransmit the latest notification between two state changes: Notification 1 ---> Notification 2 ---X Notification 3 ---> Notification 4 ---> Notification 5 ---X Notification 6 ---> Notification 7 ---X (attempt 0) Notification 7 ---X (attempt 1) Notification 7 ---X (attempt 2) Notification 8 ---X (attempt 3) Notification 9 ---X (attempt 4) (client removed from the list of observe= rs) If you don't like that, don't do it? Klaus From nobody Fri Dec 16 13:59:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BBA12946C for ; Fri, 16 Dec 2016 13:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OI4ZP0t4_RS for ; Fri, 16 Dec 2016 13:59:54 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0136.outbound.protection.outlook.com [104.47.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9596812946B for ; Fri, 16 Dec 2016 13:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9gGilcMzYhwb5VZ1NuieV/E6y782Y3qOd0n5du6csyg=; b=dJoxWdNYQZvKVCeifDk1x62aeYuzde3mDagfNYuZkV79vtFRxWxTVQaKpDILlBHwWxPwtP8nO0e2SmoMNoGjfW0XfeavlYvZBgA2nkrzSQqWrvZM4JHewdoUyTR0SYWjCt0x93cmSGhRJ2aC33eRe0wbsAiH2wgOnFbDZnsRbXI= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Fri, 16 Dec 2016 21:59:53 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0771.017; Fri, 16 Dec 2016 21:59:53 +0000 From: Michel Veillette To: Klaus Hartke Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAAeYc+AABHhG3AACCaLAAAAuNQgAAIK+gAAADfnEA== Date: Fri, 16 Dec 2016 21:59:52 +0000 Message-ID: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 588bfb58-98e0-4e77-cf93-08d425fedd4f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2305; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 7:J75UWsNHA6msdwn44904hiiG/UzuX1MINnBr5d1JqVclZ4QSwnosF6WxclBWJ01Krvsy+xfKGr5imHDN8TlD6JiB137y+VXSzcsBLZOWRG1TEJHpko2lkf2xCQVEwj1WZKQDWDIWHGuR9x2ZugCm1Pzkbs79yn7a4VcGRUJOcdpGgGCQUOpV/ndgITk9Npqi+yDzf6Jwa0Q44T+cMC5/g3asxPzs3hS4SeCoCN3xtoUzoco2mqvvkL/Wwq8hYPS80JP7dAzqIfxLrKf5RzW4Xd8j18SMUIGkE+7P7Xx6OEzPwAryzsz7W2f3NlF0Swh881y2a/ELG3y3rl9C01CjE1yN/chziEgQwTPcwkJSNWLIJzCxZQeraGCS9gbQz6dNVpko3gRUYBGL5SUbouLSzLIhunJQ2BvHm6sqxnWbTlXoA6t12lp/aqYxAbLZy2kdOZtiawnT+O0NuqvMCHSMxA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558021)(20161123562025)(6072148); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39450400003)(199003)(377454003)(189002)(13464003)(24454002)(9686002)(8936002)(7696004)(81166006)(92566002)(8676002)(3846002)(102836003)(86362001)(6506006)(105586002)(6116002)(99286002)(54356999)(97736004)(4326007)(38730400001)(33656002)(74316002)(101416001)(106356001)(76176999)(122556002)(229853002)(68736007)(50986999)(110136003)(3660700001)(76576001)(77096006)(81156014)(7736002)(93886004)(2906002)(305945005)(189998001)(6436002)(2900100001)(5660300001)(25786008)(2950100002)(6916009)(66066001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 21:59:52.8636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 21:59:57 -0000 QWJvdXQgIlRoZW4gY2hhbmdlIGl0IG9ubHkgZm9yIG5vdGlmaWNhdGlvbnM/Ig0KDQpUaGUgQ29B UCBpbXBsZW1lbnRhdGlvbnMgSSdtIGN1cnJlbnRseSB1c2luZyBkb27igJl0IGFsbG93IHRoZSB1 c2Ugb2YgbXVsdGlwbGUgc2V0IG9mIHJlLXRyYW5zbWlzc2lvbiBwYXJhbWV0ZXJzLCB0aG9zZSBh cmUgZ2xvYmFsLg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgQ29BUCBpbXBsZW1lbnRhdGlvbnMgY2Fw YWJsZSBvZiBzdXBwb3J0aW5nIHRoaXMgYXBwcm9hY2g/DQoNCkFib3V0IHRoZSBsYXN0IHNjZW5h cmlvLCBpcyBpdCByZWFsbHkgYWxsb3dlZCBieSBSRkM3MjUyIHRvIGNoYW5nZSB0aGUgY29udGVu dCBvZiBhIENvQVAgbWVzc2FnZSBkdXJpbmcgdGhlIHJldHJhbnNtaXNzaW9uIHByb2Nlc3MgKEJl dHdlZW4gYXR0ZW1wdCAyIGFuZCAzIGluIHlvdXIgZXhhbXBsZSk/IEluIHRoZSBzcGVjaWZpY2F0 aW9uLCBpdCBpcyBjbGVhciB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGNhbiBhbnN3ZXIgdG8gYSBk dXBsaWNhdGUgcmVxdWVzdCB1c2luZyBhbiB1cGRhdGVkIGNvbnRlbnQgKHNlY3Rpb24gNC41KSBi dXQgZm9yIHRoZSByZXRyaWVzLCB0aGUgc3BlYyBhbHdheXMgcmVmZXIgdG8gYSByZS10cmFuc21p c3Npb24uDQoNCiAgTm90aWZpY2F0aW9uICAxIC0tLT4NCiAgTm90aWZpY2F0aW9uICAyIC0tLVgN CiAgTm90aWZpY2F0aW9uICAzIC0tLT4NCiAgTm90aWZpY2F0aW9uICA0IC0tLT4NCiAgTm90aWZp Y2F0aW9uICA1IC0tLVgNCiAgTm90aWZpY2F0aW9uICA2IC0tLT4NCiAgTm90aWZpY2F0aW9uICA3 IC0tLVggKGF0dGVtcHQgMCkNCiAgTm90aWZpY2F0aW9uICA3IC0tLVggKGF0dGVtcHQgMSkNCiAg Tm90aWZpY2F0aW9uICA3IC0tLVggKGF0dGVtcHQgMikNCiAgTm90aWZpY2F0aW9uICA4IC0tLVgg KGF0dGVtcHQgMykNCiAgTm90aWZpY2F0aW9uICA5IC0tLVggKGF0dGVtcHQgNCkgKGNsaWVudCBy ZW1vdmVkIGZyb20gdGhlIGxpc3Qgb2Ygb2JzZXJ2ZXJzKQ0KDQpSZWdhcmRzLA0KTWljaGVsDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLbGF1cyBIYXJ0a2UgW21haWx0bzpo YXJ0a2VAdHppLm9yZ10gDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDE2LCAyMDE2IDQ6MzIgUE0N ClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+ DQpDYzogQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gQ29NSSAtIGxv bmcgdGVybSByZWxhdGlvbnNoaXAgYmV0d2VlbiBuZXR3b3JrIGVsZW1lbnRzIGFuZCBtYW5hZ2Vt ZW50IHN0YXRpb24NCg0KTWljaGVsIFZlaWxsZXR0ZSB3cm90ZToNCj4gRWZmZWN0aXZlbHksIHRo ZSBDb0FQIHJldHJhbnNtaXNzaW9uIHBhcmFtZXRlcnMgKEFDS19USU1FT1VULCBBQ0tfUkFORE9N X0ZBQ1RPUiwgYW5kIE1BWF9SRVRSQU5TTUlUKSBjYW4gYmUgY2hhbmdlZCBidXQgdGhpcyB3aWxs IGFmZmVjdCBhbGwgQ29BUCBtZXNzYWdlcyB0cmFuc21pdHRlZCBieSB0aGUgQ29BUCBzZXJ2ZXIs IG5vdCBqdXN0IHRoZSBub3RpZmljYXRpb25zLiBDaGFuZ2luZyB0aGVzZSB0aW1pbmdzIGdsb2Jh bGx5IGlzIG5vdCBhY2NlcHRhYmxlLg0KDQpUaGVuIGNoYW5nZSBpdCBvbmx5IGZvciBub3RpZmlj YXRpb25zPw0KDQo+IEZ1cnRoZXJtb3JlLCB0aGUgZ29hbCBpcyBub3QgdG8gaW5jcmVhc2UgdGhl IHJlbGlhYmlsaXR5IG9mIGEgc2luZ2xlIG5vdGlmaWNhdGlvbiBieSBzcHJlYWRpbmcgcmV0cmll cyBvbiBhIGxvbmdlciBwZXJpb2Qgb3IgYnkgcGVyZm9ybWluZyBtb3JlIHJldHJpZXMuIFR5cGlj YWxseSwgbm90aWZpY2F0aW9ucyBsb3NlIHRoZWlyIHVzZWZ1bG5lc3MgaWYgdGhleSBhcmUgZGVs YXllZCB0b28gbXVjaC4gVGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgY2xpZW50IGluIHRoZSBvYnNl cnZhYmxlIGxpc3QgZXZlbiBpbiB0aGUgY2FzZSBvZiB0cmFuc21pc3Npb24gZmFpbHVyZXMgYW5k IHRoaXMgZm9yIGEgcmVhc29uYWJsZSBwZXJpb2QuDQo+DQo+IFRoZSBmb2xsb3dpbmcgc2NlbmFy aW8gcmVwcmVzZW50cyB0aGUgY3VycmVudCBiZWhhdmlvciBtYW5kYXRlZCBieSBSRkMgNzY0MToN Cj4gICBOb3RpZmljYXRpb24gIDEgLS0tPiAgKFRyYW5zbWlzc2lvbiBzdWNjZXNzZnVsKQ0KPiAg IE5vdGlmaWNhdGlvbiAgMiAtLS0+DQo+ICAgTm90aWZpY2F0aW9uICAzIC0tLVggIChUcmFuc21p c3Npb24gZmFpbHVyZSwgY2xpZW50IHJlbW92ZWQgZnJvbSB0aGUgDQo+IGxpc3Qgb2Ygb2JzZXJ2 ZXJzKQ0KDQooQXNzdW1pbmcgdGhlIHRyYW5zbWlzc2lvbiBmYWlsdXJlIGlzIHRoZSByZXN1bHQg b2YgNSB0cmFuc21pc3Npb24gYXR0ZW1wdHMuIFNvIGl0IGxvb2tzIG1vcmUgbGlrZSB0aGlzOikN Cg0KICAgTm90aWZpY2F0aW9uICAxIC0tLT4NCiAgIE5vdGlmaWNhdGlvbiAgMiAtLS0+DQogICBO b3RpZmljYXRpb24gIDMgLS0tWCAoYXR0ZW1wdCAwKQ0KICAgTm90aWZpY2F0aW9uICAzIC0tLVgg KGF0dGVtcHQgMSkNCiAgIE5vdGlmaWNhdGlvbiAgMyAtLS1YIChhdHRlbXB0IDIpDQogICBOb3Rp ZmljYXRpb24gIDMgLS0tWCAoYXR0ZW1wdCAzKQ0KICAgTm90aWZpY2F0aW9uICAzIC0tLVggKGF0 dGVtcHQgNCkgKGNsaWVudCByZW1vdmVkIGZyb20gdGhlIGxpc3Qgb2Ygb2JzZXJ2ZXJzKQ0KDQo+ IEknbSBwcm9wb3NpbmcgdG8gYWxzbyBzdXBwb3J0IGEgbW9yZSByZXNpbGllbnQgc29sdXRpb24g d2hpY2ggc3VwcG9ydCB0aGUgZm9sbG93aW5nIHNjZW5hcmlvOg0KPiAgIE5vdGlmaWNhdGlvbiAg MSAtLS0+DQo+ICAgTm90aWZpY2F0aW9uICAyIC0tLVgNCj4gICBOb3RpZmljYXRpb24gIDMgLS0t Pg0KPiAgIE5vdGlmaWNhdGlvbiAgNCAtLS0+DQo+ICAgTm90aWZpY2F0aW9uICA1IC0tLVgNCj4g ICBOb3RpZmljYXRpb24gIDYgLS0tPg0KPiAgIE5vdGlmaWNhdGlvbiAgNyAtLS1YDQo+ICAgTm90 aWZpY2F0aW9uICA4IC0tLVgNCj4gICBOb3RpZmljYXRpb24gIDkgLS0tWCAgICAoeCBjb25zZWN1 dGl2ZSB0cmFuc21pc3Npb24gZmFpbHVyZXMsIGNsaWVudCByZW1vdmVkIGZyb20gdGhlIGxpc3Qg b2Ygb2JzZXJ2ZXJzKQ0KDQpUaGlzIGlzIHdoYXQgeW91IGdldCB3aGVuIHlvdSBpbmNyZWFzZSBN QVhfUkVUUkFOU01JVCwgZXhjZXB0IHRoYXQgdGhlIHNlcnZlciB3aWxsIGFsc28gcmV0cmFuc21p dCB0aGUgbGF0ZXN0IG5vdGlmaWNhdGlvbiBiZXR3ZWVuIHR3byBzdGF0ZQ0KY2hhbmdlczoNCg0K ICBOb3RpZmljYXRpb24gIDEgLS0tPg0KICBOb3RpZmljYXRpb24gIDIgLS0tWA0KICBOb3RpZmlj YXRpb24gIDMgLS0tPg0KICBOb3RpZmljYXRpb24gIDQgLS0tPg0KICBOb3RpZmljYXRpb24gIDUg LS0tWA0KICBOb3RpZmljYXRpb24gIDYgLS0tPg0KICBOb3RpZmljYXRpb24gIDcgLS0tWCAoYXR0 ZW1wdCAwKQ0KICBOb3RpZmljYXRpb24gIDcgLS0tWCAoYXR0ZW1wdCAxKQ0KICBOb3RpZmljYXRp b24gIDcgLS0tWCAoYXR0ZW1wdCAyKQ0KICBOb3RpZmljYXRpb24gIDggLS0tWCAoYXR0ZW1wdCAz KQ0KICBOb3RpZmljYXRpb24gIDkgLS0tWCAoYXR0ZW1wdCA0KSAoY2xpZW50IHJlbW92ZWQgZnJv bSB0aGUgbGlzdCBvZiBvYnNlcnZlcnMpDQoNCklmIHlvdSBkb24ndCBsaWtlIHRoYXQsIGRvbid0 IGRvIGl0Pw0KDQpLbGF1cw0K From nobody Fri Dec 16 14:41:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F208D129424 for ; Fri, 16 Dec 2016 14:41:08 -0800 (PST) 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 t2ZUkHJBANe1 for ; Fri, 16 Dec 2016 14:41:07 -0800 (PST) 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 6D7741293EC for ; Fri, 16 Dec 2016 14:41:07 -0800 (PST) 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 uBGMf28m023594 for ; Fri, 16 Dec 2016 23:41:02 +0100 (CET) Received: from mail-wj0-f175.google.com (mail-wj0-f175.google.com [209.85.210.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tgQJZ3Bqqz8LcG for ; Fri, 16 Dec 2016 23:41:02 +0100 (CET) Received: by mail-wj0-f175.google.com with SMTP id v7so103220487wjy.2 for ; Fri, 16 Dec 2016 14:41:02 -0800 (PST) X-Gm-Message-State: AIkVDXIzpkOe60yiQ2dzmxg8sICVL3kCGrMto6fN6cZ39P8REnKpyQOKH8QXQG+UM8Jsh0eFfGs1VyRdjc+kfQ== X-Received: by 10.194.137.104 with SMTP id qh8mr4620934wjb.69.1481928062070; Fri, 16 Dec 2016 14:41:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.108.227 with HTTP; Fri, 16 Dec 2016 14:40:21 -0800 (PST) In-Reply-To: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> From: Klaus Hartke Date: Fri, 16 Dec 2016 23:40:21 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 22:41:09 -0000 Michel Veillette wrote: > About "Then change it only for notifications?" > > The CoAP implementations I'm currently using don=E2=80=99t allow the use = of multiple set of re-transmission parameters, those are global. > Are you aware of any CoAP implementations capable of supporting this appr= oach? A CoAP implementation maintains a timeout and a retransmission counter for each active confirmable message. It shouldn't be too difficult to pass the initial values as parameters (approximately around the line of code that determines if the message is confirmable or non-confirmable) instead of using the default values. I've just made this change to my (unpublished) implementation and it took me about 20 seconds. > About the last scenario, is it really allowed by RFC7252 to change the co= ntent of a CoAP message during the retransmission process (Between attempt = 2 and 3 in your example)? In the specification, it is clear that an impleme= ntation can answer to a duplicate request using an updated content (section= 4.5) but for the retries, the spec always refer to a re-transmission. That's what Section 4.5.2 of RFC 7641 [1] is about. The transmission of the older notification is aborted and a new transmission is started with the timeout and the retransmission counter of the aborted transmission. Klaus [1] https://tools.ietf.org/html/rfc7641#section-4.5.2 From nobody Mon Dec 19 06:48:10 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 061A1128B38; Mon, 19 Dec 2016 06:48:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148215888501.12735.12065058015857575246.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 06:48:05 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-object-security-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:48:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Object Security of CoAP (OSCOAP) Authors : Goeran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-01.txt Pages : 45 Date : 2016-12-19 Abstract: This memo defines Object Security of CoAP (OSCOAP), a method for application layer protection of message exchanges with the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE) format. OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure binding between CoAP request and response messages. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-object-security-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 19 07:01:13 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725D6129B07; Mon, 19 Dec 2016 07:01:12 -0800 (PST) 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 3Jv8bLzbA5KG; Mon, 19 Dec 2016 07:01:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167D8129A97; Mon, 19 Dec 2016 07:01:09 -0800 (PST) X-AuditID: c1b4fb2d-26a859800000561e-86-5857f63467a3 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 1E.DB.22046.436F7585; Mon, 19 Dec 2016 16:01:08 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.95]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Mon, 19 Dec 2016 16:01:07 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-object-security-01.txt Thread-Index: AQHSWgb4mpEDVsUQNk2o6TSgs6NxSqEPXWOA Date: Mon, 19 Dec 2016 15:01:30 +0000 Message-ID: References: <148215888501.12735.12065058015857575246.idtracker@ietfa.amsl.com> In-Reply-To: <148215888501.12735.12065058015857575246.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-ID: <2482DA9815E86347B4AF4C7804B038C9@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7n67Jt/AIg3Pt4hb73q5ntliy6zmz xYe7uQ7MHkuW/GQKYIzisklJzcksSy3St0vgymiZMI+5YI1UxbzzTWwNjFckuxg5OSQETCTW TjrO0sXIxSEksI5R4unfp4wQzmJGiQ/rP7ODVLEJuEg8aHjEBGKLCORI3P39lAXEZhZQljg+ +zAriC0s4Cax8PJjRogad4nGvRfYIGwjiQ0fd4PZLAKqEtvnfwWbwytgIbHk9QkwW0jAT2LW 8n6wGk4Bf4mPqzvBZjIKiEl8P7WGCWKXuMStJ/OZIK4WkFiy5zwzhC0q8fLxP7B6UQE9idlT GoBu5gCKK0lM25oGYjILaEqs36UPMcVaYsayL1DXK0pM6X7IDnGNoMTJmU9YJjCKz0KybBZC 9ywk3bOQdM9C0r2AkXUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmCkHdzyW3cH4+rXjocY BTgYlXh4P4iERwixJpYVV+YeYpTgYFYS4W3+CBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7by friQQHpiSWp2ampBahFMlomDU6qBMf+ZSUNdrmzClHI+/sWX//H/Y2MPu+P/w6M4LW6r+649 T38a1O1b0pmabXYg67PO062MfStvxL9uaHgbtPvyro6HnrZu+VyxJv4WtWohius1W3mXvPLz m33mTO29rLyVa6MkTaM3PDy9JbLae7d9i6KTqcYMpw69pYuMdlkb6cYL264sNtyrxFKckWio xVxUnAgAAUM4frACAAA= Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-object-security-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:01:12 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIHZlcnNpb24gLTAxIG9mIE9TQ09BUCBzcGVj aWZ5aW5nIHNvbWUgbWlzc2luZyBkZXRhaWxzLA0KYW5kIGNsYXJpZnlpbmcgc29tZSBwYXJ0cyB0 aGF0IHdlcmUgbWlzdW5kZXJzdG9vZCBiYXNlZCBvbiBjb21tZW50cyBtYWRlDQpkdXJpbmcgaW1w bGVtZW50YXRpb24uIFRoYW5rcyB0byBKaW0gZm9yIGZpbGxpbmcgdGhlIGlzc3VlIGxpc3QsIGZv cg0KZGV0YWlscywgcGxlYXNlIHNlZSBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2NvYXAN Cg0KDQpGb3IgdGhvc2Ugb2YgeW91IHdobyBhcmUgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcg T1NDT0FQLCBwbGVhc2UgdXNlDQp0aGlzIHZlcnNpb24gYW5kIGRvbuKAmXQgaGVzaXRhdGUgdG8g Y29udGFjdCB1cyBvciBvcGVuIGlzc3VlcyBkaXJlY3RseSBvbg0KdGhlIGdpdGh1Yi4NCg0KR8O2 cmFuDQoNCg0KDQoNCk9uIDIwMTYtMTItMTkgMTU6NDgsICJjb3JlIG9uIGJlaGFsZiBvZiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo8Y29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ZGly ZWN0b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29uc3RyYWluZWQg UkVTVGZ1bCBFbnZpcm9ubWVudHMgb2YgdGhlDQo+SUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAg ICAgICAgICA6IE9iamVjdCBTZWN1cml0eSBvZiBDb0FQIChPU0NPQVApDQo+ICAgICAgICBBdXRo b3JzICAgICAgICAgOiBHb2VyYW4gU2VsYW5kZXINCj4gICAgICAgICAgICAgICAgICAgICAgICAg IEpvaG4gTWF0dHNzb24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5jZXNjYSBQYWxv bWJpbmkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEx1ZHdpZyBTZWl0eg0KPglGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTAxLnR4dA0KPglQYWdl cyAgICAgICAgICAgOiA0NQ0KPglEYXRlICAgICAgICAgICAgOiAyMDE2LTEyLTE5DQo+DQo+QWJz dHJhY3Q6DQo+ICAgVGhpcyBtZW1vIGRlZmluZXMgT2JqZWN0IFNlY3VyaXR5IG9mIENvQVAgKE9T Q09BUCksIGEgbWV0aG9kIGZvcg0KPiAgIGFwcGxpY2F0aW9uIGxheWVyIHByb3RlY3Rpb24gb2Yg bWVzc2FnZSBleGNoYW5nZXMgd2l0aCB0aGUNCj4gICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQ cm90b2NvbCAoQ29BUCksIHVzaW5nIHRoZSBDQk9SIE9iamVjdA0KPiAgIFNpZ25pbmcgYW5kIEVu Y3J5cHRpb24gKENPU0UpIGZvcm1hdC4gIE9TQ09BUCBwcm92aWRlcyBlbmQtdG8tZW5kDQo+ICAg ZW5jcnlwdGlvbiwgaW50ZWdyaXR5IGFuZCByZXBsYXkgcHJvdGVjdGlvbiB0byBDb0FQIHBheWxv YWQsIG9wdGlvbnMsDQo+ICAgYW5kIGhlYWRlciBmaWVsZHMsIGFzIHdlbGwgYXMgYSBzZWN1cmUg YmluZGluZyBiZXR3ZWVuIENvQVAgcmVxdWVzdA0KPiAgIGFuZCByZXNwb25zZSBtZXNzYWdlcy4g IFRoZSB1c2Ugb2YgT1NDT0FQIGlzIHNpZ25hbGVkIHdpdGggdGhlIENvQVANCj4gICBvcHRpb24g T2JqZWN0LVNlY3VyaXR5LCBhbHNvIGRlZmluZWQgaW4gdGhpcyBtZW1vLg0KPg0KPg0KPlRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkv DQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkt MDENCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHktMDENCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Y29yZSBtYWlsaW5nIGxp c3QNCj5jb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlDQoNCg== From nobody Mon Dec 19 08:00:33 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC66129BA5 for ; Mon, 19 Dec 2016 08:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT3cjCCrC3bK for ; Mon, 19 Dec 2016 08:00:30 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0139.outbound.protection.outlook.com [104.47.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6D9129B8C for ; Mon, 19 Dec 2016 08:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+LNSDRiD87IE4M+lIlAHbP0Dqllrirxcaae43bpVF2g=; b=mZhf6WngWlGjmUqxwHR//gKPhVUcsCna/hlD//tHWl4I4SSV0Eq72uTzZPHk5rKU9VdPIfOGCXp7QsborCATsw+gCF63OVCoEGWriF0JGWZOwtnj6SqdjH+JABE/U76BEfrgh6IxpmDXrG50Gy3RIBWZAAS69dTFrvIOddHf+H4= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 16:00:27 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 16:00:27 +0000 From: Michel Veillette To: Klaus Hartke Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAAeYc+AABHhG3AACCaLAAAAuNQgAAIK+gAAADfnEAACLK+AAIe/JsA= Date: Mon, 19 Dec 2016 16:00:27 +0000 Message-ID: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: db2aec56-7409-4ced-8374-08d42828267b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2308; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 7:K+ad9kwNhkXw5cn5lU+tv2clYU2wJmeOtYgrz8mhDB2IMLKXAkTplSeUJzuD5rSM31ScyesGIqJ3APe8CgBXT6rvovdAuT1lts7wquVF+AAbSUcmbiMJ2bRilLzUBfDoVqnRTCN+j7vFAgWJPIxcY0UHFRyc8xI+DHQkW9R7M66lcfq4J71Xye8UdgiuUmyhEw/lZ/itp/RtD5tT5KyMNwn4KJsqGpLeD1HKw+dcft+mfoht+98q66JQuW+Whe3y3VO6+X1E4DYRRdtKHElLR+hf9qrNMqx4P6golwgtuQtdCPYY9Rv773ykDqcuC8ISCgGxPYq+lw+P1xePwiFx+kJ5vqEdf9KpKAIuueFlxiUFj+pDN9PDrCaVOJfxj7jjXjBtATzWQVlYjXr1zipzJxjAUjtdLQzROHOtlivL2fUkpsNjcyk6EsmztzYAoTqq4vebMYLc4iJg65nTr4rNAw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123558021)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39840400002)(13464003)(377454003)(199003)(24454002)(189002)(93886004)(101416001)(105586002)(6916009)(76176999)(54356999)(2900100001)(99286002)(50986999)(122556002)(92566002)(76576001)(68736007)(81166006)(8676002)(6116002)(81156014)(8936002)(3846002)(4326007)(9686002)(102836003)(7696004)(110136003)(106356001)(5660300001)(33656002)(2906002)(2950100002)(189998001)(305945005)(86362001)(6436002)(6506006)(74316002)(97736004)(3280700002)(38730400001)(77096006)(66066001)(3660700001)(25786008)(7736002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 16:00:27.2241 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 16:00:32 -0000 SGkgS2xhdXMgYW5kIHRoYW5rIGZvciB5b3VyIGFuc3dlcnMuDQoNClRoZSBwcm9wb3NlZCBhcHBy b2FjaCBhcmNoaXZlIGVmZmVjdGl2ZWx5IHRoZSBuZWNlc3NhcnkgcmVzaWxpZW5jZSBvZiB0aGUg b2JzZXJ2ZSBtZWNoYW5pc20uIFRoZSBvbmx5IGRyYXdiYWNrIGlzIHRoZSByZXF1aXJlbWVudCB0 byByZXRyeSBmb3IgYSBsb25nIHBlcmlvZCBhIHNwZWNpZmljIG5vdGlmaWNhdGlvbiwgd2hpY2gg bWlnaHQgYmUgYW4gaXNzdWUgd2hlbiB0aGlzIG5vdGlmaWNhdGlvbiBpcyBub3QgdGltZXN0YW1w LiAoQ29NSSB1bmxpa2UgUkVTQ09ORiBkb24ndCBtYW5kYXRlIHRoZSB1c2Ugb2YgZXZlbnQtdGlt ZSkuIEFzIGEgd29ya2Fyb3VuZCwgSSBzdXBwb3NlIHRoYXQgYSBudWxsIG5vdGlmaWNhdGlvbiBj YW4gYmUgYXV0b21hdGljYWxseSBnZW5lcmF0ZWQgYWZ0ZXIgeCByZXRyaWVzIGlmIGEgbmV3ZXIg bm90aWZpY2F0aW9uIGlzIG5vdCBhdmFpbGFibGUuDQoNCkZvciBleGFtcGxlOg0KDQogICBOb3Rp ZmljYXRpb24gIDEgLS0tPg0KICAgLi4uLg0KICAgTm90aWZpY2F0aW9uICAyIC0tLT4NCiAgIC4u Li4NCiAgIE5vdGlmaWNhdGlvbiAgMyAtLS1YICAgIChhdHRlbXB0IDApDQogICBOb3RpZmljYXRp b24gIDMgLS0tWCAgICAoYXR0ZW1wdCAxKQ0KICAgTm90aWZpY2F0aW9uICAzIC0tLVggICAgKGF0 dGVtcHQgMikNCiAgIE5vdGlmaWNhdGlvbiAgbnVsbCAtLS1YIChhdHRlbXB0IDMsIG5vdGlmaWNh dGlvbiAzIGlzIHRvbyBvbGQgdG8gYmUgcmVwb3J0ZWQpDQogICBOb3RpZmljYXRpb24gIG51bGwg LS0tPiAoYXR0ZW1wdCA0KQ0KICAgLi4uLg0KICAgTm90aWZpY2F0aW9uICA0IC0tLVggICAoYXR0 ZW1wdCAwKQ0KICAgTm90aWZpY2F0aW9uICA0IC0tLVggICAoYXR0ZW1wdCAxKQ0KICAgTm90aWZp Y2F0aW9uICA1IC0tLT4gICAoYXR0ZW1wdCAyKQ0KICAgLi4uLg0KICAgTm90aWZpY2F0aW9uICA2 IC0tLT4NCiAgIC4uLi4NCg0KSXMgaXQgYW4gYWNjZXB0YWJsZSBzb2x1dGlvbj8NCkFueSBvdGhl ciBzb2x1dGlvbiB0byBwcm9wb3NlPw0KDQpSZWdhcmRzLA0KTWljaGVsOzsNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2xhdXMgSGFydGtlIFttYWlsdG86aGFydGtlQHR6 aS5vcmddIA0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAxNiwgMjAxNiA1OjQwIFBNDQpUbzogTWlj aGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPg0KQ2M6IENv cmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENvTUkgLSBsb25nIHRlcm0g cmVsYXRpb25zaGlwIGJldHdlZW4gbmV0d29yayBlbGVtZW50cyBhbmQgbWFuYWdlbWVudCBzdGF0 aW9uDQoNCk1pY2hlbCBWZWlsbGV0dGUgd3JvdGU6DQo+IEFib3V0ICJUaGVuIGNoYW5nZSBpdCBv bmx5IGZvciBub3RpZmljYXRpb25zPyINCj4NCj4gVGhlIENvQVAgaW1wbGVtZW50YXRpb25zIEkn bSBjdXJyZW50bHkgdXNpbmcgZG9u4oCZdCBhbGxvdyB0aGUgdXNlIG9mIG11bHRpcGxlIHNldCBv ZiByZS10cmFuc21pc3Npb24gcGFyYW1ldGVycywgdGhvc2UgYXJlIGdsb2JhbC4NCj4gQXJlIHlv dSBhd2FyZSBvZiBhbnkgQ29BUCBpbXBsZW1lbnRhdGlvbnMgY2FwYWJsZSBvZiBzdXBwb3J0aW5n IHRoaXMgYXBwcm9hY2g/DQoNCkEgQ29BUCBpbXBsZW1lbnRhdGlvbiBtYWludGFpbnMgYSB0aW1l b3V0IGFuZCBhIHJldHJhbnNtaXNzaW9uIGNvdW50ZXIgZm9yIGVhY2ggYWN0aXZlIGNvbmZpcm1h YmxlIG1lc3NhZ2UuIEl0IHNob3VsZG4ndCBiZSB0b28gZGlmZmljdWx0IHRvIHBhc3MgdGhlIGlu aXRpYWwgdmFsdWVzIGFzIHBhcmFtZXRlcnMgKGFwcHJveGltYXRlbHkgYXJvdW5kIHRoZSBsaW5l IG9mIGNvZGUgdGhhdCBkZXRlcm1pbmVzIGlmIHRoZSBtZXNzYWdlIGlzIGNvbmZpcm1hYmxlIG9y DQpub24tY29uZmlybWFibGUpIGluc3RlYWQgb2YgdXNpbmcgdGhlIGRlZmF1bHQgdmFsdWVzLiBJ J3ZlIGp1c3QgbWFkZSB0aGlzIGNoYW5nZSB0byBteSAodW5wdWJsaXNoZWQpIGltcGxlbWVudGF0 aW9uIGFuZCBpdCB0b29rIG1lIGFib3V0IDIwIHNlY29uZHMuDQoNCj4gQWJvdXQgdGhlIGxhc3Qg c2NlbmFyaW8sIGlzIGl0IHJlYWxseSBhbGxvd2VkIGJ5IFJGQzcyNTIgdG8gY2hhbmdlIHRoZSBj b250ZW50IG9mIGEgQ29BUCBtZXNzYWdlIGR1cmluZyB0aGUgcmV0cmFuc21pc3Npb24gcHJvY2Vz cyAoQmV0d2VlbiBhdHRlbXB0IDIgYW5kIDMgaW4geW91ciBleGFtcGxlKT8gSW4gdGhlIHNwZWNp ZmljYXRpb24sIGl0IGlzIGNsZWFyIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gY2FuIGFuc3dlciB0 byBhIGR1cGxpY2F0ZSByZXF1ZXN0IHVzaW5nIGFuIHVwZGF0ZWQgY29udGVudCAoc2VjdGlvbiA0 LjUpIGJ1dCBmb3IgdGhlIHJldHJpZXMsIHRoZSBzcGVjIGFsd2F5cyByZWZlciB0byBhIHJlLXRy YW5zbWlzc2lvbi4NCg0KVGhhdCdzIHdoYXQgU2VjdGlvbiA0LjUuMiBvZiBSRkMgNzY0MSBbMV0g aXMgYWJvdXQuIFRoZSB0cmFuc21pc3Npb24gb2YgdGhlIG9sZGVyIG5vdGlmaWNhdGlvbiBpcyBh Ym9ydGVkIGFuZCBhIG5ldyB0cmFuc21pc3Npb24gaXMgc3RhcnRlZCB3aXRoIHRoZSB0aW1lb3V0 IGFuZCB0aGUgcmV0cmFuc21pc3Npb24gY291bnRlciBvZiB0aGUgYWJvcnRlZCB0cmFuc21pc3Np b24uDQoNCktsYXVzDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY0MSNz ZWN0aW9uLTQuNS4yDQo= From nobody Mon Dec 19 08:40:51 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A983D129BC3; Mon, 19 Dec 2016 08:40:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148216565068.12830.9703812853265686153.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 08:40:50 -0800 Archived-At: Cc: core-chairs@ietf.org, draft-ietf-core-http-mapping@ietf.org, The IESG , core@ietf.org, rfc-editor@rfc-editor.org Subject: [core] Protocol Action: 'Guidelines for HTTP-to-CoAP Mapping Implementations' to Proposed Standard (draft-ietf-core-http-mapping-17.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 16:40:51 -0000 The IESG has approved the following document: - 'Guidelines for HTTP-to-CoAP Mapping Implementations' (draft-ietf-core-http-mapping-17.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ Technical Summary This document provides reference information for implementing a cross- protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. Working Group Summary The working group has very good consensus on this document as it is. HTTP mapping aspects raised by future CoAP extensions will then be addressed by these extensions or in separate documents. Document Quality There are multiple implementations of the mapping specified in this document. See the shepherding write-up. Media Type review was requested. See . Personnel Jaime Jiménez is the Document Shepherd. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 8.5 (change section 6.2.4 of [RFC7230] to section 6.5): OLD: If the CoAP server takes a long time in responding, the HTTP client or any other proxy in between may timeout. Further discussion of timeouts in HTTP is available in Section 6.2.4 of [RFC7230]. NEW: If the CoAP server takes a long time in responding, the HTTP client or any other proxy in between may timeout. Further discussion of timeouts in HTTP is available in Section 6.5 of [RFC7230]. From nobody Mon Dec 19 09:30:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A224A129C26 for ; Mon, 19 Dec 2016 09:30:26 -0800 (PST) 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 4z2b2mX0hEZW for ; Mon, 19 Dec 2016 09:30:24 -0800 (PST) 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 5037A129C28 for ; Mon, 19 Dec 2016 09:30:24 -0800 (PST) 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 uBJHULPK028997 for ; Mon, 19 Dec 2016 18:30:21 +0100 (CET) Received: from mail-wj0-f173.google.com (mail-wj0-f173.google.com [209.85.210.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tj7Gh74bmz8Mfb for ; Mon, 19 Dec 2016 18:30:20 +0100 (CET) Received: by mail-wj0-f173.google.com with SMTP id tg4so156852315wjb.1 for ; Mon, 19 Dec 2016 09:30:20 -0800 (PST) X-Gm-Message-State: AIkVDXLQpeEsXVgNXoX82jfSwZPckixnmjC6WjFuSLZAf+qVvpqL80YVDfpy83N2btiGvlCy9XF3eMl48O3qwA== X-Received: by 10.194.21.201 with SMTP id x9mr13960879wje.153.1482168620674; Mon, 19 Dec 2016 09:30:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.108.227 with HTTP; Mon, 19 Dec 2016 09:29:40 -0800 (PST) In-Reply-To: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> From: Klaus Hartke Date: Mon, 19 Dec 2016 18:29:40 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 17:30:26 -0000 Michel Veillette wrote: > The proposed approach archive effectively the necessary resilience of the observe mechanism. The only drawback is the requirement to retry for a long period a specific notification, which might be an issue when this notification is not timestamp. A notification contains only the first block of the resource representation. A client has to retrieve any further blocks using normal GET requests. If I understand Section 2.6 of RFC 7959 [1] correctly, it should be possible that a server sends, for example, a notification with a block size of 256 bytes for a recent state change and a notification with a block size of 16 bytes (the minimum block size) if the state change happened longer ago. Would that solve your problem? Klaus [1] https://tools.ietf.org/html/rfc7959#section-2.6 From nobody Mon Dec 19 09:44:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DB312945E for ; Mon, 19 Dec 2016 09:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUxhM2fu40Ir for ; Mon, 19 Dec 2016 09:44:24 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0106.outbound.protection.outlook.com [104.47.34.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8C5124281 for ; Mon, 19 Dec 2016 09:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ki7R4JTGyFVM8ED/jDNbGIB/8K3YZDen8mB7krib+Hc=; b=qBraYekcs2JJwkhGIGlMhcCQmN6qJTcQLFYwCJ3GOEIMXlVHGqyUrqzAxs9/MhjHUHI1ZA9GK4vkTBymIwhN6J0gPiP8CVLF8hRZgovUR9VrBnafTWwJkiIblXCt/uFTg9Q2hi0GfEHZ5+7GUHPUroYmLd+aE4iTDeuj2iWaVUI= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 17:44:23 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 17:44:22 +0000 From: Michel Veillette To: Klaus Hartke Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AdJW9xqVAs1+aI21QYaXpt5SS1MyhAAeYc+AABHhG3AACCaLAAAAuNQgAAIK+gAAADfnEAACLK+AAIe/JsAABEbwAAAAMV8g Date: Mon, 19 Dec 2016 17:44:22 +0000 Message-ID: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: f71c42b6-08e3-4a17-e727-08d42836ab05 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2307; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 7:iA3xYZi7UAFRh+4pUJs9kHMO9lkO7Zkt+551X3HVxpta414Cv/c9cXHC/5oYdqNGFIScOse5L3ofrFDc8xTOuUVzJNMEn/wqCb9XnSF2j3NUjade9hmGMv1YLb1M8CyNbmCv0YvScgrRjYVbACO89MxoVONCLkt5sSWAEQxODG+GhKg6Nqtk1OgNsMarwwEqJGWdi41xCMtIKFqCqhbGjuemZSQegAnC6HzkzzVlEdQHC8OdliXuq/s4LrN3iIkBjItQfULqIRYkI58JgRGF3ZdLQy8MlgdknLwmBUru85XKzg4crlkx+fgU+GdDaRHKMK/W3557n7ccWrtSVYe1ubfAP0bdm5iuBNJtcYkDu5hpxsW/6AXGWmLNah+nJiJChedatw35FaHnKz09OsylmT0LTINcejvhki6oBh9RrjReRyHuatS62PFNOc4+T9eOLS6GqgA+krCjveJz/oTpPQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39830400002)(39450400003)(43784003)(24454002)(189002)(377454003)(13464003)(199003)(101416001)(6116002)(3846002)(92566002)(66066001)(76176999)(54356999)(50986999)(5660300001)(33656002)(93886004)(2906002)(106356001)(105586002)(229853002)(76576001)(68736007)(9686002)(99286002)(97736004)(38730400001)(8676002)(77096006)(6506006)(102836003)(2900100001)(8936002)(4326007)(86362001)(25786008)(7696004)(110136003)(3280700002)(7736002)(6916009)(189998001)(2950100002)(122556002)(305945005)(3660700001)(6436002)(81156014)(74316002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 17:44:22.6986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 17:44:30 -0000 SGkgS2xhdXMNCg0KSWYgdGhpcyBzaG9ydCBibG9jayBzaXplIGlzIGludGVycHJldGVkIGFzIGEg ZGlmZmVyZWQgbm90aWZpY2F0aW9uLCBJIGFzc3VtZSB0aGlzIGNhbiB3b3JrLiBQZXJzb25hbGx5 LCBJIHByZWZlciB0aGUgY3JlYXRpb24gb2YgYSBub3RpZmljYXRpb24gaW4gdGhlIENvTUkgZXZl bnQgc3RyZWFtIGFmdGVyIGEgc3BlY2lmaWMgbnVtYmVyIG9mIHJldHJpZXMgY2FsbGVkIGxldCBz YXkgIkNvbW11bmljYXRpb24gbG9zcyIuIFRoaXMgbm90aWZpY2F0aW9uIGhhcyBhIGRvdWJsZSBw dXJwb3NlLCB0byBraWxsIHRoZSBjdXJyZW50IG5vdGlmaWNhdGlvbiB3aGljaCBpcyBub3cgb2Jz b2xldGUgYW5kIHRvIG5vdGlmeSB0aGUgY2xpZW50IG9mIG1pc3Npbmcgbm90aWZpY2F0aW9uKHMp Lg0KDQpUaGFua3MgYWdhaW4gZm9yIHlvdSBoZWxwLg0KDQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEtsYXVzIEhhcnRrZSBbbWFpbHRvOmhhcnRrZUB0emkub3Jn XSANClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTksIDIwMTYgMTI6MzAgUE0NClRvOiBNaWNoZWwg VmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+DQpDYzogQ29yZSA8 Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gQ29NSSAtIGxvbmcgdGVybSByZWxh dGlvbnNoaXAgYmV0d2VlbiBuZXR3b3JrIGVsZW1lbnRzIGFuZCBtYW5hZ2VtZW50IHN0YXRpb24N Cg0KTWljaGVsIFZlaWxsZXR0ZSB3cm90ZToNCj4gVGhlIHByb3Bvc2VkIGFwcHJvYWNoIGFyY2hp dmUgZWZmZWN0aXZlbHkgdGhlIG5lY2Vzc2FyeSByZXNpbGllbmNlIG9mIHRoZSBvYnNlcnZlIG1l Y2hhbmlzbS4gVGhlIG9ubHkgZHJhd2JhY2sgaXMgdGhlIHJlcXVpcmVtZW50IHRvIHJldHJ5IGZv ciBhIGxvbmcgcGVyaW9kIGEgc3BlY2lmaWMgbm90aWZpY2F0aW9uLCB3aGljaCBtaWdodCBiZSBh biBpc3N1ZSB3aGVuIHRoaXMgbm90aWZpY2F0aW9uIGlzIG5vdCB0aW1lc3RhbXAuDQoNCkEgbm90 aWZpY2F0aW9uIGNvbnRhaW5zIG9ubHkgdGhlIGZpcnN0IGJsb2NrIG9mIHRoZSByZXNvdXJjZSBy ZXByZXNlbnRhdGlvbi4gQSBjbGllbnQgaGFzIHRvIHJldHJpZXZlIGFueSBmdXJ0aGVyIGJsb2Nr cyB1c2luZyBub3JtYWwgR0VUIHJlcXVlc3RzLiBJZiBJIHVuZGVyc3RhbmQgU2VjdGlvbiAyLjYg b2YgUkZDIDc5NTkgWzFdIGNvcnJlY3RseSwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRoYXQgYSBz ZXJ2ZXIgc2VuZHMsIGZvciBleGFtcGxlLCBhIG5vdGlmaWNhdGlvbiB3aXRoIGEgYmxvY2sgc2l6 ZSBvZiAyNTYgYnl0ZXMgZm9yIGEgcmVjZW50IHN0YXRlIGNoYW5nZSBhbmQgYSBub3RpZmljYXRp b24gd2l0aCBhIGJsb2NrIHNpemUgb2YgMTYgYnl0ZXMgKHRoZSBtaW5pbXVtIGJsb2NrDQpzaXpl KSBpZiB0aGUgc3RhdGUgY2hhbmdlIGhhcHBlbmVkIGxvbmdlciBhZ28uDQoNCldvdWxkIHRoYXQg c29sdmUgeW91ciBwcm9ibGVtPw0KDQpLbGF1cw0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzc5NTkjc2VjdGlvbi0yLjYNCg== From nobody Mon Dec 19 10:13:14 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E1C129593 for ; Mon, 19 Dec 2016 10:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] 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 qyzxifz2wnAU for ; Mon, 19 Dec 2016 10:13:11 -0800 (PST) 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 8A68C12948F for ; Mon, 19 Dec 2016 10:13:11 -0800 (PST) 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 uBJID817004582 for ; Mon, 19 Dec 2016 19:13:08 +0100 (CET) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tj8D40GS9z8Mgw for ; Mon, 19 Dec 2016 19:13:08 +0100 (CET) Received: by mail-wm0-f50.google.com with SMTP id t79so108543431wmt.0 for ; Mon, 19 Dec 2016 10:13:08 -0800 (PST) X-Gm-Message-State: AIkVDXIrijPa5rfCTf6YwD/N+C8NhmwgpcPGsd6OBfHbRv1SCpijGeQJZ6m35Igz73Lj5lWEp8cZafaPWCnycQ== X-Received: by 10.28.45.142 with SMTP id t136mr16515219wmt.110.1482171187710; Mon, 19 Dec 2016 10:13:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.16.38 with HTTP; Mon, 19 Dec 2016 10:12:26 -0800 (PST) In-Reply-To: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> From: Klaus Hartke Date: Mon, 19 Dec 2016 19:12:26 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:13:13 -0000 Michel Veillette wrote: > If this short block size is interpreted as a differed notification, I ass= ume this can work. Personally, I prefer the creation of a notification in t= he CoMI event stream after a specific number of retries called let say "Com= munication loss". This notification has a double purpose, to kill the curre= nt notification which is now obsolete and to notify the client of missing n= otification(s). It is a non-goal of Observe to inform a client of every resource state change that happens or to inform a client of missed resource state changes. Observe really just tries to keep the client updated about the latest and only the latest resource state at the server. A notification cannot really be obsolete, because if a state change happened, the client should know about it -- unless there is a new state change. Because Observe focuses only on the latest resource state, if a server knows that the resource state will change soon (for any reasonable definition of "soon"), it does not have to try too hard to update the client about the soon-obsolete resource state. So I think you should be able to achieve your goals by adjusting (a) the number of retransmission attempts, (b) the time between retransmission attempts, (c) the block size of notifications, and (d) the definition of "soon". Hope this helps, Klaus From nobody Mon Dec 19 10:33:13 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AD012959C for ; Mon, 19 Dec 2016 10:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QP4JCMhVLrPc for ; Mon, 19 Dec 2016 10:33:09 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10132.outbound.protection.outlook.com [40.107.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EC81295A6 for ; Mon, 19 Dec 2016 10:33:09 -0800 (PST) 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=UnKqr5YODjmoHh8lp0MIanLFvtKHNufuA4YOABjClSI=; b=gOnCTzZazXXrln+dD0TT4ZV9YBy909ix0X3c+QqQUVDZ8s8i2O1G3jFBGGGifulbYh8/SJ+pflO2FkpSvfa2G5Z0gyPgWqLfZC27RByWrKeUIf+SMUz04bXHEr6wpUs2MLrDtNo4KO6Z+f4Gaw5T1tuFtsb2gGuH7kEVCZi5vMo= Received: from HE1PR01MB1546.eurprd01.prod.exchangelabs.com (10.164.30.156) by HE1PR01MB1545.eurprd01.prod.exchangelabs.com (10.164.30.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 18:33:06 +0000 Received: from HE1PR01MB1546.eurprd01.prod.exchangelabs.com ([10.164.30.156]) by HE1PR01MB1546.eurprd01.prod.exchangelabs.com ([10.164.30.156]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 18:33:06 +0000 From: "Turner, Randy" To: Klaus Hartke Thread-Topic: [core] CoMI - long term relationship between network elements and management station Thread-Index: AQHSV766kgdguACGAkGd7nh52WYacKELAgMAgAAOCICAAAgWAIAAB9UAgAALUICABEdDgIAAGO4AgAAEGwCAAAfYAIAABcWA Date: Mon, 19 Dec 2016 18:33:05 +0000 Message-ID: <2B199486-E8BA-47B8-8332-5677C5F46BE5@landisgyr.com> References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> In-Reply-To: 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-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:cb:c000:8248:c5b2:9818:5d15:4baf] x-ms-office365-filtering-correlation-id: a99ec152-8c16-4041-643e-08d4283d7981 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR01MB1545; x-microsoft-exchange-diagnostics: 1; HE1PR01MB1545; 7:A9w3gA8suknZD/xOp6zD8k9FXyqfY1XUIbVa+0jaudARFZYAfgvMCXoWCLwMzWLGFcTUcvmr/NJOlO9tXZQTUZdokLhfJ6t5DmoIxEjMCu7ttGG6+khPJr9Ql/nviDU77uXDbJr7GU2fNVZpZ6TCIHAMPRtUHhcKPJDyOsyEdUfHhQfgUvJYHhyzGfDituHQGHlGme6Vjjhsvia4ZZx5Vj941pzwIKUWReCjFKV0uWZypiqP0HYReScgN7bLWfnzcEX4hbyEBVtJDIDoK5OAd/Uh0IicNT4oceHVJImwFYyhWxjZhzThAylLadn07u6k7Z+2FIiOCnjnelnVd24QRgnaSYSnNkTu5a5k0o3N/uMGB3A5rIrXTxnWcD7Mass5JJW38mz/3ewFA6pKLwFzQdyL2keMYa7lM7qidm//7dS4JqNdTKsmkdmIfJaehdArApJavboEV8QWvwmkJedUXQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:HE1PR01MB1545; BCL:0; PCL:0; RULEID:; SRVR:HE1PR01MB1545; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(24454002)(189002)(199003)(129404003)(377454003)(6486002)(6916009)(2950100002)(106116001)(86362001)(105586002)(92566002)(2900100001)(93886004)(76176999)(54356999)(106356001)(50986999)(33656002)(101416001)(36756003)(189998001)(110136003)(97736004)(8936002)(102836003)(6506006)(6116002)(6512006)(77096006)(122556002)(4326007)(5660300001)(2906002)(68736007)(25786008)(81156014)(81166006)(8676002)(82746002)(6436002)(3280700002)(7736002)(3660700001)(305945005)(229853002)(38730400001)(83716003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR01MB1545; H:HE1PR01MB1546.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <16611C1710B0DD49981971EEB92EBE2C@eurprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 18:33:05.9599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR01MB1545 Archived-At: Cc: "core@ietf. org WG" Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:33:11 -0000 SGkgS2xhdXMsIEkgdGhvdWdodCB0aGUgd2hvbGUgcHVycG9zZSBvZiBvYnNlcnZlIHdhcyB0byBr ZWVwIGludGVyZXN0ZWQgY2xpZW50cyB1cGRhdGVkIGFzIHRvIHRoZSBzdGF0ZSBvZiBhIHJlc291 cmNlIC0gZXZlcnkgdGltZSB0aGUgc3RhdGUgY2hhbmdlcywgSSBnZXQgbm90aWZpZWQg4oCUIHRo aXMgc2VlbXMgdG8gYmUgaW4gY29uZmxpY3Qgd2l0aCB0aGUgZmlyc3QNCnNlbnRlbmNlIG9mIHlv dXIgZW1haWwgYmVsb3cg4oCUIEkgdW5kZXJzdGFuZCBhYm91dCBub3QgaW5mb3JtaW5nIGNsaWVu dHMgb2YgcG90ZW50aWFsIG1pc3NlZCBzdGF0ZSBpbiB0aGUgcGFzdCwgYnV0IGZyb20gdGltZSB0 KG4pLCBJIHRob3VnaHQgdGhlIHdob2xlIHBvaW50IHdhcyB0byBnZXQgbm90aWZpZWQgb2YgZWFj aCBzdGF0ZSBjaGFuZ2UgdChuKyspIC0gd2hpY2ggYXMgSSBzYWlkDQpjb25mbGljdHMgd2l0aCB0 aGUgZmlyc3QgcGFydCBvZiB5b3VyIGZpcnN0IHNlbnRlbmNlIGJlbG93Lg0KDQpSYW5keQ0KDQoN Cj4gT24gRGVjIDE5LCAyMDE2LCBhdCAxOjEyIFBNLCBLbGF1cyBIYXJ0a2UgPGhhcnRrZUB0emku b3JnPiB3cm90ZToNCj4gDQo+IE1pY2hlbCBWZWlsbGV0dGUgd3JvdGU6DQo+PiBJZiB0aGlzIHNo b3J0IGJsb2NrIHNpemUgaXMgaW50ZXJwcmV0ZWQgYXMgYSBkaWZmZXJlZCBub3RpZmljYXRpb24s IEkgYXNzdW1lIHRoaXMgY2FuIHdvcmsuIFBlcnNvbmFsbHksIEkgcHJlZmVyIHRoZSBjcmVhdGlv biBvZiBhIG5vdGlmaWNhdGlvbiBpbiB0aGUgQ29NSSBldmVudCBzdHJlYW0gYWZ0ZXIgYSBzcGVj aWZpYyBudW1iZXIgb2YgcmV0cmllcyBjYWxsZWQgbGV0IHNheSAiQ29tbXVuaWNhdGlvbiBsb3Nz Ii4gVGhpcyBub3RpZmljYXRpb24gaGFzIGEgZG91YmxlIHB1cnBvc2UsIHRvIGtpbGwgdGhlIGN1 cnJlbnQgbm90aWZpY2F0aW9uIHdoaWNoIGlzIG5vdyBvYnNvbGV0ZSBhbmQgdG8gbm90aWZ5IHRo ZSBjbGllbnQgb2YgbWlzc2luZyBub3RpZmljYXRpb24ocykuDQo+IA0KPiBJdCBpcyBhIG5vbi1n b2FsIG9mIE9ic2VydmUgdG8gaW5mb3JtIGEgY2xpZW50IG9mIGV2ZXJ5IHJlc291cmNlIHN0YXRl DQo+IGNoYW5nZSB0aGF0IGhhcHBlbnMgb3IgdG8gaW5mb3JtIGEgY2xpZW50IG9mIG1pc3NlZCBy ZXNvdXJjZSBzdGF0ZQ0KPiBjaGFuZ2VzLiBPYnNlcnZlIHJlYWxseSBqdXN0IHRyaWVzIHRvIGtl ZXAgdGhlIGNsaWVudCB1cGRhdGVkIGFib3V0DQo+IHRoZSBsYXRlc3QgYW5kIG9ubHkgdGhlIGxh dGVzdCByZXNvdXJjZSBzdGF0ZSBhdCB0aGUgc2VydmVyLiBBDQo+IG5vdGlmaWNhdGlvbiBjYW5u b3QgcmVhbGx5IGJlIG9ic29sZXRlLCBiZWNhdXNlIGlmIGEgc3RhdGUgY2hhbmdlDQo+IGhhcHBl bmVkLCB0aGUgY2xpZW50IHNob3VsZCBrbm93IGFib3V0IGl0IC0tIHVubGVzcyB0aGVyZSBpcyBh IG5ldw0KPiBzdGF0ZSBjaGFuZ2UuIEJlY2F1c2UgT2JzZXJ2ZSBmb2N1c2VzIG9ubHkgb24gdGhl IGxhdGVzdCByZXNvdXJjZQ0KPiBzdGF0ZSwgaWYgYSBzZXJ2ZXIga25vd3MgdGhhdCB0aGUgcmVz b3VyY2Ugc3RhdGUgd2lsbCBjaGFuZ2Ugc29vbiAoZm9yDQo+IGFueSByZWFzb25hYmxlIGRlZmlu aXRpb24gb2YgInNvb24iKSwgaXQgZG9lcyBub3QgaGF2ZSB0byB0cnkgdG9vIGhhcmQNCj4gdG8g dXBkYXRlIHRoZSBjbGllbnQgYWJvdXQgdGhlIHNvb24tb2Jzb2xldGUgcmVzb3VyY2Ugc3RhdGUu DQo+IA0KPiBTbyBJIHRoaW5rIHlvdSBzaG91bGQgYmUgYWJsZSB0byBhY2hpZXZlIHlvdXIgZ29h bHMgYnkgYWRqdXN0aW5nDQo+IA0KPiAoYSkgdGhlIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbiBh dHRlbXB0cywNCj4gKGIpIHRoZSB0aW1lIGJldHdlZW4gcmV0cmFuc21pc3Npb24gYXR0ZW1wdHMs DQo+IChjKSB0aGUgYmxvY2sgc2l6ZSBvZiBub3RpZmljYXRpb25zLCBhbmQNCj4gKGQpIHRoZSBk ZWZpbml0aW9uIG9mICJzb29uIi4NCj4gDQo+IEhvcGUgdGhpcyBoZWxwcywNCj4gS2xhdXMNCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNv cmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Mon Dec 19 11:37:00 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35331295F2 for ; Mon, 19 Dec 2016 11:36:58 -0800 (PST) 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 efEwgxj8jIb5 for ; Mon, 19 Dec 2016 11:36:56 -0800 (PST) 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 CB8661295C4 for ; Mon, 19 Dec 2016 11:36:55 -0800 (PST) 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 uBJJaq89011866 for ; Mon, 19 Dec 2016 20:36:52 +0100 (CET) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tjB4g6YL1z8Mj9 for ; Mon, 19 Dec 2016 20:36:51 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id g23so102445400wme.1 for ; Mon, 19 Dec 2016 11:36:51 -0800 (PST) X-Gm-Message-State: AIkVDXLSPl+tkXSEGmKqoDeOfthG8Ud6ahQZ6yNQWZnwQl30WuRaU3mSb35JGgLKbarJBwfRFfGNFDRAxhzL+w== X-Received: by 10.28.52.201 with SMTP id b192mr14405832wma.118.1482176211626; Mon, 19 Dec 2016 11:36:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.108.227 with HTTP; Mon, 19 Dec 2016 11:36:10 -0800 (PST) In-Reply-To: <2B199486-E8BA-47B8-8332-5677C5F46BE5@landisgyr.com> References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> <2B199486-E8BA-47B8-8332-5677C5F46BE5@landisgyr.com> From: Klaus Hartke Date: Mon, 19 Dec 2016 20:36:10 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Turner, Randy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core@ietf. org WG" Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 19:36:59 -0000 Randy Turner wrote: > Hi Klaus, I thought the whole purpose of observe was to keep interested c= lients updated as to the state of a resource - every time the state changes= , I get notified =E2=80=94 this seems to be in conflict with the first > sentence of your email below =E2=80=94 I understand about not informing c= lients of potential missed state in the past, but from time t(n), I thought= the whole point was to get notified of each state change t(n++) - which as= I said > conflicts with the first part of your first sentence below. In a perfect world of zero latency and infinite bandwidth it would be possible for every client to observe every state change that a resource at a server goes through. However, in a world of low-power, lossy networks and nodes with various levels of constraintness, it is not unlikely that a resource state occasionally (or often!) changes faster than all clients can reliably be notified. You can deal with this problem in two ways: either you slow down the rate of state changes, or you do not notify every client of every state change [1]. Observe opts for the latter and chooses a notification strategy that tries to keep observers updated only about the *latest* resource state. This solves a lot of problems (no storage needed to buffer a queue of notifications; slow observers don't slow down the whole system) and works for many - but not all - applications. Klaus [1] http://ferd.ca/queues-don-t-fix-overload.html From nobody Mon Dec 19 17:24:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A9129C4B; Mon, 19 Dec 2016 17:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 4NTJrNt7dYJS; Mon, 19 Dec 2016 17:24:29 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0092.outbound.protection.outlook.com [104.47.41.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706D3129C3A; Mon, 19 Dec 2016 17:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nSvJyQKpXHD+HQZEB7zkhcbD5t4ldZvRDc/tx5Lb5Lg=; b=c+PFsooPNLUw0Xxp0Mio7jSfrSMgA/OyYeajv5V/FOciTO24UQ/tt9ojX48z/6702Dz4Y33DgLSfQq4NeAWRK18HEhO8Sz39N81I+7y+zTGRYvZwJ182A4+akIB9EeshE2wk5X3dCucscxf2vNfrcDixA8FhNCLQAUJ38aD0x40= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2379.namprd03.prod.outlook.com (10.166.207.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Tue, 20 Dec 2016 01:24:24 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0771.020; Tue, 20 Dec 2016 01:24:24 +0000 From: Brian Raymor To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: =?utf-8?B?UmU6IFtjb3JlXSDwn5SUIFdHTEMgb24gZHJhZnQtaWV0Zi1jb3JlLWNvYXAt?= =?utf-8?Q?tcp-tls?= Thread-Index: AdI/n3PZGgzFmnHpQTG+f+M+6OrYhg== Date: Tue, 20 Dec 2016 01:24:24 +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=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: c358d020-00b7-415c-90c0-08d42876eeb7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB2379; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2379; 7:98gOjZxWZ8Lwh9sre1H2PuSTxdw3CkyVTSxVu71jztau0yq/CsQPFdvh7EjX5N6FzwRVMoR5c1auD6yNO/7Mg/4Sbhe9B57o57kEKNq9Q7oHgtzBXKVssU9Txte4+P8w4HnKk7fg1wGPdwNGJieGkV1gLBoWgc8rPbVhy+9AkVmtKiMoFGkuzOFVULMYWaucPKssS+xI9Btjgd5T+ZUp3KhjONtmOnmotZjC0+pp0wqQxUolsIgJJoGl2GQ/zfBQSHRJSs/j73n/di+5/xkyuF4xCWEQ1XeZQXRGiwO/G7whHfbgR8y/0A4tm5J7fERXVKCQF2GGLf32YvuuRZOmvoKXe2adhxCadjQ0b4cvCpGHXCzWbiRBqlJFroQx7ZHPzb8vIVAI21/HxQ3TRt0lGWcN6O3fx0yZh4q7kyy5RMvtJbYwvl49Ni/cFzbEMbEFDu4va2WhHFIpxkQaNBDvYP+mXBlJHDcmCfjs9vAXBgA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6047074)(6072148); SRVR:CY1PR03MB2379; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2379; x-forefront-prvs: 0162ACCC24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39450400003)(39860400002)(39840400002)(39410400002)(51914003)(199003)(189002)(99286002)(3280700002)(97736004)(5001770100001)(25786008)(68736007)(189998001)(38730400001)(10090500001)(66066001)(76576001)(92566002)(5660300001)(33656002)(2906002)(229853002)(15395725005)(77096006)(6506006)(122556002)(86362001)(86612001)(3846002)(54356999)(81156014)(81166006)(4326007)(9686002)(74316002)(606005)(3660700001)(7696004)(50986999)(7906003)(6436002)(8990500004)(230783001)(5005710100001)(10290500002)(8936002)(7736002)(105586002)(229383001)(106356001)(790700001)(102836003)(101416001)(6116002)(2900100001)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2379; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2380868D3621B914EB751D5283900CY1PR03MB2380namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2016 01:24:24.0260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2379 Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-tcp-tl?= =?utf-8?q?s?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 01:24:33 -0000 --_000_CY1PR03MB2380868D3621B914EB751D5283900CY1PR03MB2380namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLCBDYXJzdGVuLg0KDQoNCg0KPiAgICAgICAgIDEu ICBJbnRyb2R1Y3Rpb24NCg0KPiAgICAgICAgICAgIFsuLi5dIEFsdGhvdWdoIEhUVFAvMg0KDQo+ ICAgICAgICAgICAgY291bGQgYWxzbyBwb3RlbnRpYWxseSBhZGRyZXNzIHRoZXNlIHJlcXVpcmVt ZW50cywgdGhlcmUgd291bGQgYmUNCg0KPiAgICAgICAgICAgIGFkZGl0aW9uYWwgY29zdHMgYW5k IGRlbGF5cyBpbnRyb2R1Y2VkIGJ5IHN1Y2ggYSB0cmFuc2l0aW9uLg0KDQo+ICAgICAgICAgICAg Q3VycmVudGx5LCB0aGVyZSBhcmUgYWxzbyBmZXdlciBIVFRQLzIgaW1wbGVtZW50YXRpb25zIGF2 YWlsYWJsZSBmb3INCg0KPiAgICAgICAgICAgIGNvbnN0cmFpbmVkIGRldmljZXMgaW4gY29tcGFy aXNvbiB0byBDb0FQLg0KDQoNCg0KPiBUaGVzZSBzZW50ZW5jZXMgYXJlIGxhbWU7IEkgc3RpbGwg ZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhleSBhcmUgbmVlZGVkLg0KDQo+IFRoZSBtYWluIHBvaW50 IGhlcmUgaXMgdGhhdCBIVFRQLzIgaXMgYSBjb21wbGV4aXR5IGZlc3QgY29tcGFyZWQgdG8gQ29B UC4NCg0KPiBBbHNvLCBIVFRQLzIgaGFzIG5vdCB5ZXQgYmVlbiBleHRlbmRlZCBieSBpbXBvcnRh bnQgY29uY2VwdHMgc3VjaCBhcw0KDQo+IE9ic2VydmUuDQoNCg0KDQpUaGUgY29udGV4dCBpcyBp biBpbiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzUwLg0K DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgRGF2ZSBUaGFsZXIgYW5kIHlvdSByZXZpZXdlZCBk dXJpbmcgSUVURiA5Ny4NCg0KSSBoYXZlIG5vIHBsYW5zIHRvIHJlLW9wZW4gYXQgdGhpcyB0aW1l Lg0KDQoNCg0KPiAgICAgICAgICAgIFsuLi5dDQoNCj4gICAgICAgICAgIEluIGFkZGl0aW9uLCBz b21lIGNvcnBvcmF0ZSBuZXR3b3JrcyBvbmx5IGFsbG93IEludGVybmV0IGFjY2VzcyB2aWEgYQ0K DQo+ICAgICAgICAgICBIVFRQIHByb3h5LiAgSW4gdGhpcyBjYXNlLCB0aGUgYmVzdCB0cmFuc3Bv cnQgZm9yIENvQVAgd291bGQgYmUgdGhlDQoNCj4gICAgICAgICAgIFdlYlNvY2tldCBQcm90b2Nv bCBbUkZDNjQ1NV0uICBUaGUgV2ViU29ja2V0IHByb3RvY29sIHByb3ZpZGVzIHR3by0NCg0KDQoN Cj4gV2VsbCwgYW4gSFRUUCBwcm94eSB3b24ndCBuZWNlc3NhcmlseSBhbGxvdyBXZWJTb2NrZXRz IHRocm91Z2guDQoNCg0KDQpEbyB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24/IFBlcmhhcHMg4oCcbWln aHQgYmXigJ0gcmF0aGVyIHRoYW4g4oCcd291bGQgYmXigJ0/DQoNCg0KDQo+ICAgICAgICAxLjEu ICBUZXJtaW5vbG9neQ0KDQo+DQoNCj4gICAgICAgICAgIFsuLi5dDQoNCj4gICAgICAgICAgVGhp cyBkb2N1bWVudCBhc3N1bWVzIHRoYXQgcmVhZGVycyBhcmUgZmFtaWxpYXIgd2l0aCB0aGUgdGVy bXMgYW5kDQoNCj4gICAgICAgICAgIGNvbmNlcHRzIHRoYXQgYXJlIHVzZWQgaW4gW1JGQzY0NTVd LCBbUkZDNzI1Ml0sIGFuZCBbUkZDNzY0MV0uDQoNCg0KDQo+IGFuZCBSRkMgNzk1OS4NCg0KDQoN Cmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvODQNCg0KDQoN Cj4gICAgICAgICAgIFRoZSB0ZXJtICJyZWxpYWJsZSB0cmFuc3BvcnQiIG9ubHkgcmVmZXJzIHRv IHN0cmVhbS1iYXNlZCB0cmFuc3BvcnQNCg0KPiAgICAgICAgICAgcHJvdG9jb2xzIHN1Y2ggYXMg VENQLg0KDQo+DQoNCj5zL29ubHkgcmVmZXJzL2lzIHVzZWQgb25seSB0byByZWZlci8NCg0KPg0K DQo+KFdlIGNvdWxkIHNheSBtb3JlIGV4cGxpY2l0bHk6IHNlcXVlbmNlZC9vcmRlci1wcmVzZXJ2 aW5nLCByZWxpYWJsZS4uLg0KDQo+U3RyZWFtIG1pZ2h0IGJlIGJ5dGUgc3RyZWFtIG9yIG1lc3Nh Z2Ugc3RyZWFtLikNCg0KDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRs cy9pc3N1ZXMvNDkNCg0KDQoNCg0KDQo+ICAgICAgICAgMi4xLiAgTWVzc2FnaW5nIE1vZGVsDQoN Cj4NCg0KPiAgICAgICAgICAgIENvbmNlcHR1YWxseSwgQ29BUCBvdmVyIFRDUCByZXBsYWNlcyBt b3N0IG9mIHRoZSBDb0FQIG92ZXIgVURQDQoNCj4gICAgICAgICAgICBtZXNzYWdlIGxheWVyIHdp dGggYSBmcmFtaW5nIG1lY2hhbmlzbSBvbiB0b3Agb2YgdGhlIGJ5dGUgc3RyZWFtDQoNCj4gICAg ICAgICAgICBwcm92aWRlZCBieSBUQ1AvVExTLCBjb252ZXlpbmcgdGhlIGxlbmd0aCBpbmZvcm1h dGlvbiBmb3IgZWFjaA0KDQo+ICAgICAgICAgICAgbWVzc2FnZSB0aGF0IG9uIGRhdGFncmFtIHRy YW5zcG9ydHMgaXMgcHJvdmlkZWQgYnkgdGhlIFVEUC9EVExTDQoNCj4gICAgICAgICAgICBkYXRh Z3JhbSBsYXllci4NCg0KDQoNCj4gcy9Db0FQIG92ZXIgVURQIG1lc3NhZ2UgbGF5ZXIvbWVzc2Fn ZSBsYXllciBvZiBDb0FQIG92ZXIgVURQLw0KDQoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUt d2cvY29hcC10Y3AtdGxzL2lzc3Vlcy84NQ0KDQoNCg0KPiAgICAgICAgICAgICAgIEZpZ3VyZSAy OiBDb21wYXJpc29uIGJldHdlZW4gQ29BUCBvdmVyIHVucmVsaWFibGUgYW5kIHJlbGlhYmxlDQoN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRyYW5zcG9ydC4NCg0K DQoNCj4gQ2FwdGlvbnMgYXJlIG5vdCBzZW50ZW5jZXMgYW5kIHRoZXJlZm9yZSBkb24ndCBlbmQg aW4gcGVyaW9kcyAoc2VlDQoNCj4gRmlndXJlIDEpLiAoQ29tbWVudCBub3QgcmVwZWF0ZWQgZnVy dGhlciBkb3duLikNCg0KDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRs cy9pc3N1ZXMvODYNCg0KDQoNCj4gICAgICAgICAyLjMuICBPcGVuaW5nIEhhbmRzaGFrZQ0KDQo+ DQoNCj4gICAgICAgICAgIFsuLi5dDQoNCj4gICAgICAgICAgICBDbGllbnRzIGFuZCBzZXJ2ZXJz IE1VU1QgdHJlYXQgYSBtaXNzaW5nIG9yIGludmFsaWQgQ1NNIGFzIGENCg0KPiAgICAgICAgICAg IGNvbm5lY3Rpb24gZXJyb3IgYW5kIGFib3J0IHRoZSBjb25uZWN0aW9uIChzZWUgU2VjdGlvbiA0 LjYpLg0KDQo+DQoNCj4gVGhpcyBpcyBwcm9iYWJseSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIGJ1 dCBpdCBkb2VzIG1lYW4gdGhhdCB3ZSBhcmUgbm93DQoNCj4gaW5jb21wYXRpYmxlIGFnYWluIHdp dGggdGhlIE9DRiAxLjAgdmVyc2lvbiBvZiBDb0FQIG92ZXIgVENQLg0KDQo+IFdlIGNvdWxkIGRl ZmluZSBhbiBPQ0YgMS4wIGNvbXBhdGliaWxpdHkgbW9kZS4NCg0KDQoNClRoZSBxdWVzdGlvbiBh Ym91dCBPQ0YgZmVlZGJhY2sgd2FzIGRpc2N1c3NlZCBhdCBJRVRGIDk3LiBNeSBleHBlY3RhdGlv biBpcyB0aGF0IE9DRg0KDQptZW1iZXJzIHdpbGwgZGlyZWN0bHkgYnJpbmcgaXNzdWVzIHRvIHRo ZSBXRy4gSW4gYWRkaXRpb24sIGlmIHRoZXJlIHdhcyBhIGNvbXBhdGliaWxpdHkgbW9kZSwNCg0K aXQgd291bGQgYmUgaW4gdGhlIGZyYW1ld29yayByYXRoZXIgdGhhbiB0aGUgcHJvdG9jb2wgZHJh ZnQuDQoNCg0KDQo+ICAgICAgICAgMi40LiAgTWVzc2FnZSBGb3JtYXQNCg0KPg0KDQo+ICAgICAg ICAgICBbLi4uXQ0KDQo+DQoNCj4gICAgICAgICAgICBvICBJbiBhIHN0cmVhbSBvcmllbnRlZCB0 cmFuc3BvcnQgcHJvdG9jb2wgc3VjaCBhcyBUQ1AsIGEgZm9ybSBvZg0KDQoNCg0KPiBzL3N0cmVh bS9ieXRlIHN0cmVhbS8NCg0KPiAoV2UgcHJvYmFibHkgc2hvdWxkIHJldmlldyB0aGUgZW50aXJl IHRlcm1pbm9sb2d5IGFib3V0ICJyZWxpYWJsZSIsDQoNCj4gc2VxdWVuY2UtcHJlc2VydmluZywg Ynl0ZS9tZXNzYWdlIHN0cmVhbXMgb25jZSBtb3JlLikNCg0KDQoNCmh0dHBzOi8vZ2l0aHViLmNv bS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvNDkNCg0KDQoNCj4gICAgICAgICAgICAwICAg ICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz DQoNCj4gICAgICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQoNCj4gICAgICAgICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQo+ICAg ICAgICAgICAgfExlbj0xMyB8ICBUS0wgIHxFeHRlbmRlZCBMZW5ndGh8ICAgICAgQ29kZSAgICAg fCBUS0wgYnl0ZXMgLi4uDQoNCj4gICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQo+ICAgICAgICAgICAg fCAgT3B0aW9ucyAoaWYgYW55KSAuLi4NCg0KPiAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCj4gICAg ICAgICAgICB8MSAxIDEgMSAxIDEgMSAxfCAgICBQYXlsb2FkIChpZiBhbnkpIC4uLg0KDQo+ICAg ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCg0KPg0KDQo+ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA0OiBD b0FQIGZyYW1lIHdpdGggOC1iaXQgRXh0ZW5kZWQgTGVuZ3RoIGZpZWxkLg0KDQoNCg0KPiBUaGlz IChhbmQgbmVpdGhlciBkb2VzIHRoZSB0ZXh0KSBkb2VzIG5vdCBtYWtlIGNsZWFyIHRoYXQgdGhl IHBheWxvYWQNCg0KPiBtYXJrZXIgaXMgc2VudCBvbmx5IGlmIHRoZXJlIGlzIGEgbm9uLXplcm8t bGVuZ3RoIHBheWxvYWQuICAoU2FtZSBmb3INCg0KPiBvdGhlciBiZWxvdy4pDQoNCg0KDQo+IFBs ZWFzZSBjZi4gdGV4dCBmcm9tIFNlY3Rpb24gMyBvZiBSRkMgNzI1MjoNCg0KDQoNCj4gICAgRm9s bG93aW5nIHRoZSBoZWFkZXIsIHRva2VuLCBhbmQgb3B0aW9ucywgaWYgYW55LCBjb21lcyB0aGUg b3B0aW9uYWwNCg0KPiAgICBwYXlsb2FkLiAgSWYgcHJlc2VudCBhbmQgb2Ygbm9uLXplcm8gbGVu Z3RoLCBpdCBpcyBwcmVmaXhlZCBieSBhDQoNCj4gICAgZml4ZWQsIG9uZS1ieXRlIFBheWxvYWQg TWFya2VyICgweEZGKSwgd2hpY2ggaW5kaWNhdGVzIHRoZSBlbmQgb2YNCg0KPiAgICBvcHRpb25z IGFuZCB0aGUgc3RhcnQgb2YgdGhlIHBheWxvYWQuICBUaGUgcGF5bG9hZCBkYXRhIGV4dGVuZHMg ZnJvbQ0KDQo+ICAgIGFmdGVyIHRoZSBtYXJrZXIgdG8gdGhlIGVuZCBvZiB0aGUgVURQIGRhdGFn cmFtLCBpLmUuLCB0aGUgUGF5bG9hZA0KDQo+ICAgIExlbmd0aCBpcyBjYWxjdWxhdGVkIGZyb20g dGhlIGRhdGFncmFtIHNpemUuICBUaGUgYWJzZW5jZSBvZiB0aGUNCg0KPiAgICBQYXlsb2FkIE1h cmtlciBkZW5vdGVzIGEgemVyby1sZW5ndGggcGF5bG9hZC4gIFRoZSBwcmVzZW5jZSBvZiBhDQoN Cj4gICAgbWFya2VyIGZvbGxvd2VkIGJ5IGEgemVyby1sZW5ndGggcGF5bG9hZCBNVVNUIGJlIHBy b2Nlc3NlZCBhcyBhDQoNCj4gICAgbWVzc2FnZSBmb3JtYXQgZXJyb3IuDQoNCg0KDQpodHRwczov L2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzg3DQoNCg0KDQo+ICAgICAg ICAgMy4gIENvQVAgb3ZlciBXZWJTb2NrZXRzDQoNCg0KDQpVbmxlc3Mgb3RoZXJ3aXNlIG5vdGVk IGJlbG93LCB0aGUgZmVlZGJhY2sgZm9yIFNlY3Rpb24gMyBpcyBjYXB0dXJlZA0KDQppbiBodHRw czovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzg4Lg0KDQoNCg0KPg0K DQo+ICAgICAgICAgICAgWy4uLl0NCg0KPg0KDQo+IEhtbSwgd2h5IGlzIHRoZSBmb2xsb3dpbmcg ZG9uZSBoZXJlIGZvciBXUyBhbmQgbm90IGFib3ZlIGZvciBUQ1A/DQoNCj4gU2VlbXMgcmVkdW5k YW50IHdpdGggNi4yPyAgT2gsIHRoZSBwb2ludCBoZXJlIGlzIHRvIGRlcml2ZSB0aGUgd3Nbc10N Cg0KPiBVUkkgdXNlZCBmb3Igc2V0dGluZyB1cCB0aGUgV1M/DQoNCj4NCg0KPiAgICAgICAgICAg IFNlY3Rpb24gNi4yIGRlZmluZXMgYSBuZXcgImNvYXArd3MiIFVSSSBzY2hlbWUgdGhhdCBpZGVu dGlmaWVzIGJvdGggYQ0KDQo+ICAgICAgICAgICAgV2ViU29ja2V0IGVuZHBvaW50IGFuZCBhIHJl c291cmNlIHdpdGhpbiB0aGF0IGVuZHBvaW50IGFzIGZvbGxvd3M6DQoNCj4NCg0KPiAgICAgICAg ICAgICAgICAgICAgICBjb2FwK3dzOi8vZXhhbXBsZS5vcmcvc2Vuc29ycy90ZW1wZXJhdHVyZT91 PUNlbA0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgXF9fX19fXyAgX19fX19fL1xfX19f X19fX19fXyAgX19fX19fX19fX18vDQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXC8gICAgICAgICAgICAgICAgICAgXC8NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVXJpLVBhdGg6ICJzZW5zb3JzIg0KDQo+ICAgICAg ICAgICAgICAgIHdzOi8vZXhhbXBsZS5vcmcvLndlbGwta25vd24vY29hcCAgICBVcmktUGF0aDog InRlbXBlcmF0dXJlIg0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBVcmktUXVlcnk6ICJ1PUNlbCINCg0KPg0KDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBGaWd1cmUgMTA6IFRoZSAiY29hcCt3cyIgVVJJIFNjaGVtZQ0KDQo+DQoN Cg0KDQpJdCBhcHBlYXJzIHRoYXQgeW91IGFuc3dlcmVkIHlvdXIgb3duIHF1ZXN0aW9uLg0KDQoN Cg0KPiBUaGUgZm9sbG93aW5nIG5vdyBzZWVtcyB1bnJlbGF0ZWQ6DQoNCj4NCg0KPiAgICAgICAg ICAgIEFub3RoZXIgcG9zc2libGUgY29uZmlndXJhdGlvbiBpcyB0byBzZXQgdXAgYSBDb0FQIGZv cndhcmQgcHJveHkgYXQNCg0KPiAgICAgICAgICAgIHRoZSBXZWJTb2NrZXQgZW5kcG9pbnQuICBE ZXBlbmRpbmcgb24gd2hhdCB0cmFuc3BvcnRzIGFyZSBhdmFpbGFibGUNCg0KPiAgICAgICAgICAg IFsuLi5dDQoNCj4NCg0KPiAgICAgICAgICAgICAgRmlndXJlIDEyOiBDb0FQIENsaWVudCAoVURQ IGNsaWVudCkgYWNjZXNzZXMgc2xlZXB5IENvQVAgU2VydmVyDQoNCj4gICAgICAgICAgICAgKFdl YlNvY2tldCBjbGllbnQpIHZpYSBhIENvQVAgcHJveHkgKFVEUCBzZXJ2ZXIvV2ViU29ja2V0IHNl cnZlcikNCg0KPg0KDQo+IHMvc2xlZXB5Ly8NCg0KPiAoVGhlcmUgaXMgbm8gbWVudGlvbiBvZiBz bGVlcGluZXNzIGhlcmUuKQ0KDQo+DQoNCj4gICAgICAgICAgICBbLi4uXQ0KDQo+DQoNCj4gICAg ICAgICAgICBDb0FQIG92ZXIgV2ViU29ja2V0cyBpcyBpbnRlbnRpb25hbGx5IHZlcnkgc2ltaWxh ciB0byBDb0FQIG92ZXIgVURQLg0KDQo+ICAgICAgICAgICAgVGhlcmVmb3JlLCBpbnN0ZWFkIG9m IHByZXNlbnRpbmcgQ29BUCBvdmVyIFdlYlNvY2tldHMgYXMgYSBuZXcNCg0KPiAgICAgICAgICAg IHByb3RvY29sLCB0aGlzIGRvY3VtZW50IHNwZWNpZmllcyBpdCBhcyBhIHNlcmllcyBvZiBkZWx0 YXMgZnJvbQ0KDQo+ICAgICAgICAgICAgW1JGQzcyNTJdLg0KDQo+DQoNCj4gUHJvYmFibHkgYmVz dCB0byBkZWxldGUgdGhhdCBwYXJhZ3JhcGggLS0gaXQgaXMgdHJ1ZSBub3Qgb25seSBmb3IgV1Ms DQoNCj4gYnV0IGFsc28gZm9yIFRDUC4gIFNvIHdoeSBvbmx5IGhlcmU/DQoNCj4NCg0KPiAgICAg ICAgIDMuMS4gIE9wZW5pbmcgSGFuZHNoYWtlDQoNCj4NCg0KPiBIbW0sIHRoZSB0aXRsZSBpcyBj b25mdXNpbmcuICBXUyBhbHNvIHVzZXMgdGhlIHNhbWUgb3BlbmluZyBoYW5kc2hha2UgYXMgMi4z Lg0KDQo+IFRoZSBwYXJ0cyB0aGF0IHJlbGF0ZSB0byBib3RoIFRDUC9UTFMgYW5kIFdTL1MgbmVl ZCB0byBiZSBmYWN0b3JlZCBvdXQuDQoNCj4NCg0KPg0KDQo+ICAgICAgICAgMy4yLiAgTWVzc2Fn ZSBGb3JtYXQNCg0KPg0KDQo+ICAgICAgICAgICAgWy4uLl0NCg0KPg0KDQo+ICAgICAgICAgICAg VGhlIG1lc3NhZ2UgZm9ybWF0IHNob3duIGluIEZpZ3VyZSAxNCBpcyB0aGUgc2FtZSBhcyB0aGUg Q29BUCBvdmVyDQoNCj4gICAgICAgICAgICBUQ1AgbWVzc2FnZSBmb3JtYXQgKHNlZSBTZWN0aW9u IDIuNCkgd2l0aCBvbmUgcmVzdHJpY3Rpb24uICBUaGUNCg0KPiAgICAgICAgICAgIExlbmd0aCAo TGVuKSBmaWVsZCBNVVNUIGJlIHNldCB0byB6ZXJvIGJlY2F1c2UgdGhlIFdlYlNvY2tldHMgZnJh bWUNCg0KPiAgICAgICAgICAgIGFscmVhZHkgY29udGFpbnMgdGhlIGxlbmd0aC4NCg0KPg0KDQo+ IHMvcmVzdHJpY3Rpb24vY2hhbmdlLy4NCg0KPg0KDQo+ICAgICAgICAgICAgWy4uLl0NCg0KPg0K DQo+ICAgICAgICAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMNCg0KPiAgICAgICAgICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KDQo+ICAg ICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KDQo+ICAgICAgICAgICAgICB8ICAgTGVuIHwgIFRLTCAgfCAg ICAgIENvZGUgICAgIHwgICAgVG9rZW4gKFRLTCBieXRlcykgLi4uDQoNCj4gICAgICAgICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQoNCj4gICAgICAgICAgICAgIHwgICBPcHRpb25zIChpZiBhbnkpIC4uLg0KDQo+ ICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KDQo+ICAgICAgICAgICAgICB8MSAxIDEgMSAxIDEgMSAx fCAgICBQYXlsb2FkIChpZiBhbnkpIC4uLg0KDQo+ICAgICAgICAgICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQo+ DQoNCj4gICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxNDogQ29BUCBNZXNzYWdlIEZvcm1h dCBvdmVyIFdlYlNvY2tldHMNCg0KPg0KDQo+IE1heWJlIHNob3cgMCwgbm90IExlbiBoZXJlLg0K DQo+IChUaGlzIGFsc28gZG9lcyBub3QgbWFrZSBjbGVhciB0aGF0IHRoZSBwYXlsb2FkIG1hcmtl ciBpcyBzZW50IG9ubHkgaWYNCg0KPiB0aGVyZSBpcyBhIG5vbi16ZXJvLWxlbmd0aCBwYXlsb2Fk LikNCg0KPg0KDQoNCg0KQWRkZWQgdG8gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10 Y3AtdGxzL2lzc3Vlcy84Nw0KDQoNCg0KPiAgICAgICAgICAgIFRoZSBDb0FQIG92ZXIgVENQIG1l c3NhZ2UgZm9ybWF0IGVsaW1pbmF0ZXMgdGhlIFZlcnNpb24gZmllbGQgZGVmaW5lZA0KDQo+ICAg ICAgICAgICAgaW4gQ29BUCBvdmVyIFVEUC4gIElmIENvQVAgdmVyc2lvbiBuZWdvdGlhdGlvbiBp cyByZXF1aXJlZCBpbiB0aGUNCg0KPiAgICAgICAgICAgIGZ1dHVyZSwgQ29BUCBvdmVyIFdlYlNv Y2tldHMgY2FuIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50IGJ5IHRoZQ0KDQo+ICAgICAgICAgICBk ZWZpbml0aW9uIG9mIGEgbmV3IHN1YnByb3RvY29sIGlkZW50aWZpZXIgdGhhdCBpcyBuZWdvdGlh dGVkIGR1cmluZw0KDQo+ICAgICAgICAgICB0aGUgb3BlbmluZyBoYW5kc2hha2UuDQoNCj4NCg0K PiBUaGlzIHBhcmFncmFwaCBpcyBhIGJpdCB3ZWlyZC4gIE1heWJlOg0KDQo+DQoNCj4gICAgQXMg d2l0aCBDb0FQIG92ZXIgVENQLCB0aGUgbWVzc2FnZSBmb3JtYXQgZm9yIENvQVAgb3ZlciBXZWJz b2NrZXRzDQoNCj4gICAgZWxpbWluYXRlcyB0aGUgVmVyc2lvbiBmaWVsZCBkZWZpbmVkIGluIENv QVAgb3ZlciBVRFAuICBJZiBDb0FQIFsuLi5dDQoNCj4NCg0KPiAgICAgICAgICAgIFsuLi5dDQoN Cj4NCg0KPiAgICAgICAgICAgIEVtcHR5IG1lc3NhZ2VzIChDb2RlIDAuMDApIE1VU1QgYmUgaWdu b3JlZCBieSB0aGUgcmVjaXBpZW50IChzZWUgYWxzbw0KDQo+ICAgICAgICAgICAgU2VjdGlvbiA0 LjQpLg0KDQo+DQoNCj4gV2h5IGFyZSB3ZSBzYXlpbmcgdGhpcyBoZXJlIGFuZCBub3QgaW4gU2Vj dGlvbiAyPw0KDQo+IEZhY3RvciBvdXQuDQoNCj4NCg0KPiAgICAgICAgIDMuMy4gIE1lc3NhZ2Ug VHJhbnNtaXNzaW9uDQoNCj4NCg0KPiAgICAgICAgICAgIFsuLi5dDQoNCj4NCg0KPiBTaW1pbGFy IGFzIHdpdGggQ29BUCBvdmVyIFRDUCwNCg0KPiAgICAgICAgICAgIFJldHJhbnNtaXNzaW9uIGFu ZCBkZWR1cGxpY2F0aW9uIG9mIG1lc3NhZ2VzIGlzIHByb3ZpZGVkIGJ5IHRoZQ0KDQo+ICAgICAg ICAgICAgV2ViU29ja2V0IHByb3RvY29sLiAgQ29BUCBvdmVyIFdlYlNvY2tldHMgdGhlcmVmb3Jl IGRvZXMgbm90IG1ha2UgYQ0KDQo+ICAgICAgICAgICAgZGlzdGluY3Rpb24gYmV0d2VlbiBDb25m aXJtYWJsZSBvciBOb24tQ29uZmlybWFibGUgbWVzc2FnZXMsIGFuZCBkb2VzDQoNCj4gICAgICAg ICAgICBub3QgcHJvdmlkZSBBY2tub3dsZWRnZW1lbnQgb3IgUmVzZXQgbWVzc2FnZXMuDQoNCj4N Cg0KPiAgICAgICAgIDMuNC4gIENvbm5lY3Rpb24gSGVhbHRoDQoNCj4NCg0KPiAgICAgICAgICAg Wy4uLl0NCg0KPiAgICAgICAgICAgIFRoZXJlIGlzIG5vIHdheSB0byByZXRyYW5zbWl0IGEgcmVx dWVzdCB3aXRob3V0IGNyZWF0aW5nIGEgbmV3IG9uZS4NCg0KPiAgICAgICAgICAgIFJlLXJlZ2lz dGVyaW5nIGludGVyZXN0IGluIGEgcmVzb3VyY2UgaXMgcGVybWl0dGVkLCBidXQgZW50aXJlbHkN Cg0KPiAgICAgICAgICAgIHVubmVjZXNzYXJ5Lg0KDQo+DQoNCj4gKFNlZSB0aGUgZGlzY3Vzc2lv biB3ZSBhbHJlYWR5IGhhZC4pDQoNCg0KDQpUaGUgZGlzY3Vzc2lvbiBpcyBpbiBodHRwczovL2dp dGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzcxDQoNCg0KDQo+ICAgICAgICAg NC4gIFNpZ25hbGluZw0KDQoNCg0KVW5sZXNzIG90aGVyd2lzZSBub3RlZCBiZWxvdywgdGhlIGZl ZWRiYWNrIGZvciBTZWN0aW9uIDQgaXMgY2FwdHVyZWQNCg0KaW4gaHR0cHM6Ly9naXRodWIuY29t L2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy84OS4NCg0KDQoNCj4gICAgICAgICAgICBTaWdu YWxpbmcgbWVzc2FnZXMgYXJlIGludHJvZHVjZWQgdG8gYWxsb3cgcGVlcnMgdG86DQoNCj4NCg0K PiAgICAgICAgICAgIG8gIFNoYXJlIGNoYXJhY3RlcmlzdGljcyBzdWNoIGFzIG1heGltdW0gbWVz c2FnZSBzaXplIGZvciB0aGUgY29ubmVjdGlvbg0KDQo+DQoNCj4gcy9TaGFyZS9SZWxhdGUvDQoN Cj4gKHRoZSBub2RlcyBkbyBub3QgInNoYXJlIHRoZXNlIGNoYXJhY3RlcmlzdGljcyIpDQoNCj4N Cg0KPiAgICAgICAgICAgIG8gIFNodXRkb3duIHRoZSBjb25uZWN0aW9uIGluIGFuIG9yZGVyZWQg ZmFzaGlvbg0KDQo+DQoNCj4gU2h1dCBkb3duDQoNCj4gcy9PcmRlcmVkL09yZGVybHkvDQoNCj4N Cg0KPiAgICAgICAgICAgIG8gIFRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBpbiByZXNwb25zZSB0 byBhIHNlcmlvdXMgZXJyb3IgY29uZGl0aW9uDQoNCj4NCg0KPiBQcm92aWRlIGRpYWdub3N0aWMg aW5mb3JtYXRpb24gd2hlbiB0ZXJtaW5hdGluZyBhIGNvbm5lY3Rpb24gaW4gLi4uDQoNCj4NCg0K Pg0KDQo+ICAgICAgICAgNC4zLiAgQ2FwYWJpbGl0eSBhbmQgU2V0dGluZ3MgTWVzc2FnZXMgKENT TSkNCg0KPg0KDQo+IEhtbSwgc2hvdWxkIHRoaXMgYmUgIkNhcGFiaWxpdGllcyBhbmQgU2V0dGlu Z3MgTWVzc2FnZXMiPw0KDQo+IChOZWVkIHRvIGNoYW5nZSB0aHJvdWdob3V0LikNCg0KPg0KDQo+ ICAgICAgICAgICAgQ2FwYWJpbGl0eSBhbmQgU2V0dGluZ3MgbWVzc2FnZXMgKENTTSkgYXJlIHVz ZWQgZm9yIHR3byBwdXJwb3NlczoNCg0KPg0KDQo+ICAgICAgICAgICAgbyAgRWFjaCBjYXBhYmls aXR5IG9wdGlvbiBhZHZlcnRpc2VzIG9uZSBjYXBhYmlsaXR5IG9mIHRoZSBzZW5kZXIgdG8NCg0K PiAgICAgICAgICAgICAgIHRoZSByZWNpcGllbnQuDQoNCj4NCg0KPiAgICAgICAgICAgIG8gIFNl dHRpbmcgb3B0aW9ucyBpbmRpY2F0ZSBhIHNldHRpbmcgdGhhdCB3aWxsIGJlIGFwcGxpZWQgYnkg dGhlDQoNCj4gICAgICAgICAgICAgICBzZW5kZXIuDQoNCj4NCg0KPiBzL0EvT25lLw0KDQo+IHMv Q2FwYWJpbGl0eSBhbmQgU2V0dGluZ3MgbWVzc2FnZS9DU00vDQoNCj4gICAgICAgICAgICBBIENh cGFiaWxpdHkgYW5kIFNldHRpbmdzIG1lc3NhZ2UgTVVTVCBiZSBzZW50IGJ5IGJvdGggZW5kcG9p bnRzIGF0DQoNCj4gICAgICAgICAgIHRoZSBzdGFydCBvZiB0aGUgY29ubmVjdGlvbiBhbmQgTUFZ IGJlIHNlbnQgYXQgYW55IG90aGVyIHRpbWUgYnkNCg0KPiBzL2FuZC8uIEZ1cnRoZXIgQ1NNLw0K DQo+ICAgICAgICAgICAgZWl0aGVyIGVuZHBvaW50IG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBj b25uZWN0aW9uLg0KDQo+DQoNCj4gICAgICAgICAgICBCb3RoIGNhcGFiaWxpdHkgYW5kIHNldHRp bmdzIG9wdGlvbnMgYXJlIGN1bXVsYXRpdmUuICBBIENhcGFiaWxpdHkNCg0KPiBzL3NldHRpbmdz L3NldHRpbmcvDQoNCj4gICAgICAgICAgICBhbmQgU2V0dGluZ3MgbWVzc2FnZSBkb2VzIG5vdCBp bnZhbGlkYXRlIGEgcHJldmlvdXNseSBzZW50IGNhcGFiaWxpdHkNCg0KPiAgICAgICAgICAgIGlu ZGljYXRpb24gb3Igc2V0dGluZyBldmVuIGlmIGl0IGlzIG5vdCByZXBlYXRlZC4gIEEgY2FwYWJp bGl0eQ0KDQo+ICAgICAgICAgICAgbWVzc2FnZSB3aXRob3V0IGFueSBvcHRpb24gaXMgYSBuby1v cGVyYXRpb24gKGFuZCBjYW4gYmUgdXNlZCBhcw0KDQo+ICAgICAgICAgICAgc3VjaCkuICBBbiBv cHRpb24gdGhhdCBpcyBzZW50IG1pZ2h0IG92ZXJyaWRlIGEgcHJldmlvdXMgdmFsdWUgZm9yDQoN Cj4NCg0KPiAgICAgICAgNC4zLjEuICBTZXJ2ZXItTmFtZSBTZXR0aW5nIE9wdGlvbg0KDQo+DQoN Cj4gICAgICAgICAgIFsuLi5dDQoNCj4gICAgICAgICAgICBGb3IgVExTLCB0aGUgaW5pdGlhbCB2 YWx1ZSBmb3IgdGhlIFNlcnZlci1OYW1lIE9wdGlvbiBpcyBnaXZlbiBieSB0aGUNCg0KPiAgICAg ICAgICAgIFNOSSB2YWx1ZS4NCg0KPg0KDQo+IHMvaW5pdGlhbC9iYXNlLz8/Pw0KDQoNCg0KVGhp cyBpcyBhbHJlYWR5IGFkZHJlc3NlZCBpbiBteSBwZW5kaW5nIHB1bGwgcmVxdWVzdCAtIGh0dHBz Oi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9wdWxsLzY3L2NvbW1pdHMvNmVhMTJh NzAwYWZlOGVkOGQ5MDk2OTFhZjRmYzQ1NmViZWZiNjE4ZQ0KDQoNCg0KPiAgICAgICAgIDQuMy4y LiAgTWF4LU1lc3NhZ2UtU2l6ZSBDYXBhYmlsaXR5IE9wdGlvbg0KDQo+DQoNCj4gICAgICAgICAg ICBBcyBwZXIgU2VjdGlvbiA0LjYgb2YgW1JGQzcyNTJdLCB0aGUgYmFzZSB2YWx1ZSAoYW5kIHRo ZSB2YWx1ZSB1c2VkDQoNCj4gICAgICAgICAgICB3aGVuIHRoaXMgb3B0aW9uIGlzIG5vdCBpbXBs ZW1lbnRlZCkgaXMgMTE1Mi4gIEEgcGVlciB0aGF0IHJlbGllcyBvbg0KDQo+ICAgICAgICAgICAg dGhpcyBvcHRpb24gYmVpbmcgaW5kaWNhdGVkIHdpdGggYSBjZXJ0YWluIG1pbmltdW0gdmFsdWUg d2lsbCBlbmpveQ0KDQo+ICAgICAgICAgICAgbGltaXRlZCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQo+ DQoNCj4gKGFib3ZlIDExNTI/KQ0KDQoNCg0KPiA2LiAgQ29BUCBVUklzDQoNCg0KDQpVbmxlc3Mg b3RoZXJ3aXNlIG5vdGVkIGJlbG93LCB0aGUgZmVlZGJhY2sgZm9yIFNlY3Rpb24gNiBpcyBjYXB0 dXJlZA0KDQppbiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVz Lzc1Lg0KDQoNCg0KPiAgICAgICAgICAgIENvQVAgb3ZlciBVRFAgW1JGQzcyNTJdIGRlZmluZXMg dGhlICJjb2FwIiBhbmQgImNvYXBzIiBVUkkgc2NoZW1lcw0KDQo+ICAgICAgICAgICAgZm9yIGlk ZW50aWZ5aW5nIENvQVAgcmVzb3VyY2VzIGFuZCBwcm92aWRpbmcgYSBtZWFucyBvZiBsb2NhdGlu ZyB0aGUNCg0KPiAgICAgICAgICAgIHJlc291cmNlLg0KDQoNCg0KPiBJbiB0aGlzIHNlY3Rpb24s IHRoZSB0ZXJtcyAiY2xpZW50IiBhbmQgInNlcnZlciIgYXJlIHVzZWQgV1JUIHRoZSBUQ1ANCg0K PiBjb25uZWN0aW9uLCBub3QgV1JUIENvQVAsIGFuZCB0aGF0IG1heSBiZSB2ZXJ5IGNvbmZ1c2lu Zy4gIE1heWJlIHVzZQ0KDQo+IGRpZmZlcmVudCB0ZXJtcyBoZXJlIChpbml0aWF0b3IvcmVzcG9u ZGVyKT8NCg0KDQoNCj4gICAgICAgICA2LjEuICBDb0FQIG92ZXIgVENQIGFuZCBUTFMgVVJJcw0K DQo+DQoNCj4gICAgICAgICAgICBbUkZDNzI1Ml0sIFNlY3Rpb24gOCAoTXVsdGljYXN0IENvQVAp IGlzIG5vdCBhcHBsaWNhYmxlIHRvIHRoZXNlIHNjaGVtZXMuDQoNCj4NCg0KPiBOb3Qgc3VyZSB0 aGlzIGJlbG9uZ3MgaGVyZSwgYnV0IGl0IGFsc28gc2hvdWxkIGFwcGx5IHRvIDYuMiwgc28gbWF5 YmUNCg0KPiBtb3ZlIGl0IHVwIHRvIDYuDQoNCj4NCg0KPiAgICAgICAgICAgIFJlc291cmNlcyBt YWRlIGF2YWlsYWJsZSB2aWEgb25lIG9mIHRoZSAiY29hcCt0Y3AiIG9yICJjb2Fwcyt0Y3AiDQoN Cj4gICAgICAgICAgICBzY2hlbWVzIGhhdmUgbm8gc2hhcmVkIGlkZW50aXR5IHdpdGggdGhlIG90 aGVyIHNjaGVtZSBvciB3aXRoIHRoZQ0KDQo+ICAgICAgICAgICAgImNvYXAiIG9yICJjb2FwcyIg c2NoZW1lLCBldmVuIGlmIHRoZWlyIHJlc291cmNlIGlkZW50aWZpZXJzIGluZGljYXRlDQoNCj4g ICAgICAgICAgICB0aGUgc2FtZSBhdXRob3JpdHkgKHRoZSBzYW1lIGhvc3QgbGlzdGVuaW5nIHRv IHRoZSBzYW1lIHBvcnQpLiAgVGhlDQoNCj4gICAgICAgICAgICBzY2hlbWVzIGNvbnN0aXR1dGUg ZGlzdGluY3QgbmFtZXNwYWNlcyBhbmQsIGluIGNvbWJpbmF0aW9uIHdpdGggdGhlDQoNCj4gICAg ICAgICAgICBhdXRob3JpdHksIGFyZSBjb25zaWRlcmVkIHRvIGJlIGRpc3RpbmN0IG9yaWdpbiBz ZXJ2ZXJzLg0KDQo+DQoNCj4gRGl0dG8uDQoNCj4NCg0KPiAgICAgICAgIDYuMi4gIENvQVAgb3Zl ciBXZWJTb2NrZXRzIFVSSXMNCg0KPg0KDQo+ICAgICAgICAgICAgRm9yIHRoZSBmaXJzdCBjb25m aWd1cmF0aW9uIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMsIHRoaXMgZG9jdW1lbnQNCg0KPiAgICAg ICAgICAgZGVmaW5lcyB0d28gbmV3IFVSSXMgc2NoZW1lcyB0aGF0IGNhbiBiZSB1c2VkIGZvciBp ZGVudGlmeWluZyBDb0FQDQoNCj4gICAgICAgICAgIHJlc291cmNlcyBhbmQgcHJvdmlkaW5nIGEg bWVhbnMgb2YgbG9jYXRpbmcgdGhlc2UgcmVzb3VyY2VzOg0KDQo+ICAgICAgICAgICAiY29hcCt3 cyIgYW5kICJjb2FwK3dzcyIuDQoNCg0KDQo+IGNvYXArd3NzIGlzIHRoZSBvbmx5IGNvYXBzIHNj aGVtZSB0aGF0IGRvZXNuJ3QgaGF2ZSBjb2FwcyBpbiB0aGUgbmFtZS4NCg0KPiBJIGNvbnRpbnVl IHRvIGJlbGlldmUgdGhhdCB0aGlzIGlzIGEgbWlzdGFrZS4NCg0KPiBzL2NvYXArd3NzL2NvYXBz K3dzL2cuDQoNCg0KDQpUaGlzIGlzIHRoZSBiaWtlc2hlZCAtIGh0dHA6Ly9iaWtlc2hlZC5jb20v IC0gd2hpY2ggd2FzIGRpc2N1c3NlZCBhdCBJRVRGIDk2IHdpdGggbm8NCg0KY29uc2Vuc3VzIGFu ZCByYWlzZWQgYWdhaW4gYXQgdGhlIGluZm9ybWFsIENvUkUgbWVldGluZyBhdCBJRVRGIDk3IHdp dGggbm8gb3BpbmlvbnMNCg0KZXhwcmVzc2VkIGZyb20gdGhlIHBhcnRpY2lwYW50cy4NCg0KDQoN Ck91ciBwcmVmZXJlbmNlcyBhcmUgYm90aCBub3RlZCBpbiAtIGh0dHBzOi8vZ2l0aHViLmNvbS9j b3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTIuDQoNCg0KDQpJ4oCZZCBkZWZlciB0byB0aGUg Y2hhaXIgZm9yIGNvYXAtdGNwLXRscyAoSmFpbWUpIG9uIGhvdyBoZeKAmWQgbGlrZSB0byBwcm9j ZWVkLg0KDQoNCg0KPiAgICAgICAgICAgIFNpbWlsYXIgdG8gdGhlICJjb2FwIiBhbmQgImNvYXBz IiBzY2hlbWVzLCB0aGUgImNvYXArd3MiIGFuZA0KDQo+ICAgICAgICAgICAgImNvYXArd3NzIiBz Y2hlbWVzIG9yZ2FuaXplIHJlc291cmNlcyBoaWVyYXJjaGljYWxseSB1bmRlciBhIENvQVANCg0K PiAgICAgICAgICAgIG9yaWdpbiBzZXJ2ZXIuICBUaGUga2V5IGRpZmZlcmVuY2UgaXMgdGhhdCB0 aGUgc2VydmVyIGlzIHBvdGVudGlhbGx5DQoNCj4gICAgICAgICAgICByZWFjaGFibGUgb24gYSBX ZWJTb2NrZXQgZW5kcG9pbnQgaW5zdGVhZCBvZiBhIFVEUCBlbmRwb2ludC4NCg0KPg0KDQo+IHMv cG90ZW50aWFsbHkgcmVhY2hhYmxlL2ludGVuZGVkIHRvIGJlIHJlYWNoZWQvDQoNCj4NCg0KPiAg ICAgICAgICAgIFRoZSBXZWJTb2NrZXQgZW5kcG9pbnQgaXMgaWRlbnRpZmllZCBieSBhICJ3cyIg b3IgIndzcyIgVVJJIHRoYXQgaXMNCg0KPiAgICAgICAgICAgIGNvbXBvc2VkIG9mIHRoZSBhdXRo b3JpdHkgcGFydCBvZiB0aGUgImNvYXArd3MiIG9yICJjb2FwK3dzcyIgVVJJLA0KDQo+ICAgICAg ICAgICAgcmVzcGVjdGl2ZWx5LCBhbmQgdGhlIHdlbGwta25vd24gcGF0aCAiLy53ZWxsLWtub3du L2NvYXAiIFtSRkM1Nzg1XS4NCg0KPiAgICAgICAgICAgIFRoZSBwYXRoIGFuZCBxdWVyeSBwYXJ0 cyBvZiBhICJjb2FwK3dzIiBvciAiY29hcCt3c3MiIFVSSSBpZGVudGlmeSBhDQoNCj4gICAgICAg ICAgICByZXNvdXJjZSB3aXRoaW4gdGhlIHNwZWNpZmllZCBlbmRwb2ludCB3aGljaCBjYW4gYmUg b3BlcmF0ZWQgb24gYnkNCg0KPiAgICAgICAgICAgdGhlIG1ldGhvZHMgZGVmaW5lZCBieSBDb0FQ Lg0KDQo+DQoNCj4gVGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggYXBwbGllcyB0byA2LjEuMSwgNi4x LjIsIGFuZCB0aGlzIHN1YnNlY3Rpb24uDQoNCj4gKE1vdmUgdXAgdG8gNi4pDQoNCj4NCg0KPiAg ICAgICAgICAgIFRoZSBzeW50YXggb2YgdGhlICJjb2FwK3dzIiBhbmQgImNvYXArd3NzIiBVUkkg c2NoZW1lcyBpcyBzcGVjaWZpZWQNCg0KPiAgICAgICAgICAgIGJlbG93IGluIEF1Z21lbnRlZCBC YWNrdXMtTmF1ciBGb3JtIChBQk5GKSBbUkZDNTIzNF0uICBUaGUNCg0KPiAgICAgICAgICAgIGRl ZmluaXRpb25zIG9mICJob3N0IiwgInBvcnQiLCAicGF0aC1hYmVtcHR5IiBhbmQgInF1ZXJ5IiBh cmUgdGhlDQoNCj4gICAgICAgICAgICBzYW1lIGFzIGluIFtSRkMzOTg2XS4NCg0KPg0KDQo+ICAg ICAgICAgICAgICBjb2FwLXdzLVVSSSA9DQoNCj4gICAgICAgICAgICAgICAgICJjb2FwK3dzOiIg Ii8vIiBob3N0IFsgIjoiIHBvcnQgXSBwYXRoLWFiZW1wdHkgWyAiPyIgcXVlcnkgXQ0KDQo+DQoN Cj4gICAgICAgICAgICAgIGNvYXAtd3NzLVVSSSA9DQoNCj4gICAgICAgICAgICAgICAgImNvYXAr d3NzOiIgIi8vIiBob3N0IFsgIjoiIHBvcnQgXSBwYXRoLWFiZW1wdHkgWyAiPyIgcXVlcnkgXQ0K DQo+DQoNCj4gICAgICAgICAgICBUaGUgcG9ydCBjb21wb25lbnQgaXMgT1BUSU9OQUw7IHRoZSBk ZWZhdWx0IGZvciAiY29hcCt3cyIgaXMgcG9ydCA4MCwNCg0KPiAgICAgICAgICAgIHdoaWxlIHRo ZSBkZWZhdWx0IGZvciAiY29hcCt3c3MiIGlzIHBvcnQgNDQzLg0KDQo+DQoNCj4gICAgICAgICAg ICBGcmFnbWVudCBpZGVudGlmaWVycyBhcmUgbm90IHBhcnQgb2YgdGhlIHJlcXVlc3QgVVJJIGFu ZCB0aHVzIE1VU1QNCg0KPiAgICAgICAgICAgIE5PVCBiZSB0cmFuc21pdHRlZCBpbiBhIFdlYlNv Y2tldCBoYW5kc2hha2Ugb3IgaW4gdGhlIFVSSSBvcHRpb25zIG9mDQoNCj4gICAgICAgICAgICBh IENvQVAgcmVxdWVzdC4NCg0KPg0KDQo+IChUaGV5IGNhbid0IGJlIGluIGEgQ29BUCByZXF1ZXN0 OyBub3Qgc3VyZSB3aGF0IHRoZSBNVVNUIE5PVCBtZWFucy4NCg0KPiBCdXQgYWdhaW4sIHRoaXMg YWxzbyBhcHBsaWVzIHRvIHRoZSBUQ1AvVExTIGNhc2UuKQ0KDQoNCg0KVGhpcyBpcyBkdXBsaWNh dGVkIGZyb20gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhdm9sYWluZW4tY29y ZS1jb2FwLXdlYnNvY2tldHMtMDcjc2VjdGlvbi0zLg0KDQpBbnkgY29tbWVudHMgZnJvbSB0aGUg b3JpZ2luYWwgYXV0aG9ycyBvbiB0aGVpciBpbnRlbnQ/DQoNCg0KDQo+ICAgICAgICAgNi4yLjEu ICBEZWNvbXBvc2luZyBhbmQgQ29tcG9zaW5nIFVSSXMNCg0KPg0KDQo+DQoNCj4gICAgICAgICAg ICBvICBBIFVyaS1Ib3N0IE9wdGlvbiBNVVNUIG9ubHkgYmUgaW5jbHVkZWQgaW4gYSByZXF1ZXN0 IHdoZW4gdGhlDQoNCj4gICAgICAgICAgICAgICA8aG9zdD4gY29tcG9uZW50IGRvZXMgbm90IGVx dWFsIHRoZSB1cmktaG9zdCBjb21wb25lbnQgaW4gdGhlIEhvc3QNCg0KPiAgICAgICAgICAgICAg IGhlYWRlciBmaWVsZCBpbiB0aGUgV2ViU29ja2V0IGhhbmRzaGFrZS4NCg0KPg0KDQo+IFdyb25n IHVzZSBvZiBNVVNULiAgKE1VU1QgaXQgYmUgaW5jbHVkZWQgb3IgaXMgdGhpcyBhIE1VU1QgTk9U IGlmIGVxdWFsPykNCg0KPg0KDQo+ICAgICAgICAgICAgbyAgQSBVcmktUG9ydCBPcHRpb24gTVVT VCBvbmx5IGJlIGluY2x1ZGVkIGluIGEgcmVxdWVzdCBpZiB8cG9ydHwNCg0KPiAgICAgICAgICAg ICAgIGRvZXMgbm90IGVxdWFsIHRoZSBwb3J0IGNvbXBvbmVudCBpbiB0aGUgSG9zdCBoZWFkZXIg ZmllbGQgaW4gdGhlDQoNCj4gICAgICAgICAgICAgICBXZWJTb2NrZXQgaGFuZHNoYWtlLg0KDQo+ DQoNCj4gRGl0dG8uDQoNCj4NCg0KPiAgICAgICAgICAgIFRoZSBzdGVwcyB0byBjb25zdHJ1Y3Qg YSBVUkkgZnJvbSBhIHJlcXVlc3QncyBvcHRpb25zIGFyZSBjaGFuZ2VkDQoNCj4gICAgICAgICAg ICBhY2NvcmRpbmdseS4NCg0KPg0KDQo+ICAgICAgICAgNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zDQoNCj4NCg0KPiAgICAgICAgICAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBb UkZDNzI1Ml0gYXBwbHkuDQoNCj4gV2UgU0hPVUxEIE5PVCBiZSB1c2luZyBSRkMgMjExOSBsYW5n dWFnZSBpbiB0aGUgc2VjdXJpdHkNCg0KPiBjb25zaWRlcmF0aW9ucy4gIElmIHRoZXJlIGFyZSBt YW5kYXRlcywgdGhleSBTSE9VTEQgYmUgaW4gdGhlIHNlY3Rpb25zDQoNCj4gZGVmaW5pbmcgdGhl IHByb3RvY29sLiAgUG9zc2libGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJpc2luZyBmcm9t DQoNCj4gdGhvc2UgbWFuZGF0ZXMgdGhlbiBhcmUgZGlzY3Vzc2VkIGhlcmUuDQoNCg0KDQo8c25p cD4NCg0KDQoNCj4gICAgICAgICAgIFRoZSBUTFMgdXNhZ2UgZ3VpZGFuY2UgaW4gW1JGQzc5MjVd IFNIT1VMRCBiZSBmb2xsb3dlZC4NCg0KDQoNCj4gVGhlcmUgYXJlIHNldmVyYWwgTVVTVHMgaW4g dGhhdCBkb2N1bWVudC4gIERvIHdlIHdhbnQgdG8gdHVybiB0aGVtDQoNCj4gaW50byBTSE9VTERz PyAgTm8uIC0+DQoNCg0KDQo+ICAgIFRoZSBUTFMgdXNhZ2UgZ3VpZGFuY2UgaW4gW1JGQzc5MjVd IGFwcGxpZXMuDQoNCg0KDQpBZGRlZCB0byBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2Fw LXRjcC10bHMvaXNzdWVzLzExDQoNCg0KDQpJ4oCZbSBhZGRpbmcgYSBTZWN1cmluZyBDb0FQIHNl Y3Rpb24gbGlrZSBSRkM3MjUyLiBXZeKAmXJlIHJldmlld2luZyB0aGUgb3V0bGluZSBpbiB0aGUN Cg0K4oCcc21hbGwgZ3JvdXDigJ0gYmVmb3JlIGJyaW5naW5nIHRoZSBwdWxsIHJlcXVlc3QgdG8g dGhlIFdHLg0KDQoNCg0KPiAgICAgICAgIDguMS4gIFNpZ25hbGluZyBDb2Rlcw0KDQo+DQoNCj4g ICAgICAgICAgICBFYWNoIGVudHJ5IGluIHRoZSBzdWItcmVnaXN0cnkgbXVzdCBpbmNsdWRlIHRo ZSBTaWduYWxpbmcgQ29kZSBpbiB0aGUNCg0KPiAgICAgICAgICAgIHJhbmdlIDcuMDEtNy4zMSwg aXRzIG5hbWUsIGFuZCBhIHJlZmVyZW5jZSB0byBpdHMgZG9jdW1lbnRhdGlvbi4NCg0KPiBJcyA3 LjAwIHJlc2VydmVkPw0KDQoNCg0KR29vZCBjYXRjaC4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUt d2cvY29hcC10Y3AtdGxzL2lzc3Vlcy85MA0KDQoNCg0KPiAgICAgICAgIDguMi4gIENvQVAgU2ln bmFsaW5nIE9wdGlvbiBOdW1iZXJzIFJlZ2lzdHJ5DQoNCj4NCg0KPiAgICAgICAgICAgIElBTkEg aXMgcmVxdWVzdGVkIHRvIGNyZWF0ZSBhIHN1Yi1yZWdpc3RyeSBmb3Igc2lnbmFsaW5nIG9wdGlv bnMNCg0KPiAgICAgICAgICAgIHNpbWlsYXIgdG8gdGhlIENvQVAgT3B0aW9uIE51bWJlcnMgUmVn aXN0cnkgKFNlY3Rpb24gMTIuMiBvZg0KDQo+ICAgICAgICAgICAgW1JGQzcyNTJdKSwgd2l0aCB0 aGUgc2luZ2xlIGNoYW5nZSB0aGF0IGEgZm91cnRoIGNvbHVtbiBpcyBhZGRlZCB0bw0KDQo+ICAg ICAgICAgICAgdGhlIHN1Yi1yZWdpc3RyeSB0aGF0IGlzIG9uZSBvZiB0aGUgY29kZXMgaW4gdGhl IFNpZ25hbGluZyBDb2Rlcw0KDQo+ICAgICAgICAgICAgc3VicmVnaXN0cnkgKFNlY3Rpb24gOC4x KS4NCg0KPg0KDQo+IHMvb25lL29uZSBvciBtb3JlLw0KDQoNCg0KQWRkZWQgdG8gaHR0cHM6Ly9n aXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy83Ng0KDQoNCg0KPiAgICAgICAg IDguNS4gIFVSSSBTY2hlbWUgUmVnaXN0cmF0aW9uDQoNCj4NCg0KPiBUaGlzIHNlY3Rpb24gbmVl ZHMgdG8gZ2V0IHN5bW1ldHJpYyBiZXR3ZWVuIHRoZSBmb3VyIFVSSSBzY2hlbWVzIGRlZmluZWQu DQoNCg0KDQo+ICAgICAgICAgICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYWRkIHRoZXNlIG5ldyBV Ukkgc2NoZW1lcyB0byB0aGUgcmVnaXN0cnkNCg0KPiAgICAgICAgICAgIGVzdGFibGlzaGVkIHdp dGggW1JGQzc1OTVdLg0KDQoNCg0KPiBXZSBuZWVkIHRvIGZpbGwgaW4gdGhlIHRlbXBsYXRlLiAg U2VlIGFib3ZlIGNvbW1lbnQuDQoNCg0KDQpBZGRlZCB0byBodHRwczovL2dpdGh1Yi5jb20vY29y ZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzc4DQoNCg0KDQo+ICAgICAgICAgOC41LjEuICBjb2Fw K3dzDQoNCj4NCg0KPiAgICAgICAgICAgIFVSSSBzY2hlbWUgc3ludGF4Lg0KDQo+ICAgICAgICAg ICAgICBEZWZpbmVkIGluIFNlY3Rpb24gTiBvZiBbUkZDdGhpc10NCg0KPg0KDQo+IHMvTi82LjIv DQoNCg0KDQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzkx DQoNCg0KDQo+ICAgICAgICAgICAgVVJJIHNjaGVtZSBzZW1hbnRpY3MuDQoNCj4gICAgICAgICAg ICAgICBUaGUgImNvYXArd3MiIFVSSSBzY2hlbWUgcHJvdmlkZXMgYSB3YXkgdG8gaWRlbnRpZnkg cmVzb3VyY2VzIHRoYXQNCg0KPiAgICAgICAgICAgICAgIGFyZSBwb3RlbnRpYWxseSBhY2Nlc3Np YmxlIG92ZXIgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uDQoNCj4gICAgICAgICAgICAgICBQ cm90b2NvbCAoQ29BUCkgdXNpbmcgdGhlIFdlYlNvY2tldCBwcm90b2NvbC4NCg0KDQoNCj4gcy9h cmUgcG90ZW50aWFsbHkgYWNjZXNzaWJsZS9hcmUgaW50ZW5kZWQgdG8gYmUgYWNjZXNzaWJsZS8N Cg0KDQoNCkFkZGVkIHRvIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9p c3N1ZXMvNzggLSB3aXRoIGEgbm90ZQ0KDQp0aGF0IHNpbWlsYXIgbGFuZ3VhZ2UgZXhpc3RzIGZv ciBjb2FwK3dzcy4NCg0KDQoNCj4gICAgICAgICAgICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4N Cg0KPiAgICAgICAgICAgICAgIFNlZSBTZWN0aW9uIE4gb2YgW1JGQ3RoaXNdDQoNCj4NCg0KPiBz L04vNy8NCg0KDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1 ZXMvOTENCg0KDQoNCj4gICAgICAgICA4LjUuMi4gIGNvYXArd3NzDQoNCj4gICAgICAgICAgICBV Ukkgc2NoZW1lIHN5bnRheC4NCg0KPiAgICAgICAgICAgICAgIERlZmluZWQgaW4gU2VjdGlvbiBO IG9mIFtSRkN0aGlzXQ0KDQo+IHMvTi82LjIvDQoNCg0KDQpodHRwczovL2dpdGh1Yi5jb20vY29y ZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzkxDQoNCg0KDQo+ICAgICAgICAgICAgVVJJIHNjaGVt ZSBzZW1hbnRpY3MuDQoNCj4gICAgICAgICAgICAgICBUaGUgImNvYXArd3MiIFVSSSBzY2hlbWUg cHJvdmlkZXMgYSB3YXkgdG8gaWRlbnRpZnkgcmVzb3VyY2VzIHRoYXQNCg0KPiAgICAgICAgICAg ICAgIGFyZSBwb3RlbnRpYWxseSBhY2Nlc3NpYmxlIG92ZXIgdGhlIENvbnN0cmFpbmVkIEFwcGxp Y2F0aW9uDQoNCj4gICAgICAgICAgICAgICBQcm90b2NvbCAoQ29BUCkgdXNpbmcgdGhlIFdlYlNv Y2tldCBwcm90b2NvbCBzZWN1cmVkIHdpdGgNCg0KPiAgICAgICAgICAgICAgIFRyYW5zcG9ydCBM YXllciBTZWN1cml0eSAoVExTKS4NCg0KDQoNCj4gcy9jb2FwK3dzL2NvYXBzK3dzLw0KDQoNCg0K U2VlIGJpa2VzaGVkIGNvbW1lbnQgYWJvdmUuDQoNCg0KDQoNCg0KPiAgICAgICAgICAgIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zLg0KDQo+ICAgICAgICAgICAgICAgU2VlIFNlY3Rpb24gTiBvZiBb UkZDdGhpc10NCg0KPiBzL04vNy8NCg0KDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2Nv YXAtdGNwLXRscy9pc3N1ZXMvOTENCg0KDQoNCj4gICAgICAgICBBcHBlbmRpeCBBLiAgVXBkYXRl cyB0byBSRkM3NjQxIE9ic2VydmluZyBSZXNvdXJjZXMgaW4gdGhlIENvbnN0cmFpbmVkDQoNCj4g ICAgICAgICAgICAgICAgICAgICAgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApDQoNCg0KDQo+ IFRoaXMgbmVlZHMgdG8gYmUgcmVmZXJlbmNlZCBmcm9tIHRoZSBtYWluIGJvZHkgaW4gc29tZSBm b3JtLg0KDQoNCg0KQWRkZWQgdG8gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3At dGxzL2lzc3Vlcy84Mw0KDQoNCg0KPiAgICAgICAgIEFwcGVuZGl4IEIuICBOZWdvdGlhdGluZyBQ cm90b2NvbCBWZXJzaW9ucw0KDQo+ICAgICAgICAgICAgSW4gY29udHJhc3QgdG8gdGhlIG1lc3Nh Z2UgbGF5ZXIgZm9yIFVEUCBhbmQgRFRMUywgdGhlIENvQVAgb3ZlciBUQ1ANCg0KPiAgICAgICAg ICAgIG1lc3NhZ2UgZm9ybWF0IGRvZXMgbm90IGluY2x1ZGUgYSB2ZXJzaW9uIG51bWJlci4gIElm IHZlcnNpb24NCg0KPiAgICAgICAgICAgIG5lZ290aWF0aW9uIG5lZWRzIHRvIGJlIGFkZHJlc3Nl ZCBpbiB0aGUgZnV0dXJlLCB0aGVuIENhcGFiaWxpdHkgYW5kDQoNCj4gICAgICAgICAgICBTZXR0 aW5ncyBoYXZlIGJlZW4gc3BlY2lmaWNhbGx5IGRlc2lnbmVkIHRvIGVuYWJsZSBzdWNoIGEgcG90 ZW50aWFsDQoNCj4gICAgICAgICAgICBmZWF0dXJlLg0KDQoNCg0KPiBzL0NhcGFiaWxpdHkgYW5k IFNldHRpbmdzL0NhcGFiaWxpdGllcyBhbmQgU2V0dGluZ3MgTWVzc2FnZXMgKENTTSkvDQoNCg0K DQpBZGRlZCB0byBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVz Lzg5DQoNCg0KDQo= --_000_CY1PR03MB2380868D3621B914EB751D5283900CY1PR03MB2380namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIGZvciB0aGUgZmVl ZGJhY2ssIENhcnN0ZW4uIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuJm5ic3A7IEludHJv ZHVjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBbLi4uXSBBbHRob3VnaCBIVFRQLzI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY291bGQgYWxzbyBwb3RlbnRpYWxseSBhZGRyZXNzIHRo ZXNlIHJlcXVpcmVtZW50cywgdGhlcmUgd291bGQgYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRkaXRpb25hbCBjb3N0cyBhbmQgZGVsYXlz IGludHJvZHVjZWQgYnkgc3VjaCBhIHRyYW5zaXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEN1cnJlbnRseSwgdGhlcmUgYXJlIGFsc28g ZmV3ZXIgSFRUUC8yIGltcGxlbWVudGF0aW9ucyBhdmFpbGFibGUgZm9yPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnN0cmFpbmVkIGRldmlj ZXMgaW4gY29tcGFyaXNvbiB0byBDb0FQLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IFRoZXNlIHNlbnRlbmNlcyBhcmUgbGFtZTsgSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHdo eSB0aGV5IGFyZSBuZWVkZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IFRoZSBtYWluIHBvaW50IGhlcmUgaXMgdGhhdCBIVFRQLzIgaXMgYSBjb21wbGV4aXR5 IGZlc3QgY29tcGFyZWQgdG8gQ29BUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgQWxzbywgSFRUUC8yIGhhcyBub3QgeWV0IGJlZW4gZXh0ZW5kZWQgYnkgaW1w b3J0YW50IGNvbmNlcHRzIHN1Y2ggYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgT2JzZXJ2ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGNv bnRleHQgaXMgaW4gaW4gPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10 Y3AtdGxzL2lzc3Vlcy81MCI+DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10 bHMvaXNzdWVzLzUwPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBEYXZlIFRoYWxlciBhbmQgeW91IHJldmlld2VkIGR1 cmluZyBJRVRGIDk3Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J IGhhdmUgbm8gcGxhbnMgdG8gcmUtb3BlbiBhdCB0aGlzIHRpbWUuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWy4uLl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gYWRkaXRpb24sIHNvbWUgY29ycG9yYXRlIG5ldHdv cmtzIG9ubHkgYWxsb3cgSW50ZXJuZXQgYWNjZXNzIHZpYSBhPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhUVFAgcHJveHkuJm5ic3A7IEluIHRoaXMgY2Fz ZSwgdGhlIGJlc3QgdHJhbnNwb3J0IGZvciBDb0FQIHdvdWxkIGJlIHRoZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXZWJTb2NrZXQgUHJvdG9jb2wgW1JG QzY0NTVdLiZuYnNwOyBUaGUgV2ViU29ja2V0IHByb3RvY29sIHByb3ZpZGVzIHR3by08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBXZWxsLCBhbiBIVFRQIHByb3h5IHdvbid0IG5l Y2Vzc2FyaWx5IGFsbG93IFdlYlNvY2tldHMgdGhyb3VnaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+RG8geW91IGhhdmUgYSBzdWdnZXN0aW9uPyBQZXJoYXBzIOKAnG1pZ2h0IGJl4oCd IHJhdGhlciB0aGFuIOKAnHdvdWxkIGJl4oCdPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOzEuMS4mbmJz cDsgVGVybWlub2xvZ3k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Wy4uLl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1 bWVudCBhc3N1bWVzIHRoYXQgcmVhZGVycyBhcmUgZmFtaWxpYXIgd2l0aCB0aGUgdGVybXMgYW5k PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmNlcHRz IHRoYXQgYXJlIHVzZWQgaW4gW1JGQzY0NTVdLCBbUkZDNzI1Ml0sIGFuZCBbUkZDNzY0MV0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYW5kIFJGQyA3OTU5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9j b2FwLXRjcC10bHMvaXNzdWVzLzg0Ij5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRj cC10bHMvaXNzdWVzLzg0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZSB0ZXJtICZxdW90O3JlbGlhYmxlIHRyYW5zcG9ydCZxdW90OyBvbmx5IHJlZmVycyB0byBz dHJlYW0tYmFzZWQgdHJhbnNwb3J0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHByb3RvY29scyBzdWNoIGFzIFRDUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDtzL29ubHkgcmVmZXJzL2lzIHVzZWQgb25seSB0byByZWZlci88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsoV2UgY291bGQgc2F5IG1vcmUgZXhw bGljaXRseTogc2VxdWVuY2VkL29yZGVyLXByZXNlcnZpbmcsIHJlbGlhYmxlLi4uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7U3RyZWFtIG1pZ2h0IGJlIGJ5dGUg c3RyZWFtIG9yIG1lc3NhZ2Ugc3RyZWFtLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy80 OSI+aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy80OTwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDIuMS4mbmJzcDsgTWVzc2FnaW5nIE1vZGVsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb25jZXB0dWFsbHksIENvQVAgb3ZlciBUQ1Ag cmVwbGFjZXMgbW9zdCBvZiB0aGUgQ29BUCBvdmVyIFVEUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZXNzYWdlIGxheWVyIHdpdGggYSBmcmFt aW5nIG1lY2hhbmlzbSBvbiB0b3Agb2YgdGhlIGJ5dGUgc3RyZWFtPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3ZpZGVkIGJ5IFRDUC9UTFMs IGNvbnZleWluZyB0aGUgbGVuZ3RoIGluZm9ybWF0aW9uIGZvciBlYWNoPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UgdGhhdCBvbiBk YXRhZ3JhbSB0cmFuc3BvcnRzIGlzIHByb3ZpZGVkIGJ5IHRoZSBVRFAvRFRMUzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkYXRhZ3JhbSBsYXll ci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzL0NvQVAgb3ZlciBVRFAgbWVz c2FnZSBsYXllci9tZXNzYWdlIGxheWVyIG9mIENvQVAgb3ZlciBVRFAvPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAt dGNwLXRscy9pc3N1ZXMvODUiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRs cy9pc3N1ZXMvODU8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDI6IENvbXBhcmlzb24gYmV0d2VlbiBDb0FQIG92 ZXIgdW5yZWxpYWJsZSBhbmQgcmVsaWFibGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhbnNwb3J0LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IENhcHRpb25zIGFyZSBub3Qgc2VudGVuY2VzIGFuZCB0aGVyZWZvcmUg ZG9uJ3QgZW5kIGluIHBlcmlvZHMgKHNlZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBGaWd1cmUgMSkuIChDb21tZW50IG5vdCByZXBlYXRlZCBmdXJ0aGVyIGRv d24uKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzg2Ij5odHRwczovL2dpdGh1Yi5jb20v Y29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzg2PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDIuMy4mbmJzcDsgT3BlbmluZyBIYW5kc2hha2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFsuLi5dPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENsaWVudHMgYW5kIHNlcnZlcnMgTVVTVCB0cmVhdCBhIG1pc3Npbmcg b3IgaW52YWxpZCBDU00gYXMgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0aW9uIGVycm9yIGFuZCBhYm9ydCB0aGUgY29ubmVjdGlv biAoc2VlIFNlY3Rpb24gNC42KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRo aXMgaXMgcHJvYmFibHkgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLCBidXQgaXQgZG9lcyBtZWFuIHRo YXQgd2UgYXJlIG5vdzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBpbmNvbXBhdGlibGUgYWdhaW4gd2l0aCB0aGUgT0NGIDEuMCB2ZXJzaW9uIG9mIENvQVAgb3Zl ciBUQ1AuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFdlIGNv dWxkIGRlZmluZSBhbiBPQ0YgMS4wIGNvbXBhdGliaWxpdHkgbW9kZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhlIHF1ZXN0aW9uIGFib3V0IE9DRiBmZWVkYmFjayB3YXMgZGlzY3Vz c2VkIGF0IElFVEYgOTcuIE15IGV4cGVjdGF0aW9uIGlzIHRoYXQgT0NGPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5tZW1iZXJzIHdpbGwgZGlyZWN0bHkgYnJpbmcgaXNz dWVzIHRvIHRoZSBXRy4gSW4gYWRkaXRpb24sIGlmIHRoZXJlIHdhcyBhIGNvbXBhdGliaWxpdHkg bW9kZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPml0IHdvdWxkIGJl IGluIHRoZSBmcmFtZXdvcmsgcmF0aGVyIHRoYW4gdGhlIHByb3RvY29sIGRyYWZ0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuNC4mbmJzcDsgTWVzc2FnZSBGb3JtYXQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsuLi5dPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEluIGEgc3RyZWFtIG9yaWVudGVkIHRyYW5zcG9ydCBw cm90b2NvbCBzdWNoIGFzIFRDUCwgYSBmb3JtIG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgcy9zdHJlYW0vYnl0ZSBzdHJlYW0vPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IChXZSBwcm9iYWJseSBzaG91bGQgcmV2aWV3IHRoZSBlbnRpcmUg dGVybWlub2xvZ3kgYWJvdXQgJnF1b3Q7cmVsaWFibGUmcXVvdDssPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHNlcXVlbmNlLXByZXNlcnZpbmcsIGJ5dGUvbWVz c2FnZSBzdHJlYW1zIG9uY2UgbW9yZS4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxh IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvNDki Pmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvNDk8L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDswIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fExlbj0xMyB8Jm5ic3A7IFRLTCZuYnNwOyB8RXh0ZW5kZWQgTGVuZ3RofCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb2RlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgVEtM IGJ5dGVzIC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7IE9wdGlvbnMgKGlmIGFueSkg Li4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wxIDEgMSAxIDEgMSAxIDF8Jm5ic3A7Jm5ic3A7Jm5i c3A7IFBheWxvYWQgKGlmIGFueSkgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUgNDogQ29BUCBmcmFtZSB3aXRoIDgtYml0IEV4dGVu ZGVkIExlbmd0aCBmaWVsZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGlz IChhbmQgbmVpdGhlciBkb2VzIHRoZSB0ZXh0KSBkb2VzIG5vdCBtYWtlIGNsZWFyIHRoYXQgdGhl IHBheWxvYWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbWFy a2VyIGlzIHNlbnQgb25seSBpZiB0aGVyZSBpcyBhIG5vbi16ZXJvLWxlbmd0aCBwYXlsb2FkLiZu YnNwOyAoU2FtZSBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgb3RoZXIgYmVsb3cuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFBsZWFz ZSBjZi4gdGV4dCBmcm9tIFNlY3Rpb24gMyBvZiBSRkMgNzI1Mjo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDtGb2xsb3dpbmcgdGhlIGhlYWRlciwg dG9rZW4sIGFuZCBvcHRpb25zLCBpZiBhbnksIGNvbWVzIHRoZSBvcHRpb25hbDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDtwYXls b2FkLiZuYnNwOyBJZiBwcmVzZW50IGFuZCBvZiBub24temVybyBsZW5ndGgsIGl0IGlzIHByZWZp eGVkIGJ5IGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Zml4ZWQsIG9uZS1ieXRlIFBheWxvYWQgTWFya2VyICgweEZGKSwgd2hp Y2ggaW5kaWNhdGVzIHRoZSBlbmQgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7b3B0aW9ucyBhbmQgdGhlIHN0YXJ0IG9mIHRo ZSBwYXlsb2FkLiZuYnNwOyBUaGUgcGF5bG9hZCBkYXRhIGV4dGVuZHMgZnJvbTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDthZnRl ciB0aGUgbWFya2VyIHRvIHRoZSBlbmQgb2YgdGhlIFVEUCBkYXRhZ3JhbSwgaS5lLiwgdGhlIFBh eWxvYWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7TGVuZ3RoIGlzIGNhbGN1bGF0ZWQgZnJvbSB0aGUgZGF0YWdyYW0gc2l6ZS4m bmJzcDsgVGhlIGFic2VuY2Ugb2YgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwO1BheWxvYWQgTWFya2VyIGRlbm90ZXMgYSB6 ZXJvLWxlbmd0aCBwYXlsb2FkLiZuYnNwOyBUaGUgcHJlc2VuY2Ugb2YgYTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDttYXJrZXIg Zm9sbG93ZWQgYnkgYSB6ZXJvLWxlbmd0aCBwYXlsb2FkIE1VU1QgYmUgcHJvY2Vzc2VkIGFzIGE8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7bWVzc2FnZSBmb3JtYXQgZXJyb3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMv ODciPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvODc8L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7My4mbmJzcDsgQ29BUCBvdmVyIFdlYlNvY2tldHM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VW5sZXNzIG90aGVyd2lzZSBub3RlZCBiZWxv dywgdGhlIGZlZWRiYWNrIGZvciBTZWN0aW9uIDMgaXMgY2FwdHVyZWQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmluIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9j b3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvODgiPg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUt d2cvY29hcC10Y3AtdGxzL2lzc3Vlcy84ODwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1suLi5dPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIbW0sIHdoeSBp cyB0aGUgZm9sbG93aW5nIGRvbmUgaGVyZSBmb3IgV1MgYW5kIG5vdCBhYm92ZSBmb3IgVENQPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZWVtcyByZWR1bmRh bnQgd2l0aCA2LjI/Jm5ic3A7IE9oLCB0aGUgcG9pbnQgaGVyZSBpcyB0byBkZXJpdmUgdGhlIHdz W3NdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFVSSSB1c2Vk IGZvciBzZXR0aW5nIHVwIHRoZSBXUz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO1NlY3Rpb24gNi4yIGRlZmluZXMgYSBuZXcgJnF1b3Q7Y29hcCYjNDM7d3MmcXVv dDsgVVJJIHNjaGVtZSB0aGF0IGlkZW50aWZpZXMgYm90aCBhPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1dlYlNvY2tldCBlbmRwb2ludCBhbmQg YSByZXNvdXJjZSB3aXRoaW4gdGhhdCBlbmRwb2ludCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29hcCYjNDM7d3M6Ly9leGFtcGxlLm9y Zy9zZW5zb3JzL3RlbXBlcmF0dXJlP3U9Q2VsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1xfX19fX18mbmJzcDsgX19fX19fL1xfX19fX19fX19fXyZuYnNwOyBfX19fX19fX19fXy88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7XC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgXC88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VXJpLVBhdGg6ICZxdW90O3NlbnNvcnMmcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d3M6Ly9leGFtcGxlLm9yZy8ud2VsbC1rbm93bi9jb2FwJm5i c3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDt0ZW1wZXJhdHVyZSZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtVcmktUXVlcnk6ICZxdW90O3U9Q2VsJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtGaWd1cmUgMTA6IFRoZSAmcXVvdDtjb2FwJiM0Mzt3cyZxdW90OyBVUkkgU2No ZW1lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JdCBhcHBlYXJzIHRoYXQgeW91IGFuc3dlcmVkIHlvdXIg b3duIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZSBmb2xs b3dpbmcgbm93IHNlZW1zIHVucmVsYXRlZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7QW5vdGhlciBwb3NzaWJsZSBjb25maWd1cmF0aW9uIGlzIHRvIHNl dCB1cCBhIENvQVAgZm9yd2FyZCBwcm94eSBhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgV2ViU29ja2V0IGVuZHBvaW50LiZuYnNwOyBE ZXBlbmRpbmcgb24gd2hhdCB0cmFuc3BvcnRzIGFyZSBhdmFpbGFibGU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Wy4uLl08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDEy OiBDb0FQIENsaWVudCAoVURQIGNsaWVudCkgYWNjZXNzZXMgc2xlZXB5IENvQVAgU2VydmVyPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyhXZWJTb2NrZXQgY2xpZW50KSB2aWEgYSBDb0FQIHByb3h5IChVRFAgc2VydmVyL1dlYlNvY2tl dCBzZXJ2ZXIpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzL3NsZWVweS8vPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IChUaGVyZSBpcyBubyBt ZW50aW9uIG9mIHNsZWVwaW5lc3MgaGVyZS4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtbLi4uXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Q29BUCBvdmVyIFdlYlNvY2tldHMgaXMgaW50ZW50aW9uYWxseSB2ZXJ5IHNpbWlsYXIg dG8gQ29BUCBvdmVyIFVEUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7VGhlcmVmb3JlLCBpbnN0ZWFkIG9mIHByZXNlbnRpbmcgQ29BUCBvdmVy IFdlYlNvY2tldHMgYXMgYSBuZXc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdG9jb2wsIHRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGl0IGFz IGEgc2VyaWVzIG9mIGRlbHRhcyBmcm9tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tSRkM3MjUyXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IFByb2JhYmx5IGJlc3QgdG8gZGVsZXRlIHRoYXQgcGFyYWdyYXBoIC0tIGl0IGlz IHRydWUgbm90IG9ubHkgZm9yIFdTLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBidXQgYWxzbyBmb3IgVENQLiZuYnNwOyBTbyB3aHkgb25seSBoZXJlPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7My4xLiAmbmJzcDtPcGVuaW5nIEhhbmRzaGFrZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSG1tLCB0aGUgdGl0bGUgaXMgY29uZnVzaW5nLiZu YnNwOyBXUyBhbHNvIHVzZXMgdGhlIHNhbWUgb3BlbmluZyBoYW5kc2hha2UgYXMgMi4zLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgcGFydHMgdGhhdCBy ZWxhdGUgdG8gYm90aCBUQ1AvVExTIGFuZCBXUy9TIG5lZWQgdG8gYmUgZmFjdG9yZWQgb3V0Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzMuMi4mbmJzcDsgTWVzc2FnZSBGb3JtYXQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1suLi5dPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtUaGUgbWVzc2FnZSBmb3JtYXQgc2hvd24gaW4gRmlndXJlIDE0IGlz IHRoZSBzYW1lIGFzIHRoZSBDb0FQIG92ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VENQIG1lc3NhZ2UgZm9ybWF0IChzZWUgU2VjdGlvbiAy LjQpIHdpdGggb25lIHJlc3RyaWN0aW9uLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TGVuZ3RoIChMZW4pIGZpZWxkIE1VU1Qg YmUgc2V0IHRvIHplcm8gYmVjYXVzZSB0aGUgV2ViU29ja2V0cyBmcmFtZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbHJlYWR5IGNvbnRhaW5z IHRoZSBsZW5ndGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzL3Jlc3RyaWN0 aW9uL2NoYW5nZS8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtb Li4uXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDswIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyBMZW4gfCZuYnNwOyBUS0wmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb2RlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsgVG9rZW4gKFRLTCBieXRlcykgLi4uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsgT3B0aW9ucyAoaWYgYW55 KSAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDEgMSAx IDEgMSAxIDEgMXwmbmJzcDsmbmJzcDsmbmJzcDsgUGF5bG9hZCAoaWYgYW55KSAuLi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ZpZ3VyZSAxNDogQ29BUCBNZXNzYWdlIEZvcm1hdCBv dmVyIFdlYlNvY2tldHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE1heWJlIHNo b3cgMCwgbm90IExlbiBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAoVGhpcyBhbHNvIGRvZXMgbm90IG1ha2UgY2xlYXIgdGhhdCB0aGUgcGF5bG9hZCBt YXJrZXIgaXMgc2VudCBvbmx5IGlmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IHRoZXJlIGlzIGEgbm9uLXplcm8tbGVuZ3RoIHBheWxvYWQuKTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+QWRkZWQgdG8gPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29h cC10Y3AtdGxzL2lzc3Vlcy84NyI+DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRj cC10bHMvaXNzdWVzLzg3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1RoZSBDb0FQIG92ZXIgVENQIG1lc3NhZ2UgZm9ybWF0IGVsaW1pbmF0ZXMgdGhlIFZl cnNpb24gZmllbGQgZGVmaW5lZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtpbiBDb0FQIG92ZXIgVURQLiZuYnNwOyBJZiBDb0FQIHZlcnNpb24g bmVnb3RpYXRpb24gaXMgcmVxdWlyZWQgaW4gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Z1dHVyZSwgQ29BUCBvdmVyIFdlYlNvY2tldHMg Y2FuIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50IGJ5IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtkZWZpbml0aW9uIG9mIGEgbmV3IHN1YnByb3RvY29s IGlkZW50aWZpZXIgdGhhdCBpcyBuZWdvdGlhdGVkIGR1cmluZzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgb3BlbmluZyBoYW5kc2hha2UuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGlzIHBhcmFncmFwaCBpcyBhIGJpdCB3ZWly ZC4mbmJzcDsgTWF5YmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsm bmJzcDsmbmJzcDtBcyB3aXRoIENvQVAgb3ZlciBUQ1AsIHRoZSBtZXNzYWdlIGZvcm1hdCBmb3Ig Q29BUCBvdmVyIFdlYnNvY2tldHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ZWxpbWluYXRlcyB0aGUgVmVyc2lvbiBmaWVsZCBk ZWZpbmVkIGluIENvQVAgb3ZlciBVRFAuJm5ic3A7IElmIENvQVAgWy4uLl08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1suLi5dPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtFbXB0eSBtZXNzYWdlcyAoQ29kZSAwLjAwKSBNVVNUIGJl IGlnbm9yZWQgYnkgdGhlIHJlY2lwaWVudCAoc2VlIGFsc288bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2VjdGlvbiA0LjQpLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgV2h5IGFyZSB3ZSBzYXlpbmcgdGhpcyBoZXJlIGFuZCBu b3QgaW4gU2VjdGlvbiAyPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBGYWN0b3Igb3V0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7My4zLiZuYnNwOyBNZXNz YWdlIFRyYW5zbWlzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Wy4uLl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNpbWlsYXIgYXMgd2l0 aCBDb0FQIG92ZXIgVENQLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtSZXRyYW5zbWlzc2lvbiBhbmQgZGVkdXBsaWNhdGlvbiBvZiBtZXNzYWdl cyBpcyBwcm92aWRlZCBieSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7V2ViU29ja2V0IHByb3RvY29sLiZuYnNwOyBDb0FQIG92ZXIgV2Vi U29ja2V0cyB0aGVyZWZvcmUgZG9lcyBub3QgbWFrZSBhPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rpc3RpbmN0aW9uIGJldHdlZW4gQ29uZmly bWFibGUgb3IgTm9uLUNvbmZpcm1hYmxlIG1lc3NhZ2VzLCBhbmQgZG9lczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtub3QgcHJvdmlkZSBBY2tu b3dsZWRnZW1lbnQgb3IgUmVzZXQgbWVzc2FnZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsz LjQuJm5ic3A7IENvbm5lY3Rpb24gSGVhbHRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtbLi4uXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtUaGVyZSBpcyBubyB3YXkgdG8gcmV0cmFuc21pdCBhIHJlcXVlc3Qgd2l0aG91 dCBjcmVhdGluZyBhIG5ldyBvbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO1JlLXJlZ2lzdGVyaW5nIGludGVyZXN0IGluIGEgcmVzb3VyY2Ug aXMgcGVybWl0dGVkLCBidXQgZW50aXJlbHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dW5uZWNlc3NhcnkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAoU2VlIHRoZSBkaXNjdXNzaW9uIHdlIGFscmVhZHkgaGFkLik8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGRpc2N1c3Npb24gaXMgaW4gPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy83MSI+DQpodHRwczov L2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzcxPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzQuJm5ic3A7IFNpZ25hbGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5Vbmxlc3Mgb3RoZXJ3aXNlIG5vdGVkIGJlbG93LCB0aGUgZmVlZGJhY2sgZm9yIFNl Y3Rpb24gNCBpcyBjYXB0dXJlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+aW4gPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lz c3Vlcy84OSI+DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVz Lzg5PC9hPi4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2ln bmFsaW5nIG1lc3NhZ2VzIGFyZSBpbnRyb2R1Y2VkIHRvIGFsbG93IHBlZXJzIHRvOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyBTaGFyZSBjaGFyYWN0 ZXJpc3RpY3Mgc3VjaCBhcyBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZSBmb3IgdGhlIGNvbm5lY3Rpb248 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHMvU2hhcmUvUmVsYXRlLzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAodGhlIG5vZGVzIGRvIG5vdCAm cXVvdDtzaGFyZSB0aGVzZSBjaGFyYWN0ZXJpc3RpY3MmcXVvdDspPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7IFNodXRkb3duIHRoZSBjb25uZWN0aW9u IGluIGFuIG9yZGVyZWQgZmFzaGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg U2h1dCBkb3duPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHMv T3JkZXJlZC9PcmRlcmx5LzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7byZuYnNwOyBUZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24gaW4gcmVzcG9uc2UgdG8gYSBzZXJp b3VzIGVycm9yIGNvbmRpdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUHJv dmlkZSBkaWFnbm9zdGljIGluZm9ybWF0aW9uIHdoZW4gdGVybWluYXRpbmcgYSBjb25uZWN0aW9u IGluIC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzQuMy4mbmJzcDsgQ2FwYWJpbGl0eSBhbmQgU2V0dGluZ3Mg TWVzc2FnZXMgKENTTSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEhtbSwgc2hv dWxkIHRoaXMgYmUgJnF1b3Q7Q2FwYWJpbGl0aWVzIGFuZCBTZXR0aW5ncyBNZXNzYWdlcyZxdW90 Oz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgKE5lZWQgdG8g Y2hhbmdlIHRocm91Z2hvdXQuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Q2FwYWJpbGl0eSBhbmQgU2V0dGluZ3MgbWVzc2FnZXMgKENTTSkgYXJlIHVzZWQgZm9y IHR3byBwdXJwb3Nlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O28mbmJzcDsgRWFjaCBjYXBhYmlsaXR5IG9wdGlvbiBhZHZlcnRpc2VzIG9uZSBjYXBhYmlsaXR5 IG9mIHRoZSBzZW5kZXIgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIHJlY2lwaWVudC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJzcDsgU2V0dGluZyBvcHRpb25z IGluZGljYXRlIGEgc2V0dGluZyB0aGF0IHdpbGwgYmUgYXBwbGllZCBieSB0aGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7c2VuZGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcy9BL09uZS88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcy9DYXBhYmlsaXR5 IGFuZCBTZXR0aW5ncyBtZXNzYWdlL0NTTS88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QSBDYXBhYmlsaXR5IGFuZCBTZXR0aW5ncyBtZXNzYWdl IE1VU1QgYmUgc2VudCBieSBib3RoIGVuZHBvaW50cyBhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgc3RhcnQgb2YgdGhlIGNvbm5lY3Rpb24gYW5k IE1BWSBiZSBzZW50IGF0IGFueSBvdGhlciB0aW1lIGJ5PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHMvYW5kLy4gRnVydGhlciBDU00vPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VpdGhlciBlbmRwb2ludCBv dmVyIHRoZSBsaWZldGltZSBvZiB0aGUgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0JvdGggY2FwYWJpbGl0eSBhbmQgc2V0dGluZ3Mgb3B0aW9u cyBhcmUgY3VtdWxhdGl2ZS4mbmJzcDsgQSBDYXBhYmlsaXR5PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHMvc2V0dGluZ3Mvc2V0dGluZy88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIFNldHRpbmdzIG1l c3NhZ2UgZG9lcyBub3QgaW52YWxpZGF0ZSBhIHByZXZpb3VzbHkgc2VudCBjYXBhYmlsaXR5PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2luZGlj YXRpb24gb3Igc2V0dGluZyBldmVuIGlmIGl0IGlzIG5vdCByZXBlYXRlZC4mbmJzcDsgQSBjYXBh YmlsaXR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO21lc3NhZ2Ugd2l0aG91dCBhbnkgb3B0aW9uIGlzIGEgbm8tb3BlcmF0aW9uIChhbmQgY2Fu IGJlIHVzZWQgYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7c3VjaCkuJm5ic3A7IEFuIG9wdGlvbiB0aGF0IGlzIHNlbnQgbWlnaHQgb3ZlcnJp ZGUgYSBwcmV2aW91cyB2YWx1ZSBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuMy4xLiZuYnNwOyBT ZXJ2ZXItTmFtZSBTZXR0aW5nIE9wdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgWy4uLl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRm9yIFRMUywgdGhlIGluaXRpYWwgdmFsdWUgZm9yIHRoZSBTZXJ2ZXItTmFtZSBP cHRpb24gaXMgZ2l2ZW4gYnkgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNOSSB2YWx1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHMvaW5pdGlhbC9iYXNlLz8/PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U aGlzIGlzIGFscmVhZHkgYWRkcmVzc2VkIGluIG15IHBlbmRpbmcgcHVsbCByZXF1ZXN0IC0gPGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvNjcvY29t bWl0cy82ZWExMmE3MDBhZmU4ZWQ4ZDkwOTY5MWFmNGZjNDU2ZWJlZmI2MThlIj4NCmh0dHBzOi8v Z2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9wdWxsLzY3L2NvbW1pdHMvNmVhMTJhNzAw YWZlOGVkOGQ5MDk2OTFhZjRmYzQ1NmViZWZiNjE4ZTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs0LjMuMi4mbmJzcDsgTWF4LU1lc3NhZ2UtU2l6ZSBDYXBhYmlsaXR5IE9wdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXMgcGVyIFNlY3Rpb24gNC42 IG9mIFtSRkM3MjUyXSwgdGhlIGJhc2UgdmFsdWUgKGFuZCB0aGUgdmFsdWUgdXNlZDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3aGVuIHRoaXMg b3B0aW9uIGlzIG5vdCBpbXBsZW1lbnRlZCkgaXMgMTE1Mi4mbmJzcDsgQSBwZWVyIHRoYXQgcmVs aWVzIG9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3RoaXMgb3B0aW9uIGJlaW5nIGluZGljYXRlZCB3aXRoIGEgY2VydGFpbiBtaW5pbXVtIHZh bHVlIHdpbGwgZW5qb3k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7bGltaXRlZCBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgKGFib3ZlIDExNTI/KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDYuJm5ic3A7IENvQVAgVVJJczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5V bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkIGJlbG93LCB0aGUgZmVlZGJhY2sgZm9yIFNlY3Rpb24gNiBp cyBjYXB0dXJlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aW4gaHR0 cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy83NS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb0FQIG92ZXIgVURQIFtSRkM3MjUy XSBkZWZpbmVzIHRoZSAmcXVvdDtjb2FwJnF1b3Q7IGFuZCAmcXVvdDtjb2FwcyZxdW90OyBVUkkg c2NoZW1lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtmb3IgaWRlbnRpZnlpbmcgQ29BUCByZXNvdXJjZXMgYW5kIHByb3ZpZGluZyBhIG1lYW5z IG9mIGxvY2F0aW5nIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtyZXNvdXJjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBJbiB0aGlzIHNlY3Rpb24sIHRoZSB0ZXJtcyAmcXVvdDtjbGllbnQmcXVvdDsgYW5kICZxdW90 O3NlcnZlciZxdW90OyBhcmUgdXNlZCBXUlQgdGhlIFRDUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjb25uZWN0aW9uLCBub3QgV1JUIENvQVAsIGFuZCB0aGF0 IG1heSBiZSB2ZXJ5IGNvbmZ1c2luZy4mbmJzcDsgTWF5YmUgdXNlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRpZmZlcmVudCB0ZXJtcyBoZXJlIChpbml0aWF0 b3IvcmVzcG9uZGVyKT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs2LjEuJm5ic3A7IENvQVAg b3ZlciBUQ1AgYW5kIFRMUyBVUklzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtbUkZDNzI1Ml0sIFNlY3Rpb24gOCAoTXVsdGljYXN0IENvQVApIGlzIG5vdCBhcHBs aWNhYmxlIHRvIHRoZXNlIHNjaGVtZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBOb3Qgc3VyZSB0aGlzIGJlbG9uZ3MgaGVyZSwgYnV0IGl0IGFsc28gc2hvdWxkIGFwcGx5IHRv IDYuMiwgc28gbWF5YmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgbW92ZSBpdCB1cCB0byA2LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7UmVzb3VyY2VzIG1hZGUgYXZhaWxhYmxlIHZpYSBvbmUgb2YgdGhlICZxdW90O2NvYXAm IzQzO3RjcCZxdW90OyBvciAmcXVvdDtjb2FwcyYjNDM7dGNwJnF1b3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NjaGVtZXMgaGF2ZSBubyBz aGFyZWQgaWRlbnRpdHkgd2l0aCB0aGUgb3RoZXIgc2NoZW1lIG9yIHdpdGggdGhlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2NvYXAm cXVvdDsgb3IgJnF1b3Q7Y29hcHMmcXVvdDsgc2NoZW1lLCBldmVuIGlmIHRoZWlyIHJlc291cmNl IGlkZW50aWZpZXJzIGluZGljYXRlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBzYW1lIGF1dGhvcml0eSAodGhlIHNhbWUgaG9zdCBsaXN0 ZW5pbmcgdG8gdGhlIHNhbWUgcG9ydCkuJm5ic3A7IFRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzY2hlbWVzIGNvbnN0aXR1dGUgZGlzdGlu Y3QgbmFtZXNwYWNlcyBhbmQsIGluIGNvbWJpbmF0aW9uIHdpdGggdGhlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2F1dGhvcml0eSwgYXJlIGNv bnNpZGVyZWQgdG8gYmUgZGlzdGluY3Qgb3JpZ2luIHNlcnZlcnMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBEaXR0by48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNi4y LiAmbmJzcDtDb0FQIG92ZXIgV2ViU29ja2V0cyBVUklzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgdGhlIGZpcnN0IGNvbmZpZ3VyYXRpb24gZGlzY3Vzc2Vk IGluIFNlY3Rpb24gMywgdGhpcyBkb2N1bWVudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbmVzIHR3byBuZXcgVVJJcyBzY2hlbWVzIHRoYXQgY2Fu IGJlIHVzZWQgZm9yIGlkZW50aWZ5aW5nIENvQVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzb3VyY2VzIGFuZCBwcm92aWRpbmcgYSBtZWFucyBvZiBs b2NhdGluZyB0aGVzZSByZXNvdXJjZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2NvYXAmIzQzO3dzJnF1b3Q7IGFuZCAmcXVvdDtjb2FwJiM0 Mzt3c3MmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY29hcCYjNDM7 d3NzIGlzIHRoZSBvbmx5IGNvYXBzIHNjaGVtZSB0aGF0IGRvZXNuJ3QgaGF2ZSBjb2FwcyBpbiB0 aGUgbmFtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSSBj b250aW51ZSB0byBiZWxpZXZlIHRoYXQgdGhpcyBpcyBhIG1pc3Rha2UuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHMvY29hcCYjNDM7d3NzL2NvYXBzJiM0Mzt3 cy9nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIGlzIHRoZSBiaWtlc2hlZCAt IDxhIGhyZWY9Imh0dHA6Ly9iaWtlc2hlZC5jb20vIj5odHRwOi8vYmlrZXNoZWQuY29tLzwvYT4g LSB3aGljaCB3YXMgZGlzY3Vzc2VkIGF0IElFVEYgOTYgd2l0aCBubzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Y29uc2Vuc3VzIGFuZCByYWlzZWQgYWdhaW4gYXQgdGhl IGluZm9ybWFsIENvUkUgbWVldGluZyBhdCBJRVRGIDk3IHdpdGggbm8gb3BpbmlvbnM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmV4cHJlc3NlZCBmcm9tIHRoZSBwYXJ0 aWNpcGFudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk91ciBwcmVmZXJlbmNlcyBh cmUgYm90aCBub3RlZCBpbiAtIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2Nv YXAtdGNwLXRscy9pc3N1ZXMvMTIiPg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10 Y3AtdGxzL2lzc3Vlcy8xMjwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPknigJlk IGRlZmVyIHRvIHRoZSBjaGFpciBmb3IgY29hcC10Y3AtdGxzIChKYWltZSkgb24gaG93IGhl4oCZ ZCBsaWtlIHRvIHByb2NlZWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtTaW1pbGFyIHRvIHRoZSAmcXVvdDtjb2FwJnF1b3Q7IGFuZCAmcXVvdDtjb2FwcyZx dW90OyBzY2hlbWVzLCB0aGUgJnF1b3Q7Y29hcCYjNDM7d3MmcXVvdDsgYW5kPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2NvYXAmIzQz O3dzcyZxdW90OyBzY2hlbWVzIG9yZ2FuaXplIHJlc291cmNlcyBoaWVyYXJjaGljYWxseSB1bmRl ciBhIENvQVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7b3JpZ2luIHNlcnZlci4mbmJzcDsgVGhlIGtleSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhl IHNlcnZlciBpcyBwb3RlbnRpYWxseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtyZWFjaGFibGUgb24gYSBXZWJTb2NrZXQgZW5kcG9pbnQgaW5z dGVhZCBvZiBhIFVEUCBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IHMvcG90ZW50aWFsbHkgcmVhY2hhYmxlL2ludGVuZGVkIHRvIGJlIHJlYWNoZWQvPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgV2ViU29ja2V0IGVuZHBvaW50 IGlzIGlkZW50aWZpZWQgYnkgYSAmcXVvdDt3cyZxdW90OyBvciAmcXVvdDt3c3MmcXVvdDsgVVJJ IHRoYXQgaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y29tcG9zZWQgb2YgdGhlIGF1dGhvcml0eSBwYXJ0IG9mIHRoZSAmcXVvdDtjb2FwJiM0 Mzt3cyZxdW90OyBvciAmcXVvdDtjb2FwJiM0Mzt3c3MmcXVvdDsgVVJJLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXNwZWN0aXZlbHksIGFu ZCB0aGUgd2VsbC1rbm93biBwYXRoICZxdW90Oy8ud2VsbC1rbm93bi9jb2FwJnF1b3Q7IFtSRkM1 Nzg1XS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VGhlIHBhdGggYW5kIHF1ZXJ5IHBhcnRzIG9mIGEgJnF1b3Q7Y29hcCYjNDM7d3MmcXVvdDsg b3IgJnF1b3Q7Y29hcCYjNDM7d3NzJnF1b3Q7IFVSSSBpZGVudGlmeSBhPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Jlc291cmNlIHdpdGhpbiB0 aGUgc3BlY2lmaWVkIGVuZHBvaW50IHdoaWNoIGNhbiBiZSBvcGVyYXRlZCBvbiBieTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgbWV0aG9kcyBkZWZp bmVkIGJ5IENvQVAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgZm9sbG93 aW5nIHBhcmFncmFwaCBhcHBsaWVzIHRvIDYuMS4xLCA2LjEuMiwgYW5kIHRoaXMgc3Vic2VjdGlv bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgKE1vdmUgdXAg dG8gNi4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgc3lu dGF4IG9mIHRoZSAmcXVvdDtjb2FwJiM0Mzt3cyZxdW90OyBhbmQgJnF1b3Q7Y29hcCYjNDM7d3Nz JnF1b3Q7IFVSSSBzY2hlbWVzIGlzIHNwZWNpZmllZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiZWxvdyBpbiBBdWdtZW50ZWQgQmFja3VzLU5h dXIgRm9ybSAoQUJORikgW1JGQzUyMzRdLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVmaW5pdGlvbnMgb2YgJnF1b3Q7aG9z dCZxdW90OywgJnF1b3Q7cG9ydCZxdW90OywgJnF1b3Q7cGF0aC1hYmVtcHR5JnF1b3Q7IGFuZCAm cXVvdDtxdWVyeSZxdW90OyBhcmUgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NhbWUgYXMgaW4gW1JGQzM5ODZdLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29hcC13cy1VUkkgPTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtjb2FwJiM0Mzt3czomcXVvdDsgJnF1b3Q7 Ly8mcXVvdDsgaG9zdCBbICZxdW90OzomcXVvdDsgcG9ydCBdIHBhdGgtYWJlbXB0eSBbICZxdW90 Oz8mcXVvdDsgcXVlcnkgXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Y29hcC13c3MtVVJJID08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7 Y29hcCYjNDM7d3NzOiZxdW90OyAmcXVvdDsvLyZxdW90OyBob3N0IFsgJnF1b3Q7OiZxdW90OyBw b3J0IF0gcGF0aC1hYmVtcHR5IFsgJnF1b3Q7PyZxdW90OyBxdWVyeSBdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgcG9ydCBjb21wb25lbnQgaXMgT1BUSU9O QUw7IHRoZSBkZWZhdWx0IGZvciAmcXVvdDtjb2FwJiM0Mzt3cyZxdW90OyBpcyBwb3J0IDgwLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3aGls ZSB0aGUgZGVmYXVsdCBmb3IgJnF1b3Q7Y29hcCYjNDM7d3NzJnF1b3Q7IGlzIHBvcnQgNDQzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RnJhZ21lbnQgaWRlbnRp ZmllcnMgYXJlIG5vdCBwYXJ0IG9mIHRoZSByZXF1ZXN0IFVSSSBhbmQgdGh1cyBNVVNUPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO05PVCBiZSB0 cmFuc21pdHRlZCBpbiBhIFdlYlNvY2tldCBoYW5kc2hha2Ugb3IgaW4gdGhlIFVSSSBvcHRpb25z IG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2EgQ29BUCByZXF1ZXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgKFRoZXkg Y2FuJ3QgYmUgaW4gYSBDb0FQIHJlcXVlc3Q7IG5vdCBzdXJlIHdoYXQgdGhlIE1VU1QgTk9UIG1l YW5zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBCdXQgYWdh aW4sIHRoaXMgYWxzbyBhcHBsaWVzIHRvIHRoZSBUQ1AvVExTIGNhc2UuKTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaGlzIGlzIGR1cGxpY2F0ZWQgZnJvbSA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2F2b2xhaW5lbi1jb3JlLWNvYXAtd2Vic29ja2V0 cy0wNyNzZWN0aW9uLTMiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhdm9s YWluZW4tY29yZS1jb2FwLXdlYnNvY2tldHMtMDcjc2VjdGlvbi0zPC9hPi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFueSBjb21tZW50cyBmcm9tIHRoZSBvcmlnaW5h bCBhdXRob3JzIG9uIHRoZWlyIGludGVudD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs2LjIu MS4mbmJzcDsgRGVjb21wb3NpbmcgYW5kIENvbXBvc2luZyBVUklzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyBBIFVyaS1Ib3N0IE9wdGlvbiBNVVNUIG9ubHkgYmUgaW5j bHVkZWQgaW4gYSByZXF1ZXN0IHdoZW4gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtob3N0Jmd0OyBj b21wb25lbnQgZG9lcyBub3QgZXF1YWwgdGhlIHVyaS1ob3N0IGNvbXBvbmVudCBpbiB0aGUgSG9z dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtoZWFkZXIgZmllbGQgaW4gdGhlIFdlYlNvY2tldCBoYW5kc2hha2Uu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBXcm9uZyB1c2Ugb2YgTVVTVC4mbmJz cDsgKE1VU1QgaXQgYmUgaW5jbHVkZWQgb3IgaXMgdGhpcyBhIE1VU1QgTk9UIGlmIGVxdWFsPyk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJzcDsgQSBVcmkt UG9ydCBPcHRpb24gTVVTVCBvbmx5IGJlIGluY2x1ZGVkIGluIGEgcmVxdWVzdCBpZiB8cG9ydHw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ZG9lcyBub3QgZXF1YWwgdGhlIHBvcnQgY29tcG9uZW50IGluIHRoZSBI b3N0IGhlYWRlciBmaWVsZCBpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2ViU29ja2V0IGhhbmRzaGFr ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IERpdHRvLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIHN0ZXBzIHRvIGNvbnN0cnVjdCBhIFVS SSBmcm9tIGEgcmVxdWVzdCdzIG9wdGlvbnMgYXJlIGNoYW5nZWQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YWNjb3JkaW5nbHkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs3LiZuYnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIG9mIFtSRkM3MjUyXSBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgV2UgU0hPVUxEIE5PVCBiZSB1c2luZyBSRkMgMjExOSBsYW5ndWFnZSBp biB0aGUgc2VjdXJpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgY29uc2lkZXJhdGlvbnMuJm5ic3A7IElmIHRoZXJlIGFyZSBtYW5kYXRlcywgdGhleSBTSE9V TEQgYmUgaW4gdGhlIHNlY3Rpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IGRlZmluaW5nIHRoZSBwcm90b2NvbC4mbmJzcDsgUG9zc2libGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgYXJpc2luZyBmcm9tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IHRob3NlIG1hbmRhdGVzIHRoZW4gYXJlIGRpc2N1c3NlZCBoZXJlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7c25pcCZndDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgVExTIHVzYWdlIGd1aWRhbmNlIGluIFtSRkM3OTI1 XSBTSE9VTEQgYmUgZm9sbG93ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg VGhlcmUgYXJlIHNldmVyYWwgTVVTVHMgaW4gdGhhdCBkb2N1bWVudC4mbmJzcDsgRG8gd2Ugd2Fu dCB0byB0dXJuIHRoZW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgaW50byBTSE9VTERzPyZuYnNwOyBOby4gLSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDtUaGUgVExTIHVzYWdlIGd1aWRhbmNlIGluIFtS RkM3OTI1XSBhcHBsaWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BZGRlZCB0byA8 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEx Ij4NCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTE8L2E+ IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J4oCZbSBhZGRpbmcgYSBTZWN1cmluZyBD b0FQIHNlY3Rpb24gbGlrZSBSRkM3MjUyLiBXZeKAmXJlIHJldmlld2luZyB0aGUgb3V0bGluZSBp biB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPuKAnHNtYWxsIGdy b3Vw4oCdIGJlZm9yZSBicmluZ2luZyB0aGUgcHVsbCByZXF1ZXN0IHRvIHRoZSBXRy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs4LjEuJm5ic3A7IFNpZ25hbGluZyBDb2RlczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RWFjaCBlbnRyeSBpbiB0aGUgc3ViLXJl Z2lzdHJ5IG11c3QgaW5jbHVkZSB0aGUgU2lnbmFsaW5nIENvZGUgaW4gdGhlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JhbmdlIDcuMDEtNy4z MSwgaXRzIG5hbWUsIGFuZCBhIHJlZmVyZW5jZSB0byBpdHMgZG9jdW1lbnRhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSXMgNy4wMCByZXNlcnZlZD88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+R29vZCBjYXRjaC4gPGEgaHJlZj0iaHR0cHM6 Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy85MCI+DQpodHRwczovL2dp dGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzkwPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzguMi4mbmJzcDsgQ29BUCBTaWduYWxpbmcgT3B0aW9uIE51bWJlcnMgUmVn aXN0cnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0lBTkEgaXMg cmVxdWVzdGVkIHRvIGNyZWF0ZSBhIHN1Yi1yZWdpc3RyeSBmb3Igc2lnbmFsaW5nIG9wdGlvbnM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c2lt aWxhciB0byB0aGUgQ29BUCBPcHRpb24gTnVtYmVycyBSZWdpc3RyeSAoU2VjdGlvbiAxMi4yIG9m PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tS RkM3MjUyXSksIHdpdGggdGhlIHNpbmdsZSBjaGFuZ2UgdGhhdCBhIGZvdXJ0aCBjb2x1bW4gaXMg YWRkZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlIHN1Yi1yZWdpc3RyeSB0aGF0IGlzIG9uZSBvZiB0aGUgY29kZXMgaW4gdGhlIFNp Z25hbGluZyBDb2RlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtzdWJyZWdpc3RyeSAoU2VjdGlvbiA4LjEpLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgcy9vbmUvb25lIG9yIG1vcmUvPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkFkZGVkIHRvIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAt dGNwLXRscy9pc3N1ZXMvNzYiPg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3At dGxzL2lzc3Vlcy83NjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs4LjUuJm5ic3A7IFVS SSBTY2hlbWUgUmVnaXN0cmF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBU aGlzIHNlY3Rpb24gbmVlZHMgdG8gZ2V0IHN5bW1ldHJpYyBiZXR3ZWVuIHRoZSBmb3VyIFVSSSBz Y2hlbWVzIGRlZmluZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7SUFOQSBpcyByZXF1ZXN0ZWQgdG8gYWRkIHRoZXNlIG5ldyBVUkkgc2NoZW1lcyB0byB0aGUg cmVnaXN0cnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ZXN0YWJsaXNoZWQgd2l0aCBbUkZDNzU5NV0uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgV2UgbmVlZCB0byBmaWxsIGluIHRoZSB0ZW1wbGF0ZS4mbmJzcDsgU2VlIGFi b3ZlIGNvbW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFkZGVkIHRvIDxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvNzgiPg0K aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy83ODwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs4LjUuMS4mbmJzcDsgY29hcCYjNDM7d3M8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1VSSSBzY2hlbWUgc3ludGF4LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtEZWZpbmVkIGluIFNlY3Rpb24gTiBvZiBbUkZDdGhpc108bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IHMvTi82LjIvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxh IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvOTEi Pmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvOTE8L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VVJJIHNjaGVtZSBzZW1h bnRpY3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSAmcXVvdDtjb2FwJiM0Mzt3cyZxdW90OyBVUkkgc2No ZW1lIHByb3ZpZGVzIGEgd2F5IHRvIGlkZW50aWZ5IHJlc291cmNlcyB0aGF0PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2FyZSBwb3RlbnRpYWxseSBhY2Nlc3NpYmxlIG92ZXIgdGhlIENvbnN0cmFpbmVkIEFwcGxp Y2F0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Byb3RvY29sIChDb0FQKSB1c2luZyB0aGUgV2ViU29ja2V0 IHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHMvYXJlIHBvdGVu dGlhbGx5IGFjY2Vzc2libGUvYXJlIGludGVuZGVkIHRvIGJlIGFjY2Vzc2libGUvPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkFkZGVkIHRvIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvNzgiPg0KaHR0cHM6Ly9naXRodWIuY29tL2Nv cmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy83ODwvYT4gLSB3aXRoIGEgbm90ZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhhdCBzaW1pbGFyIGxhbmd1YWdlIGV4aXN0 cyBmb3IgY29hcCYjNDM7d3NzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1NlY3VyaXR5IENvbnNpZGVyYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTZWUgU2VjdGlv biBOIG9mIFtSRkN0aGlzXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcy9OLzcv PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L2NvYXAtdGNwLXRscy9pc3N1ZXMvOTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs4LjUuMi4m bmJzcDsgY29hcCYjNDM7d3NzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1VSSSBzY2hlbWUgc3ludGF4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtEZWZpbmVk IGluIFNlY3Rpb24gTiBvZiBbUkZDdGhpc108bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgcy9OLzYuMi88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy85MSI+ aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy85MTwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtVUkkgc2NoZW1lIHNlbWFu dGljcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlICZxdW90O2NvYXAmIzQzO3dzJnF1b3Q7IFVSSSBzY2hl bWUgcHJvdmlkZXMgYSB3YXkgdG8gaWRlbnRpZnkgcmVzb3VyY2VzIHRoYXQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7YXJlIHBvdGVudGlhbGx5IGFjY2Vzc2libGUgb3ZlciB0aGUgQ29uc3RyYWluZWQgQXBwbGlj YXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UHJvdG9jb2wgKENvQVApIHVzaW5nIHRoZSBXZWJTb2NrZXQg cHJvdG9jb2wgc2VjdXJlZCB3aXRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RyYW5zcG9ydCBMYXllciBTZWN1 cml0eSAoVExTKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzL2NvYXAmIzQz O3dzL2NvYXBzJiM0Mzt3cy88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VlIGJpa2Vz aGVkIGNvbW1lbnQgYWJvdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTZWN1 cml0eSBDb25zaWRlcmF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2VlIFNlY3Rpb24gTiBvZiBbUkZD dGhpc108bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcy9OLzcv PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L2NvYXAtdGNwLXRscy9pc3N1ZXMvOTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBcHBlbmRp eCBBLiZuYnNwOyBVcGRhdGVzIHRvIFJGQzc2NDEgT2JzZXJ2aW5nIFJlc291cmNlcyBpbiB0aGUg Q29uc3RyYWluZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7QXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgVGhpcyBuZWVkcyB0byBiZSByZWZlcmVuY2VkIGZyb20gdGhlIG1h aW4gYm9keSBpbiBzb21lIGZvcm0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFkZGVk IHRvIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvODM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBcHBlbmRpeCBCLiZuYnNwOyBOZWdvdGlhdGluZyBQcm90 b2NvbCBWZXJzaW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtJbiBjb250cmFzdCB0byB0aGUgbWVzc2FnZSBsYXllciBmb3IgVURQIGFuZCBE VExTLCB0aGUgQ29BUCBvdmVyIFRDUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDttZXNzYWdlIGZvcm1hdCBkb2VzIG5vdCBpbmNsdWRlIGEgdmVy c2lvbiBudW1iZXIuJm5ic3A7IElmIHZlcnNpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bmVnb3RpYXRpb24gbmVlZHMgdG8gYmUgYWRkcmVz c2VkIGluIHRoZSBmdXR1cmUsIHRoZW4gQ2FwYWJpbGl0eSBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2V0dGluZ3MgaGF2ZSBiZWVuIHNw ZWNpZmljYWxseSBkZXNpZ25lZCB0byBlbmFibGUgc3VjaCBhIHBvdGVudGlhbDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmZWF0dXJlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHMvQ2FwYWJpbGl0eSBhbmQgU2V0dGluZ3Mv Q2FwYWJpbGl0aWVzIGFuZCBTZXR0aW5ncyBNZXNzYWdlcyAoQ1NNKS88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+QWRkZWQgdG8gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10 Y3AtdGxzL2lzc3Vlcy84OTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR03MB2380868D3621B914EB751D5283900CY1PR03MB2380namp_-- From nobody Tue Dec 20 00:23:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363DA1288B8 for ; Tue, 20 Dec 2016 00:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 Q6BHkgYwFSkj for ; Tue, 20 Dec 2016 00:23:33 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0243512950A for ; Tue, 20 Dec 2016 00:23:32 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.205]) by smtp-cloud6.xs4all.net with ESMTP id N8PW1u0014RV18J018PWAQ; Tue, 20 Dec 2016 09:23:31 +0100 Received: from 2001:983:a264:1:10ed:14c:14cb:a1ef by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 20 Dec 2016 09:23:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 20 Dec 2016 09:23:29 +0100 From: peter van der Stok To: Klaus Hartke Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <228df7c6c2171d86f18e1fec462d632c@xs4all.nl> <2B199486-E8BA-47B8-8332-5677C5F46BE5@landisgyr.com> Message-ID: <18d0c0fa8c93ecd1e58c6acffa1439a4@xs4all.nl> X-Sender: stokcons@xs4all.nl (v/SD0uXq3cc0+AHkWncHZHux1LXBRRzq) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf. org WG" Subject: Re: [core] CoMI - long term relationship between network elements and management station X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 08:23:35 -0000 you do not notify every client of every state change [1]. > Observe opts for the latter and chooses a notification strategy that > tries to keep observers updated only about the *latest* resource > state. This solves a lot of problems (no storage needed to buffer a > queue of notifications; slow observers don't slow down the whole > system) and works for many - but not all - applications. > I completely agree with the above strategy. It is well-known that in overload situations LIFO is the best way to satisfy deadlines. And who needs yesterday's paper....? When, for example, you want to maintain financial records, you don't want to use observe. Peter From nobody Tue Dec 20 03:49:44 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB244128B44 for ; Tue, 20 Dec 2016 03:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDvd3vV_4w1U for ; Tue, 20 Dec 2016 03:49:39 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0115.outbound.protection.outlook.com [104.47.2.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247F8129552 for ; Tue, 20 Dec 2016 03:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=63EAJwhMS/zrgC5791YjmGUr2p271eGOISVzSSOAYas=; b=mXnJ1V/zuaY4bjn9e9hPJDtVEnUV54tMkE8df5tfI96bjg8mpF3QrYyflIIHuORzAc/XYZiOrxQ38dtxYSnhS7NIOfUormo/0eXTWHyQ1LmMS+H6I5FDj39socYnyP42JWEtD62lvVbkAx2oAryRcMRLzC5KzZWJKS/KgtMuRXk= Received: from HE1P122CA0004.EURP122.PROD.OUTLOOK.COM (129.75.100.146) by AM3P122MB0003.EURP122.PROD.OUTLOOK.COM (129.75.100.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.15; Tue, 20 Dec 2016 11:49:35 +0000 Received: from DB3FFO11FD007.protection.gbl (2a01:111:f400:7e04::173) by HE1P122CA0004.outlook.office365.com (2603:10a6:23:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.15 via Frontend Transport; Tue, 20 Dec 2016 11:49:35 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by DB3FFO11FD007.mail.protection.outlook.com (10.47.216.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10 via Frontend Transport; Tue, 20 Dec 2016 11:49:34 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0169.MGDPHG.emi.philips.com (141.251.190.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Tue, 20 Dec 2016 11:49:33 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0789.018; Tue, 20 Dec 2016 11:49:33 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: CoAP's handling of trailing slash in URI - to file erratum? Thread-Index: AdJatxE8lYy6M5GkQiep6egbQl3Q9A== Date: Tue, 20 Dec 2016 11:49:33 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.122] X-MS-Office365-Filtering-Correlation-Id: 3d7a2f3b-42b0-42c9-7a64-08d428ce44b3 Content-Type: multipart/alternative; boundary="_000_f16b6c637b464821b12795c3c83b3483HE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9001MB0169.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(2980300002)(428002)(374574003)(189002)(85714005)(199003)(55904004)(2900100001)(626004)(105586002)(2906002)(5660300001)(38730400001)(50986999)(33646002)(54356999)(7696004)(92566002)(110136003)(101416001)(108616004)(97736004)(66066001)(450100001)(3846002)(790700001)(6116002)(69596002)(102836003)(7736002)(24736003)(68736007)(260700001)(107886002)(189998001)(512954002)(106466001)(86362001)(84326002)(6916009)(356003)(81166006)(8936002)(81156014)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3P122MB0003; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD007; 1:y3pcHMJRKNhHXLGH7DaMqplgDoI1XmsOeLW3KniHJNi6W1NF2kps4krYmyvkJUzmhHexozQnvdylOmd2RUwN1EW4PRBjHBbUjwjiIo3Jd23F39AMMBOD4VOnXWdVSSuxNn+xPQYaKloBUaHbbzJk9LD+s7bBLZq2heFrNa6Sqlto0wfWMEQWP2h1gzFiEBpIIKwV52Aw8X107mFqJXfDBJAJvouqtdEax6G1+Tz8NeJcMhq4RoiRrLycPyYLiI4jV5eFEnUGW3xwkVylkgGf5HMle1eawN5CqXiCVghoPN2CtdwGBx0/4c6Pkh5TEVsnwTyNTszPrlZOnr666OksFPia7EQsxk4t7uViKVdLf6kbR3L0sO/Io46mpwOFBZlsVyvVhwjTx6Qmku6IxW7bQ0p87k5FR898oKFDiuNd38+GkpBfJDUugLeEoBmvLCdqECBuediBoj1P3B1xSi00cF5T7OOy5PePoNIMGpozAw4WwvAxIkNn1zcXIsdbOKhO6nUI006rLjtwXsBOyl0Tg0i49G+T1btwAf4oN19ygcLI9I0tTkVckM2hafIBV4P4 X-CrossPremisesHeadersPromoted: DB3FFO11FD007.protection.gbl X-CrossPremisesHeadersFiltered: DB3FFO11FD007.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3P122MB0003; X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0003; 3:Fz/qMKbLalqJ82h6IPpsc3ErLJ6B1RWvLQ41ZWHca0hXbxpYR/JcoErWDopnqIdppMyPD9DzJ6YLf7BoEbnZituV1S0M5SWAUi/iAL9dZXrpgpfu2ZV8R1IsLRifQ0RENrNEYUtNUnj2cTOrVQdSV2WQK4vT5W5gg0jW/eEErbPsVEyX0DhtxrTzQH16JY4K2oUpexBU3A+2nYWXMlc/bJhilexSFc5YwamQ+P3Ad0rZhIefSTA15EuNx/ICQ2Kid89ZkC7yPgiOgMlGVyu19n4qgyiqEzgD6y0AX22znrJyDMOtEzuJUXJ/u8IEFaUahWtLKaZ+XDdtN1Z66+Z0W5wnUcOEKkM9Bkm//Ru6QOi28ZFITQeI56M6U6vkQOjP X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3P122MB0003; 25:EXpntOYWTNMRcdZnvCIQoK3D25O50xbD3aoLPG81y?= =?us-ascii?Q?vxOwuMyEBvxCiQSFzdMSBY0gVNiOKoqQc9+SL051VfBf1T6oIMkFp84w4Pre?= =?us-ascii?Q?O0yBfOI0JsFkQMin1pPby+UjIlddOM9n9Lq/wuBKRVYmyD7AsUqVEVWGTZhC?= =?us-ascii?Q?YaDufAPeCwM4seq6bk3VcO+dPxfcGxnf5Tymx82FN6A4vP5sQRMZ0rJDArjD?= =?us-ascii?Q?GRj5aOjowFNs0ir3wb4+J9QjAahaIVAUlIYUf3y+g+UfsbdIZrTIkIg04jaD?= =?us-ascii?Q?eXQVLwHXglpEesoCZDXT+9bYwtODfa4MKJKm0r7q5qRTbnnWs5puagWtWM1y?= =?us-ascii?Q?DH0kxxzwB2I1KDSou2Sui/4kB686JQhXLRLfp0+HuCI0zTedOZ0WKPEyD6eR?= =?us-ascii?Q?Bfmt5jj37kRZ91yHJqQHQZSADK72A0XyMweQFnTR2IvTLyVSex4jvnhbTRM0?= =?us-ascii?Q?YuD58gPj+xINiORwhRHGlHTQ8SzJbRzzVxDKyfOcL2X+sVeLrbFFxtCaPFh0?= =?us-ascii?Q?wf0bovwLQnnj49sLu7pVciiZUu6r8tfzam3hP7izJPdMqr6sbXTHLSip5tgH?= =?us-ascii?Q?1lzwbTKV6S+t34HdOPWGgc7xcOZtSLEC22LXXpXmKGSHJW/NX3GP/9kEDleQ?= =?us-ascii?Q?sTxTyxfKJe4jr9KBfTsRakwq30LWZfFap/UHHxo2Cl2ca6FHi9UKUOcHvNdI?= =?us-ascii?Q?7YU+SWpSUS1YJf6QhAxmpGJDmA+2bF/295jDiqZ0ozHWzRbxtH+GyHUycnfA?= =?us-ascii?Q?KDuF3QFVQ05slY7bummB14jaEpTcxPC3aiuukd8vSff8/3ETH+ctIdS1urUy?= =?us-ascii?Q?J3gARctjhz3Bg5heuMoPRz3DKKb6nn+AXLYoG8vcTUtk574JMHYt+hQL1k37?= =?us-ascii?Q?39wRbsNAS6OtHUOZStJkhGvl06yBMFxiymrR/8TsIlUbZ8qSgvoS03MewgC3?= =?us-ascii?Q?3S2EeGD7tx7xo8vZUm78oUIEKkJj14ncGLsXFrQEw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0003; 31:mVjxs5MJi/aS37B1anq8GhACKZlKBsimAGsQPAKobabAsBMlUmaw3s8lI0z+7FLVtHDecq0tEU+IP9BSA3NgnzXUXHhecjACMAyMNJXQPOnPK9GKh92d+xmBbDqLHsXa9+X845Z3XOw8YbAtT0xek5ze2ItvqnDeSMG+X6FLPVNyXipRZeG9UY3kU5BsHAjwyN+L7qtFbnv89aHKzTnktomagLcjT7RJx9tLtmrvpzNbzQ/qjp6iOXN+CcN6vBoUt3k333Exy1rmdQF8Y45cY8GU8IwqFJY4F/3P73hEJTc=; 20:VrMWKq9CJ4FhXCF/t/tPc60cbZ+lbqXiW4E1gG/ALOSmkax6PlslUl53ZBCRqNfpO8YQSekn7BgYPM47hmFtw7ctqJUG8fngVGkafBqdbps0CzhowIS1qb9+r+boUMxByuLSya7JybXZDdaqsvrjSlNHjzIjVZPZXoSuKVmh5dPj6SvWXDPUbg+/1lt7icq4XzjrtgzMEt38ysxyl9ZsZq4iygpPvjibaHVCND/cVyukBugQH/1MXjmJDnrpIyvOejJGW9Z/kommgFYSLWQ4f2Sb6gpNUIwMnRDMOT7klUmBrhAfzBtSBQ4FaoL68Mo6GS6tuq4bi1C7Q6q8667N2hOQbQ3eGizvFd2an1ysvYPSTE82w/gGb6U0ENwfo1CDjvQKzNXU61cfvGi6CtRiEw4Og1KAY7mldHUsvKRCSKUzbiLgAq6Drg1mnLiv0ZuP6xskY4svOSi0KcPQMb25kcYqNfMp31+a0iSgoYX4IEVv4Nu4HRyi0PUj+5/hc1Xv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(13016025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM3P122MB0003; BCL:0; PCL:0; RULEID:; SRVR:AM3P122MB0003; X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0003; 4:CBSoFjL/knj8dq5hpJU5jPAHi/YA03TV1fXiLYiu1rECBYvDQL0cuNaVRVYNBjD+INlCXw+7fbvcZVCLYG29yKy9PA7SX/+QJBN5BIcnLiOSGMXuhiWoQ+Z8Wxn2W/QtEeTU1NczA8ozo2VSKCJYm9gcXcRX1vt5oCBpQ7W1XGheiBzBUytynDVQ9balVPaU3J0B6qItooVAsN8GCc1jycZ7mPY5l/kylI4iJZVaWn7GpGwGckWPrgrVee+RdsXNx1OK6Nati/cumV6bx1hY2AvtQjHNu/VDldWz10Wa5QsVqH1/dNgNgNqmuuN6exLvryuNL/B+Y1TJVC6ChlBXbqsUrXaYL7yRVr7vXhmBHPZyFHkwJ3nEXNA1Waqi0+HhwO9jED/qWClSCg336O+NMS6mpU1WfuyXk8xRWiMNCcU8KauI4G8tzi5KoQmQy2SBn4EbSf3Kzl2d3m7mlH2mginRRSKK4LDqCSs94ZYgYP5QY0oOz1Lz02mKhNsGP0zsAximBRanXw0/BQ6TC9VrA5/3B5CtNmdmp8I20ZZ6iWDexusFCKK6hrHk4esEZxUFCwnZE0m92vvvGTnm/C+kpIVnKPXhB9kEJJ/4B9RrwGiOYdmQRtTwcTm34mWJHPoZn9akIZT/TO2BI6aPidXuRiSK59b6kqSehll2M+vX+Uw= X-Forefront-PRVS: 0162ACCC24 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3P122MB0003; 23:oHb3Dsh5R57zz1MPoLeoLL59L86G/C2yO9fdBUIme?= =?us-ascii?Q?L/mxQjn4FD/GV3G2ocNuKY5YsByw+kpluWu6n27JBa4pgOiJxPPiRPStxx+i?= =?us-ascii?Q?6hmZbImFOV8Mq5sNeANoOmOI/kGCF8kMj8wIzBzMv7Z7P7Tt9gC39ItLp+DO?= =?us-ascii?Q?Cb8FXRO+14WR3NxARrXkNNBZMsDjCNmsmmKiKJdW3NqdmY6r+PoX1bofmcXd?= =?us-ascii?Q?UWL/IM27fRaBMRSVtdibuUMyl3HJEnYvrlVONPaWC9hx/C5U+tH1NnxqukCZ?= =?us-ascii?Q?ywOkUmHhJA6f43EyE8Mc4xQ9yMQ7h87NUsFG16B3FyVNDyPmOtC/qeXOobsj?= =?us-ascii?Q?xwQHIp9cPSbgXhX/i0SzyxmETi1z4O5BuP4kF6qL3QJLChw35WsxeOuZYtea?= =?us-ascii?Q?0I8FLzEgz8iBiMzVt1BwHPB6qoLURmj/5YAGwEsAZrVM18KftnPscQ6jtoEc?= =?us-ascii?Q?03IEtOY8H85jIF8nOy+8E86SWTxejGCbnXRP/1r81lvglrnMXHsxd/2sa1U1?= =?us-ascii?Q?Vc16LWEKdMEN/1CSECVF7GnaL+L7hXQBjdWnD6W7R5yAqTWPx1DBRygiO80l?= =?us-ascii?Q?b2cIAOZTj0AKjolmZmeuHsejqHsDa1a9UbkvlJ9s9GoUccKTrFFn/NH354jZ?= =?us-ascii?Q?7RalLX0cTe1nB6sx3JPy+KXZI//MJqvFA3rI1wic6/JWW4WasERkVwUE8MxD?= =?us-ascii?Q?tYgfSSkL5AL3Tfp0piLe/k5N9c83895UVx+jEuJZtA6OS/GJmOfzn8upLSEh?= =?us-ascii?Q?hwr8NAjHihxldivz7lXUfptXIFiBoxl5xpiOPnVgwEzN/Fk1UoFULNHaFp9p?= =?us-ascii?Q?I5ctdA911D696IraWGGSC+QswIGRXtDYh/+0yjirVCqRd0p34JTvED2duwL5?= =?us-ascii?Q?Xv8N98Qm/wOhjdocOeukMAivZ/pyniSEYMn+67PCyYzzLQ3LNkxKTMvmothm?= =?us-ascii?Q?Obs+4PHf07f/lTaK816TxOZTTJjYz+hocfMILasBilqI4WU18cOFk1l7Z4Sm?= =?us-ascii?Q?DSIvHeRs00GGmUof4/IPKLjQnU56cbdABdhBhJ7gnMhG8SUcFbqpAbPv2a7t?= =?us-ascii?Q?SEPlFd1zzJmY4GpqAn74uVfGwcvQTMbdH3fo1Wv1ZEe22lspWFajxnN+J5ZY?= =?us-ascii?Q?Vv1VJgWIepZH7m5TYI/7Z7D7l0HQjInSoGBsMwCq18KHB4C6AzK2curMqIYr?= =?us-ascii?Q?oaDUO2c5D1xf883VH8WpTE9iArmSajRI4OSxWjwzTtYag2spL/AjNQk5/X61?= =?us-ascii?Q?Umo8JzdqWPsw3a45Vs=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0003; 6:joKRYIwwHNtFT/+uRBQ/098yjrRAc8c51QVqJbbwsk3IQYl4WLtz7doL+TTgnrmZ5nVvreZhveQLBS823TbAfNFkhwf6qaERB+xpD4QdJi3FZr8H4JOZJxM4eswV6Hvpe21u1IpZGEwV0fWSxy+wKS1Pw91fApZ8YND7jNfuICNi/W7cBtHAuHs6nFjZOZoisTJUHc45UwngC78zCV95fcuIJm8V132iisbhCChrTi0/5GFZ/IWYkGOpU8yIxUrWR4GCIPC1/gDH44O2IezSgYY/C5ZZOArxQyc4QCWycizBtfT24oerkQIfCKBsw+5K0i547wQzRjmynzK4HyL7B5aD7i+EGDbFxMEhw+l/tBSJOjQzDHO2mQTM88gLyTQrD5Y6/OWlcR+iXZDQUStLNnOd9O0JVh1JZrfFlTDCviYXh6OBJM3Jcl259tRqsBPoEgqSV19t40dEbg8hHfy3RA==; 5:1hJv3hy7s1U2NQBn2Sq9Ov7Ork2P4D9+BnN+9uSBY6DLLKps9PI/5LKct7JkK708LTazSYe3bvfuvZvlAYze4aPasrlAO6FTcfcIYmZDMRu3m7LO9l7vxSDQ2TYK8MYcw1vkXXj7H15ZtpswjZaX5Q==; 24:4tc5IfABytDe1NeNYgEL064adVL1ZShlCQOvEi+vzCUrPBDN+tksxVuHutHWOnR4+EKg/aimbD5A9e3fB+zqIwLQMw6QM+K8WhM2FbdZa8s= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0003; 7:rMr39otrOD+8KAtaNDVDUCdzCJDtQQKraD1kvPPT/R5BlSxtLVigPafu3SEfa5iQMhxSL8sEFXCZpB+jNuu9LttcTcBaxRfso0HGrdAbajt08N6pVcDrLp+dSe9y5p4G3vxC/iIYcaJptYEGFxxwGDKd9a9qLhMSvq7vNi5vwiaaaEKBQhPvKPN0UuTTyno1MntyGYmwaxCcanhJkE4Gy3Tg4/+F2pSpyjBV2LRLu/BqVQmtJoDOHk3hHB3CjsN0XygAFbMK+IEUoxzx5VVNWPy2MjrrbjzlijGrF5tulNXgdepHzIHdIxUrEiJyxtcLdMa/xM96SMtlJi8JpNnvZEwZ83wfZDWWuztxNJtGE0NtUMviydBMXzrR5v/cQ++7Y0Dq2V9P6brif23X2Zi28gY86p/urq4o7jL7AdO5ujVQpid5qFKhdnR7L+2KoLTUtED9GRtWKizHZsiRcINyyw== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2016 11:49:34.5977 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3P122MB0003 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR9001MB0170.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 194.171.252.122 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: AM3P122MB0003.EURP122.PROD.OUTLOOK.COM Archived-At: Subject: [core] CoAP's handling of trailing slash in URI - to file erratum? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 11:49:43 -0000 --_000_f16b6c637b464821b12795c3c83b3483HE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear CoRE WG, while looking at the CoAP spec recently me and some colleagues found a pote= ntial wording issue in the handling of URIs with trailing slash (/) charact= er in CoAP. The issue is as follows: one would like to encode the below two CoAP URIs as separate CoAP requests = because the two are in principle semantically different: Example #1: coap://host.example.com/path Example #2: coap://host.example.com/path/ (Although many CoAP servers will want to treat these requests in an identic= al way, similar to the way HTTP servers do, in the generic case these are d= ifferent requests.) The Example #1 URI will be encoded with a single Uri-Path option containing= 4 bytes "path". The #2 URI should be encoded with two Uri-Path options, one containing "pat= h" and a second one of zero bytes. However - RFC 7252 Section 6.4 step 8 mentions: " for each segment in the <= path> component, include a Uri-Path Option and let that option's value be t= he segment (not including the delimiting slash characters)". Now taking the above two examples, example #1 contains a single segment "pa= th" which is encoded as one Uri-Path Option. Example #2 also contains a sin= gle segment "path", encoded as one Uri-Path Option, and the delimiting slas= h character is ignored just like the text says. So the problem is that both= examples are encoded in exactly the same CoAP request, which the CoAP serv= er. Furthermore it may be unclear to an implementer that the Example #2 pat= h contains in fact two path segments, of which the 2nd is an empty segment.= Because the text appears to say "don't include the delimiting slash charac= ter" this will easily go wrong. For example, the often-used Eclipse Californium library (1.1.0) has this pr= oblem. I'm planning to file an erratum on this item since clarification of RFC 725= 2 is clearly needed. This email is to check if others agree, or not, and wh= ether I missed something. best regards, Esko Dijk ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_f16b6c637b464821b12795c3c83b3483HE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear CoRE WG,

 

while looking at the CoAP spec recently me and some = colleagues found a potential wording issue in the handling of URIs with tra= iling slash (/) character in CoAP. The issue is as follows:

one would like to encode the below two CoAP URIs as = separate CoAP requests because the two are in principle semantically differ= ent:

  Example #1:  coap://host.example.com/pat= h

  Example #2:  coap://host.example.com/pat= h/

 

(Although many CoAP servers will want to treat these= requests in an identical way, similar to the way HTTP servers do, in the g= eneric case these are different requests.)

 

The Example #1 URI will be encoded with a single Uri= -Path option containing 4 bytes "path".

The #2 URI should be encoded with two Uri-Path optio= ns, one containing "path" and a second one of zero bytes.

 

However - RFC 7252 Section 6.4 step 8 mentions: &quo= t; for each segment in the <path> component, include a Uri-Path Optio= n and let that option's value be the segment (not including the delimiting = slash characters)".

Now taking the above two examples, example #1 contai= ns a single segment "path" which is encoded as one Uri-Path Optio= n. Example #2 also contains a single segment "path", encoded as o= ne Uri-Path Option, and the delimiting slash character is ignored just like the text says. So the problem is that both examples a= re encoded in exactly the same CoAP request, which the CoAP server. Further= more it may be unclear to an implementer that the Example #2 path contains = in fact two path segments, of which the 2nd is an empty segment. Because the text appears to say "don't i= nclude the delimiting slash character" this will easily go wrong.=

For example, the often-used Eclipse Californium libr= ary (1.1.0) has this problem.

 

I'm planning to file an erratum on this item since c= larification of RFC 7252 is clearly needed. This email is to check if other= s agree, or not, and whether I missed something.

 

best regards,

Esko Dijk

 

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_f16b6c637b464821b12795c3c83b3483HE1PR9001MB0170MGDPHGem_-- From nobody Tue Dec 20 04:33:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B71C129678 for ; Tue, 20 Dec 2016 04:33:31 -0800 (PST) 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 Y7Ukj1JRbJir for ; Tue, 20 Dec 2016 04:33:29 -0800 (PST) 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 857D9129669 for ; Tue, 20 Dec 2016 04:33:29 -0800 (PST) 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 uBKCXQT8019971; Tue, 20 Dec 2016 13:33:26 +0100 (CET) Received: from [IPv6:2002:8666:da7b::c4d5:9240:6585:283b] (unknown [IPv6:2002:8666:da7b:0:c4d5:9240:6585:283b]) (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 3tjcdf2H2hz8N4D; Tue, 20 Dec 2016 13:33:26 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Tue, 20 Dec 2016 13:33:25 +0100 X-Mao-Original-Outgoing-Id: 503930005.466799-8d9361a09aabd04dafc3c3bd443fbe91 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Dijk, Esko" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP's handling of trailing slash in URI - to file erratum? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 12:33:31 -0000 Hi Esko, RFC 3986 is a normative reference of RFC 7252. While the defining parts of RFC 3986 (e.g., Section 3.3) are not very = explicit about this (you have to read the ABNF to understand), Section = 6.2.4 finally is. > one would like to encode the below two CoAP URIs as separate CoAP = requests because the two are in principle semantically different: > Example #1: coap://host.example.com/path > Example #2: coap://host.example.com/path/ Not just in principle =E2=80=94 they definitely are different. > (Although many CoAP servers will want to treat these requests in an = identical way, similar to the way HTTP servers do, in the generic case = these are different requests.) They can=E2=80=99t do this in the same way HTTP servers do this, as that = involves a redirect (which we deliberately don=E2=80=99t have in CoAP). > The Example #1 URI will be encoded with a single Uri-Path option = containing 4 bytes "path". > The #2 URI should be encoded with two Uri-Path options, one containing = "path" and a second one of zero bytes. Yes. > However - RFC 7252 Section 6.4 step 8 mentions: " for each segment in = the component, include a Uri-Path Option and let that option's = value be the segment (not including the delimiting slash characters)". > Now taking the above two examples, example #1 contains a single = segment "path" which is encoded as one Uri-Path Option. Example #2 also = contains a single segment "path=E2=80=9D, Segment is defined (Section 6 intro) to be a reference to the = terminology defined by RFC 3986, and we clearly have two RFC 3986 = segments in the second case. We probably don=E2=80=99t have an example in RFC 7252 because that is = not emphasizing collections (which is where these URIs typically occur). > encoded as one Uri-Path Option, and the delimiting slash character is = ignored just like the text says. So the problem is that both examples = are encoded in exactly the same CoAP request, which the CoAP server. = Furthermore it may be unclear to an implementer that the Example #2 path = contains in fact two path segments, of which the 2nd is an empty = segment. Because the text appears to say "don't include the delimiting = slash character" this will easily go wrong. > For example, the often-used Eclipse Californium library (1.1.0) has = this problem. > =20 > I'm planning to file an erratum on this item since clarification of = RFC 7252 is clearly needed.=20 Filing an erratum calling for making the fact more explicit that RFC = 3986 works this way is good. (It is not, however, an =E2=80=9Cerratum=E2=80=9D in the Latin sense of = the word; the text is unambiguous when properly consulting the = references, and it is not wrong.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 20 04:45:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02FF1296C7 for ; Tue, 20 Dec 2016 04:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] 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 sc0KlYYgnUhG for ; Tue, 20 Dec 2016 04:45:17 -0800 (PST) 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 798A31296C9 for ; Tue, 20 Dec 2016 04:45:17 -0800 (PST) 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 uBKCj9rl017123 for ; Tue, 20 Dec 2016 13:45:09 +0100 (CET) Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tjcv9490pz8N4Y for ; Tue, 20 Dec 2016 13:45:09 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id f82so129418023wmf.1 for ; Tue, 20 Dec 2016 04:45:09 -0800 (PST) X-Gm-Message-State: AIkVDXL+zUP+BynxxIfzoswYaEyj1PF2vWjS9VAmewkO3X+fqjDvdDWOe36Zb5bPW7fqGUoN6L3jLT6WATom0w== X-Received: by 10.28.45.142 with SMTP id t136mr1947288wmt.110.1482237909254; Tue, 20 Dec 2016 04:45:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.16.38 with HTTP; Tue, 20 Dec 2016 04:44:23 -0800 (PST) In-Reply-To: References: From: Klaus Hartke Date: Tue, 20 Dec 2016 13:44:23 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Dijk, Esko" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP's handling of trailing slash in URI - to file erratum? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 12:45:18 -0000 Esko Dijk wrote: > one would like to encode the below two CoAP URIs as separate CoAP requests > because the two are in principle semantically different: > > Example #1: coap://host.example.com/path > Example #2: coap://host.example.com/path/ > [...] > The Example #1 URI will be encoded with a single Uri-Path option containing > 4 bytes "path". > > The #2 URI should be encoded with two Uri-Path options, one containing > "path" and a second one of zero bytes. This is the correct behavior. Section 3.3 of RFC 3986 [1] defines the path component of a URI as a sequence of (possibly empty) segments separated by a slash character: path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0 As the ABNF shows, there are two segments in Example #2 ("path" and "") and segments do not include the slash character. RFC 7252 Section 6.4 step 8 tries to make that double clear by saying "let that option's value be the segment (not including the delimiting slash characters)". So I don't think that RFC 7252 is wrong. Of course, there is always room for improvement of the text. Klaus [1] https://tools.ietf.org/html/rfc3986#section-3.3 From nobody Tue Dec 20 12:02:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88E11295F7 for ; Tue, 20 Dec 2016 12:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qdQDs9gyeBRY for ; Tue, 20 Dec 2016 12:02:00 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FC81295DE for ; Tue, 20 Dec 2016 12:01:59 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7E2F745BFC; Tue, 20 Dec 2016 21:01:56 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id AB6E3FD; Tue, 20 Dec 2016 21:01:55 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 923113EA; Tue, 20 Dec 2016 21:01:55 +0100 (CET) Received: (nullmailer pid 11164 invoked by uid 1000); Tue, 20 Dec 2016 20:01:41 -0000 Date: Tue, 20 Dec 2016 21:01:41 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Message-ID: <20161220200141.25sxgblqdfdzpnin@hephaistos.amsuess.com> References: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> <70e08696a7f97ae01ba3633e2266f816@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2jhwn654wprdbsrh" Content-Disposition: inline In-Reply-To: <70e08696a7f97ae01ba3633e2266f816@xs4all.nl> User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: core@ietf.org Subject: Re: [core] resource-directory: notes from implementing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:02:02 -0000 --2jhwn654wprdbsrh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 14, 2016 at 10:13:58AM +0100, peter van der Stok wrote: > Usng the (ep, d) tuple as key for registration sounds difficult as d is > optional; and d's may be generated after the generation of multiple ep's. > To which d do the earlier ep's belong to is then a valid question. That the d may be changed (or created) later is a point I did miss. I suppose such a thing could happen if a commissioning tool took up a registration and POSTed an update to its +location with a new d=3D query parameter. > Zach always insisted that storage issues are the concern of the > implementors, and they have the returned location (e.g. /rd/4521) to guide > the implementation. Sure, storage is a different issue. > That subsumes (IMO) storage uniqueness within one registration and > consecutive updates; while additional criteria can be checked without > affecting the storage. >=20 > does that make sense to you? Frankly, no :-/. The question to me remains open what should happen after * my-device POSTs /rd?ep=3Dnumber41 (-> location /reg-12345) * some tool POSTs /reg-12345?d=3Dexample.com * my-device reboots and POSTs /rd?ep=3Dnumber41 again =2E My conclusion from this is that I'll make sure my devices register with their configured domain, but for implementing the server this leaves me none the wiser. Reading through the draft again, I read > The registration interface MUST be implemented to be idempotent, so > that registering twice with the same endpoint parameter does not > create multiple RD entries. which might even imply that two different devices registeringin at /rd?ep=3Dnumber41&d=3Dexample.com and /rd?ep=3Dnumber41&d=3Dother.network should be smushed into one registration, but I don't think that's what's actually meant. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --2jhwn654wprdbsrh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlhZjiEACgkQOY0REtOk veHCLA/+LmMgdW0dBIOtqQDpLaJh3BNs7WXcs4wlokRUH1pdAJbC7E3HsGq6y4im rHsGwg1wEsim1QrNcgWf7Dcsro4o+l1qoCk3/t0pPwTHXrZVwLh/3b6QmcKAN6q8 6PYHtMOK1xqJuImjjbuVxmmrKlmXD4YoRL1VlYY9fWRbGsBGWRpuFVDF2a0TFoUR qe0uZiCZso8XmMnGNIH9OhgVYsu3Fb9Fu26S7EqeUbQcAYwgxmtbS/Vu7vRzPx+Q m1CLIg6bHe0drqv6UDnvJMvb06WJh5/rdPNEZoGVJpLuy+7pFPBaOnsHaH2nHiDC AN/wYSEaAnFI8tbmrph9TGn+U1/ITIcZtc4rJ5IsEqMwet2+bX09RbW7EnmOk7p5 ftXK6M5zmQ/XLTHDg6Ao2tvJMJNq4ZNrKIbkKchw/68ZClPxsjAi00qZlrku763s 5TopBz2lHUoWKOjgPgGuafc6U4Umn5UFbjq1VbC36xSuYWO2NZJssUJ7x7nA3I9T DW1GRmpjlO3YuplXGCX8eDy98+tld7lX2oCMAu/VwvlZPJYUwAAqA+d6UNmNGuHD wmxEzqVhNCdF5n5F7Cp6JFLTRuupRPmGg8hWuivAVWtOVPf18CVIebfbLS+gEMmc detZqPsAsIP3lkIFNCJcwa05HpsCpVV6oSC0Xe6F8Ezb4F3wubA= =Tvlv -----END PGP SIGNATURE----- --2jhwn654wprdbsrh-- From nobody Tue Dec 20 12:13:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184EA12941D for ; Tue, 20 Dec 2016 12:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esddXVu7rl2d for ; Tue, 20 Dec 2016 12:13:29 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 B69851295DF for ; Tue, 20 Dec 2016 12:13:29 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id i88so30326006pfk.2 for ; Tue, 20 Dec 2016 12:13:29 -0800 (PST) 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:message-id:references :to; bh=m0F4Fbr8eucOazguf2G35UE1+X91+tdoLPivvVzNh48=; b=kMVaXKl2XzYUsploQCO+CRGf1Qd92x1uKhUr8pgt/tVBG5H7EOXtRHrr3elb6Bb1Us UaGbabmHsL/6eVKZ1keeZNHysPL6cL2sUrYLM/UaP+SX5DoPW/jkWk7/xAb+aSfhBkid 11tcrrX/3kMxqfWEDEa//gfl2yYLWLM6TfUOD9N34JESfn2q0rVsAEKN+7geyO7Cym0N tT7SvYCTuLB0DkTZjZIyMhk2h2LzCLEoRan7Di26ISJIFGMT+90ms0KUSyaSzvb/wDF7 ZUYvat9YYoMB1o/9i9qJ4XSQqZmfPNZoSkAh7fwmLtC4fmrgvAx3o4M3Zl38eZBQbME6 A3zw== 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 :message-id:references:to; bh=m0F4Fbr8eucOazguf2G35UE1+X91+tdoLPivvVzNh48=; b=GNaZ9DOMvm7pi/eb0dPUCuUF7pbufKH/tFUU8u8tDWspgUMxR1sUZuL5q0OEkztQgv K5PWfaUL2frXv57hNGisGpJPicFouxAFz/P2UpODz4avvcmxm3JDj9JXGyJhFpGAVvhb YIMHUv1HVFOUoWhCDjhc0a+qXMa10t/T2KArKFvhNNNqOJKpULY7O8Fk8S1TGeHtNY1z wJdCzMvYZJhdrBAd6hNjgBHeas/NE26ViiF73et/xDcR+SNn2A6uYxuW2QeM64Igr3eH NZtbBHZbdlVchjXd44m86EfZG8/C+a0to1dgyJOOctFWkiND4CuxQGhIsE/Uzpp10N7q IdCQ== X-Gm-Message-State: AIkVDXJsPemU+Ye6YkTqF5RsF1kLMJtSx61Qn2VcGW6mS5GSGQdeOuiB9dp2aHVTZR+lbw== X-Received: by 10.84.225.129 with SMTP id u1mr1925352plj.110.1482264809247; Tue, 20 Dec 2016 12:13:29 -0800 (PST) Received: from [10.0.0.23] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id s3sm41123867pfe.27.2016.12.20.12.13.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Dec 2016 12:13:28 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AD6DCFD7-A40D-4021-B75C-9BC3C2308D1C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> Date: Tue, 20 Dec 2016 12:13:27 -0800 Message-Id: References: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] resource-directory: notes from implementing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:13:31 -0000 --Apple-Mail=_AD6DCFD7-A40D-4021-B75C-9BC3C2308D1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 We need to make it clear that if a previous registration or update has = set a lifetime value for a particular registration, it must not be = reverted to the default. best regards, Michael > On Dec 5, 2016, at 8:10 AM, Christian Ams=FCss = wrote: >=20 > Update suggestion: "If no lifetime is included, the previous last > lifetime set on a previous update or the original registration > (falling back to 86400) SHOULD be used." (Possibly also "MUST be = used" > or "is implied"). --Apple-Mail=_AD6DCFD7-A40D-4021-B75C-9BC3C2308D1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 We need to make it clear that if a previous registration or = update has set a lifetime value for a particular registration, it must = not be reverted to the default.

best regards,

Michael

On Dec 5, 2016, at 8:10 AM, = Christian Ams=FCss <c.amsuess@energyharvesting.at> wrote:

Update suggestion: "If no lifetime is included, = the previous last
 lifetime set on a = previous update or the original registration
 (falling back to 86400) SHOULD be used." = (Possibly also "MUST be used"
 or "is = implied").

= --Apple-Mail=_AD6DCFD7-A40D-4021-B75C-9BC3C2308D1C-- From nobody Tue Dec 20 12:14:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34861295F1 for ; Tue, 20 Dec 2016 12:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rKgjWjXaIcdo for ; Tue, 20 Dec 2016 12:14:45 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48101295FD for ; Tue, 20 Dec 2016 12:14:44 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2F43E45BFC; Tue, 20 Dec 2016 21:14:43 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1B39AFD; Tue, 20 Dec 2016 21:14:42 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E78F13EA; Tue, 20 Dec 2016 21:14:41 +0100 (CET) Received: (nullmailer pid 13941 invoked by uid 1000); Tue, 20 Dec 2016 20:14:27 -0000 Date: Tue, 20 Dec 2016 21:14:27 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Message-ID: <20161220201427.fdb4zs4rb7xxz4we@hephaistos.amsuess.com> References: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kitgdjoh6t4ltm25" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: core@ietf.org Subject: Re: [core] resource-directory: notes from implementing (2), X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:14:46 -0000 --kitgdjoh6t4ltm25 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 14, 2016 at 11:34:25AM +0100, peter van der Stok wrote: > > * The `resource-param` parameter was called `source*` in RFC6690. It > > might make sense to call it the same here or reference to it. > >=20 > > Given that unlike RFC6690 (only one element, see above), here many > > filters can be given, it would make sense to suffix that parameter > > with a '*'. >=20 > I don't follow; I dont see the similarity between source and resource-par= am; > can you explain a bit more? I seem to have mixed up terms a little here, let me try again: RFC6690/4.1 defines a {?search*} query which is a generic argument for filtering by arbitary properties of link-format entries. The resource-param of resource-directory seems to serve the very same purpose, and could thus be similarly named. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --kitgdjoh6t4ltm25 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlhZkSEACgkQOY0REtOk veFjEBAAv7l2FnjGnQ5vlLV++6d8kBtp+A6hMI7J0t+wAjJAjICgUlCDvb30wQ7o froSBmljsegLezeJN9Kp+yB6k28USy0z4Dev8qJHW0+GMHfr0HZI8fTKHoTP4BhF LPN0JRr8X9TmoHWnu7gyLJpQ6peNDoMCmgEajPtsZ1grBEa8bLH83GfrozF4Z5/z ovSjr7yCszzdGiJKpKAkqJTVV70L1wiw+Q4ikI/faMkN86Bpq5TJofsgqdHNb3E6 YpBJAPeM2P7tuShDsWwkBk2c88NwUdPlD+Rb2z7WtR8kx2+8RVpXTtFJa/JBI+O5 4j+tIBOkE5oUH+ybC92r0oiceWE9HpDi72+y3M49zbmeS3oVhB/07iLqd6mFQ7cg 0Nndq4cU62bmR6oo3b525YSCNLa5bLN8aRRk791UkKg8tpI5PtNou7+dV1GEtw6M QvTlimgNARTl8wMqmBNtkSbp4XWjxntA7Lbel8IlXDOZgoSiVRsgj2dbD4f+daeS frrWS+/f+kItDor4MbdJUHjU9a7yFmeFQGuIptTP8YU45wmM7sWr087zb4fnJee1 LwHT3fiivr9j4K46x1317yQSQRIQWn0lnqmTKUg3fWcaInzuqyW7y6uIpcppaq1c rTlL0VXYhKhFsanKDxjgz54IK1KzDYPUKTHc0+i10nkU9go8Mzk= =u4uG -----END PGP SIGNATURE----- --kitgdjoh6t4ltm25-- From nobody Tue Dec 20 12:37:40 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1B1295EB for ; Tue, 20 Dec 2016 12:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hUvVgt2BaUII for ; Tue, 20 Dec 2016 12:37:38 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AC21295BF for ; Tue, 20 Dec 2016 12:37:38 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5123045BFC; Tue, 20 Dec 2016 21:37:36 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C127DFD; Tue, 20 Dec 2016 21:37:35 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9F8953EA; Tue, 20 Dec 2016 21:37:35 +0100 (CET) Received: (nullmailer pid 18161 invoked by uid 1000); Tue, 20 Dec 2016 20:37:22 -0000 Date: Tue, 20 Dec 2016 21:37:22 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Message-ID: <20161220203722.ke2brcnp5fcu2s5t@hephaistos.amsuess.com> References: <20161205161041.wrc5sz4bhdw5hp22@hephaistos.amsuess.com> <9a3a9ad52a9675a12ef4312e857c216b@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gck6qnhcvmvyalgq" Content-Disposition: inline In-Reply-To: <9a3a9ad52a9675a12ef4312e857c216b@xs4all.nl> User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: core@ietf.org Subject: Re: [core] resource-directory: notes from implementing (3) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:37:39 -0000 --gck6qnhcvmvyalgq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Peter, On Wed, Dec 14, 2016 at 12:50:21PM +0100, peter van der Stok wrote: > > * Why is `rt` explicitly listed and not subsumed under > > `resource-param`? Granted, `rt` is defined for > > group/endpoint/resource lookups while `resoure-param` is only for > > endpoints, but why is that? > > I think you answered your own question. > Subsuming rt under resource-param will not make the text more readable (t= he > contrary I would say) Follow-up question, as I just implemented a no-op there: What does a /rd/ep?rt=3Dsomething query actually mean? Is it just a "match an endpoint iff any of its resources have that rt"? Does that have actual applications (given that the resource with the rt could not be used until a second /rd/res?rt=3D query is issued)? If yes, why does the same not apply to resource-param so it could be used for /rd/ep queries too? Best regards Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --gck6qnhcvmvyalgq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlhZln4ACgkQOY0REtOk veGTZhAAkeroTNXR6K11tyE64BqUBEjGQEHjeBuLcZJVTgKO+GVEFs4zCz4uiMFk 0vfFYjlmlfRfwCPlqmJax0md4/T7O2pC7r+Kp3mGkRgehonhebRpwRY1pF0k25D2 oE4ryB7225uoK5gAcrOtUQi9AYyba9fXWSWLPfioL1SsbEUv7C3sHzj95wt7rfmK ihYKy24AXMLOYsPQeXQvRVnpxrQwkTtkXgpSYc3V/3/lCqfJYqsOwNq77YGx+LXf 1BMHool548aUISt77vV37QV/lfL6M4zgSNvrTO9AH1IOLg5aQ3CUji9yDZuLMbyB JjnbNL0NeGVWzS+rE29uK7l5q7lSXVZsIaQQQhyUbjAn8dbZJTV/yl5rE17KwoWQ oFKW/JWbogRf/GY+OW70oLzpaTpzXD+zihVUbOJuKuwaUH3ubiFA0bqY3CcipODa a9Hy8BvdmC86MVm39eDa6UEsuLd4XVtArzkbexY/F0p/kgU4rC+Hh4TLKQJoKru0 QbuVER6xo/7r0jYdbba8pTGSt7+iBEdnSFz556mV7cr0O5vc2lpF62700uhPRYXT c/LGpKVdpXeKEFBr8aWsm1Ve1F40b70Z/6Zfxn7uRXhrw0CvJ6D1Mq0P3MaLs8W2 zxFDfu2CBnmhvGGpqhbJ9Outi2/SfLQ2VCU541G+k/y6jrVRWgs= =sfm7 -----END PGP SIGNATURE----- --gck6qnhcvmvyalgq-- From nobody Tue Dec 20 15:11:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D906129432; Tue, 20 Dec 2016 15:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 qaDSnIMuSAJZ; Tue, 20 Dec 2016 15:11:34 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C74A129422; Tue, 20 Dec 2016 15:11:34 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id g1so38484642pgn.0; Tue, 20 Dec 2016 15:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:message-id:subject:from:to:cc:date:mime-version :content-transfer-encoding; bh=zCh02vxuCVPmsnMGjlOp0cmd7FeBAthJq3bkafdI1fU=; b=Zy3DeW9O1ORVNJOajcVfvFYt38wyvu9W5OkegQigVSyLLGoAshGNdNaV4YYpOtG/4q Td3ZM93uBvavBLjwmWW2LvPhHCUp1N8TUlVGDSDsjUqgd5Z67KM6SZEOp48sl3t+ep1m z5TuTYUg9yRgLsnbB302vOCxuALLeMptI7omsG+kl4VxoFAwICX1k4symRrcFlswmvB0 Q8iEwujR1suMuMBDmVqzFLCnRqr9MFK9G8vMk908DYrPZh98k+JZJrOM5iGTZ0Af0BH4 Jn9wq9WSMF3rijkvYKeHP4YPgMX/lM0UYM0l1u0+wnZQQrcu/Xb9OGw8FabqaICfO7Di 80tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:message-id:subject:from:to:cc:date :mime-version:content-transfer-encoding; bh=zCh02vxuCVPmsnMGjlOp0cmd7FeBAthJq3bkafdI1fU=; b=XMz8DTJrArvbwXW9I3OwCcOtrJ3H39tMCjn1Td3VvEigbVMAq0vod+mXti2l4Tlvwn rGLbfUxHi4LVSB8C4WU6jnrFGPpw/h6Qn8ZO4hYDFIxPX36KqNeNTvHbwUdk4lZz1ZGO DavmbIrKAf5KBKfd2Z4AV2X7fxMImcNVHIqciaxxWTxEonO8UkEMzba3SBQI1V6qfXUD 35c2FEWE4tXKH023SKhrYKWZYBYmwtxG3bRBRWKjMOcAuG6QLskHqSeBbJX+nLIBgUts R0OA7L+uMz6JlmmKrSYwFsp4vQMJA4JI9wqkO4ApD8/UrfNIkGm0oJjCtCo67h2o85nk qwBw== X-Gm-Message-State: AIkVDXJWNVXaomkfFBMRVX2eT6D1d7PQMOwzbG6YWhfyeza31SwUwM7Td5Exr28xVQZ7jA== X-Received: by 10.99.98.2 with SMTP id w2mr2687294pgb.59.1482275493874; Tue, 20 Dec 2016 15:11:33 -0800 (PST) Received: from desktop ([103.232.159.187]) by smtp.gmail.com with ESMTPSA id t25sm41845380pgo.9.2016.12.20.15.11.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Dec 2016 15:11:33 -0800 (PST) Sender: Jan Newmarch Message-ID: <1482275487.2683.17.camel@newmarch.name> From: Jan Newmarch To: core@ietf.org, draft-ietf-core-resource-directory@ietf.org Date: Wed, 21 Dec 2016 10:11:27 +1100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jan Newmarch Subject: [core] More comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 23:11:36 -0000 Thanks for responses to my earlier queries. Just two more: Small error in 6.3? "con :=  Context (optional).  This parameter sets the scheme,          a ddress and port at which this server is available in the form          s cheme://host:port.  In the absence of this parameter the          scheme of the protocol, source IP address and source port of          the register request are assumed" The source port of the request will be a transient port. This isn't the port of the service. It should be the default port In the absence of this parameter the scheme of the protocol, source IP address register request are assumed. The port is assumed to be the default port, 5683. Relation between RD and WK/C: Resources registered with WK/C include core.rd, core.rd-lookup and core.rd-group. Nothing is said about the 'sub-resources' /{+rd-lookup- base}/{lookup-type} such as /rd-lookup/res etc. I would assume these are not meant to be visible. Should this be stated explicitly? If they could be visible, what would be their resource type 'rt'? The same with resources registered with RD such as /rd/4521. If they were visible through WK/C that would give another lookup mechanism besides the Lookup Function Set. Probably best to exclude that explicitly. The package I am using (aiocoap) makes all resources visible through WK/C, so would need changes if they are not to be visible. Thanks Jan -- Dr Jan Newmarch, Director of Higher Education (Business and ICT) @ Box Hill, Adjunct Professor @ University of Canberra E jan@newmarch.name From nobody Tue Dec 20 19:21:54 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 429A21294D5; Tue, 20 Dec 2016 19:21:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148229050926.23713.7192937139859837378.idtracker@ietfa.amsl.com> Date: Tue, 20 Dec 2016 19:21:49 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-interfaces-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 03:21:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Reusable Interface Definitions for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Filename : draft-ietf-core-interfaces-07.txt Pages : 26 Date : 2016-12-20 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, Paramter, 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 note: The git repository for the draft is found at https://github.com/core-wg/interfaces_ The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 20 19:34:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F621294C1 for ; Tue, 20 Dec 2016 19:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 0emQayppKKAF for ; Tue, 20 Dec 2016 19:34:36 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 C0B7A1294C3 for ; Tue, 20 Dec 2016 19:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nH8B5X2Ej8QJnKgL1outSc45Yc5Q9KttUQA2/VbOTko=; b=h/arzo+E2M2qfz2Ry/JqJcJGvC XJsR2/rOswTCya+G5HshGATIctUtooQXkbHWLkqoFtvNuQym7q3Kfj9ZA1DlV4563HNW12JxA7yGS N/sdOsID4uBNJrU4DZ/XC9lCcTVv+BLELPQ/1+ZhvR2pFBVO0UOdwAH2R3eTHUd6JgEiE/ROy9j4M kMiChpajZLp717uCfH/Ha48xmTLVOs2qJ1wi50WFW44lmd7ZBMAfWHRjMGPsoQ5vyO6BJ9JvTDyzT YFBNUZu+DWy8cGoorSWs0cWWXtdbKDRrU/HoSB+WJzmPoQ1U4bN+h4IgLbYGkMbxd50iwebdZtWV7 TEjM/wLA==; Received: from ppp118-209-5-98.lns20.mel4.internode.on.net ([118.209.5.98]:54202 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cJXfm-002w3x-Hd for core@ietf.org; Wed, 21 Dec 2016 14:34:34 +1100 To: core@ietf.org References: <148229050926.23713.7192937139859837378.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: Date: Wed, 21 Dec 2016 14:34:30 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148229050926.23713.7192937139859837378.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-interfaces-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 03:34:38 -0000 Hello all, FYI, I've updated the interfaces draft to remove text regarding function sets and profiles. There's also a few other fixes. Regards, Christian On 21/12/2016 2:21 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments of the IETF. > > Title : Reusable Interface Definitions for Constrained RESTful Environments > Authors : Zach Shelby > Matthieu Vial > Michael Koster > Christian Groves > Filename : draft-ietf-core-interfaces-07.txt > Pages : 26 > Date : 2016-12-20 > > 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, > Paramter, 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 note: The git repository for the draft is found at > https://github.com/core-wg/interfaces_ > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-core-interfaces-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Dec 21 03:23:11 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA84129554; Wed, 21 Dec 2016 03:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 VwlPewEJr5Ht; Wed, 21 Dec 2016 03:23:08 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC83129560; Wed, 21 Dec 2016 03:23:07 -0800 (PST) Received: from devpc ([193.51.159.254]) by mrelayeu.kundenserver.de (mreue005 [212.227.15.168]) with ESMTPSA (Nemesis) id 0MZyjz-1c0cZ43Svf-00LoaP; Wed, 21 Dec 2016 12:23:05 +0100 From: "David Navarro" To: , References: <1482275487.2683.17.camel@newmarch.name> In-Reply-To: <1482275487.2683.17.camel@newmarch.name> Date: Wed, 21 Dec 2016 12:23:01 +0100 Message-ID: <041e01d25b7c$97707e50$c6517af0$@ioterop.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKpgSPa2FgiiJJhkbRV4wbZnIttZp9j809A Content-Language: fr X-Provags-ID: V03:K0:j47JnqcVaStMQ3dyOm6d5eGQWBYfIw2te3tHNfcHCN/Ty6A0pR3 gUOBFLFjvstYPWbGYtb1JA/hZRchpf6LMbD4IpjvZFXPrBQrydf4SGFHEDqbzamkivqgSYL aa95f2AZYjKKQlHTGbJfMyHz3uL5tqnJgsbkj5VhF5sTEUnA5YnM1I4wzPh7Gr8qmhcj/c0 6PbviMkmdPsui0no8Xjng== X-UI-Out-Filterresults: notjunk:1;V01:K0:eB7NcCJBS5E=:bN/v+55Zkz8lXhjOFzdykS o0kWwBPomKCEjHSTXidce+fZoCZ896QjuzZ6Lgvio/i6N1ON1xBnh+LrBehkTRFJZbSmXus8T 9xNHfmb3pn42Ij6dnM69yzzKrPKNfIicldjmg8hBWhyC36ED0MJdcBkloqEx4Ks7Xdjdr1pyv ACGXiVLXDQIt4irncBvkfyFbv20pT/52JJ6G4c3iGdiTV0NxocXaUrxL6LwuALRegvNebdQst AbX4JzuVgmhQngUovOVoIkxDKYostRy295502eeU4PWjBVOmAEV2W5tUvkI4AacA1CbbIUVHK zMqk0C7sfC4seT0rP63u3s7k9Nh/yLaJnR0LfgCO6Qh9pTQbCP8aB7cv8O34+QCs/qzjD28d7 JZdCPhJbSZMkW0/Leco8Ww10FS1LEOhw6YCpOgf8r6MkfSmrthhFZ4Oaz0sWlLSx047C4W2kU Z2YOCGrV3szS/qeCQveaHJrHsE9ojhbkXIQoiX8Q64IAkMOL5EAfbf/y5V1WvsG7uRpt8hYY1 tgEke5nipAuzM0RH256PC51mNYKW6C3m9bDyNf/oZxz0jm/o8bQoPqWi2LZDpYxKZbXWRnNpi G+3Hkik22Vv+4r+rNiQcvFD5xnJHXdOQ5GnKLzRvURQkeAQ0mcEPDGETBHwdWr6Bmx2EtcDM1 xRmHb4GivmubWZPp1Cm870kEAa6KVsrnpA2KRvDsD/EVZwZvD5CCoYuFrmr1zhBaMt7BCO0dQ gd2Gv0eIkrJQhs7v Archived-At: Subject: Re: [core] More comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 11:23:09 -0000 Hi, Allow to join the conversation to point another small issue in the OMA = LightweightM2M example. 13.2.3. Alternate Base URI =20 If the LWM2M endpoint exposes objects at a base URI other than = the default empty base path, the endpoint must register the base URI using rt=3D"oma.lwm2m". An example link payload using alternate = base URI would be: = ;rt=3D"oma.lwm2m",,, This link payload indicates that the lwm2m objects will be placed under the base URI "/my_lwm2m" and that object ID 1 (server) is supported, with a single instance 0 existing, and object 5 = (firmware update) is supported. In current LWM2M specification, the link payload would be: ;rt=3D"oma.lwm2m",, LWM2M expects the base path to be prepended to the other URIs. This is = probably making LWM2M not RD-compliant. Regards, David Navarro=20 -----Message d'origine----- De : core [mailto:core-bounces@ietf.org] De la part de Jan Newmarch Envoy=C3=A9 : mercredi 21 d=C3=A9cembre 2016 00:11 =C3=80 : core@ietf.org; draft-ietf-core-resource-directory@ietf.org Cc : Jan Newmarch Objet : [core] More comments on draft-ietf-core-resource-directory-09 Thanks for responses to my earlier queries. Just two more: Small error in 6.3? "con :=3D Context (optional). This parameter sets the scheme, a ddress and port at which this server is available in the form s cheme://host:port. In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed" The source port of the request will be a transient port. This isn't the = port of the service. It should be the default port In the absence of this parameter the scheme of the protocol, source = IP address register request are assumed. The port is assumed to be the = default port, 5683. Relation between RD and WK/C: Resources registered with WK/C include core.rd, core.rd-lookup and = core.rd-group. Nothing is said about the 'sub-resources' /{+rd-lookup- = base}/{lookup-type} such as /rd-lookup/res etc. I would assume these are = not meant to be visible. Should this be stated explicitly? If they could = be visible, what would be their resource type 'rt'? The same with resources registered with RD such as /rd/4521. If they = were visible through WK/C that would give another lookup mechanism = besides the Lookup Function Set. Probably best to exclude that = explicitly. The package I am using (aiocoap) makes all resources visible through = WK/C, so would need changes if they are not to be visible. Thanks Jan -- Dr Jan Newmarch, Director of Higher Education (Business and ICT) @ Box Hill, Adjunct = Professor @ University of Canberra E jan@newmarch.name _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Dec 22 15:20:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5893129628 for ; Thu, 22 Dec 2016 15:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 TPsUfbWmlcay for ; Thu, 22 Dec 2016 15:20:49 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B06C12960B for ; Thu, 22 Dec 2016 15:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZcL1ERgv5Mon6U7iKYfxMaWxcRKMdy0n7HmkG+sM2SQ=; b=h+sbge/SBj3uKXAD9pNzLajpFWtd8esZ0puOuvd8FzpA54kykkzYO8fQZhsJ3hc4JwH15CkCXdNlzuG+UN/Iw72e7EELee16CGUCJhUb0+Xr3LrQaRb2NmBNnr9S6aLRNJbkMNnoAriv8mMORDV9raBZlokfTUUVRraLHsLbZiU= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by MWHPR03MB2445.namprd03.prod.outlook.com (10.169.200.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 22 Dec 2016 23:20:47 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0803.015; Thu, 22 Dec 2016 23:20:46 +0000 From: Brian Raymor To: "core@ietf.org WG" Thread-Topic: Securing coap-tcp-tls Thread-Index: AdJcpRDdSlKL1bwuQ0m25+zFtG6gsg== Date: Thu, 22 Dec 2016 23:20:46 +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=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: 375c0fae-b0a8-4dc8-2042-08d42ac128e4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR03MB2445; x-microsoft-exchange-diagnostics: 1; MWHPR03MB2445; 7:1O6MOnXi0b0zvr3GPwCXihvs2c30agfR3hbFe/Wko0OXc7JDqonGbgI0DLGhLq3uJ0xZDdLMhEAqp5TNYnBzFrjeMQLfqSJrAGikRiv43imRZZsS2lmWJkb4fZ+h0RcIizfzRq3o6YrzJ+i5j2HgxXnqXVsTTE4m2UzHDzYaRLkjRlyFg6deLBNZ2AeWGmyDlyohNeYaubUdiBHrNzJZUsBs9kj8Y12nKN9Mb2Kl5S9KDMfpO18qZbb9hYoYQmsILmk14fYL0JzSmIseRf8hWLE3hx9voUPM3otvOd99OuIgGoanPvB9pnE3XJrJd4RDvqUX1cuF53BixkZOI8wJzK3tR5FCbB4aMITCOuD/f4so19OYtN7GSMKTZvKrENFhQ7N6Uu5TX9pAhCvlCHRF3lnV/6bvPQEZgd6ElbILk+guyV9fOHwpsWwKxmlb5gPMkIEutVh2dW0GSU/VssUYJXdrbEkAY60kWeuYbZzzLwg= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6047074)(6042181)(6072148); SRVR:MWHPR03MB2445; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2445; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(50986999)(4326007)(25786008)(606005)(54356999)(6506006)(230783001)(6436002)(561944003)(38730400001)(92566002)(9686002)(77096006)(122556002)(4001430100002)(2906002)(99286002)(68736007)(66066001)(76576001)(3280700002)(105586002)(6916009)(106356001)(7906003)(81156014)(81166006)(97736004)(10090500001)(110136003)(101416001)(74316002)(5005710100001)(3846002)(8936002)(6116002)(7696004)(790700001)(8676002)(10290500002)(102836003)(107886002)(3660700001)(2900100001)(86362001)(33656002)(7736002)(8990500004)(5660300001)(86612001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2445; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB23802864A5545B972020826283920CY1PR03MB2380namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 23:20:46.7725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2445 Archived-At: Cc: Hannes Tschofenig , Juan Perez Subject: [core] Securing coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 23:20:52 -0000 --_000_CY1PR03MB23802864A5545B972020826283920CY1PR03MB2380namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies for the long delay in preparing this proposal. An extended illnes= s after Seoul conspired against me. Following the security discussion for coap-tcp-tls at IETF 97, G=F6ran and = I have been iterating on more nuanced text. I've applied the changes to the editor's draft, but kept - https://g= ithub.com/core-wg/coap-tcp-tls/issues/11 - open for tracking and further updates until there's broader agreement. Summary of Changes: * Added a "Securing CoAP" section which is a mind-meld between the related = RFC7252 section and the RFC7925 profile. The draft attempts to avoid too much duplication, but may be too minimal = for some tastes. * Added an informative reference to draft-ietf-core-object-security to illu= strate an alternative approach * Added an informative reference to Security Challenges for the Internet of= Things from the IAB workshop There is one question that needs broader review. In RFC7252, the NoSec and = RawPublicKey modes were mandatory-to-implement. Should this requirement be maintained for coap-tcp-tls ? For the moment, th= e current draft follows the direction of RFC7925: The mandatory-to-implement functionality will depend on the credential type used with IoT devices. 7. Securing CoAP Security Challenges for the Internet of Things [SecurityChallenges] recommends: ... it is essential that IoT protocol suites specify a mandatory to implement but optional to use security solution. This will ensure security is available in all implementations, but configurable to use when not necessary (e.g., in closed environment). ... even if those features stretch the capabilities of such devices. A security solution MUST be implemented to protect CoAP over TCP and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over TCP when appropriate. Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see [I-D.ietf-core-object-security]). 7.1. TLS binding for CoAP over TCP The TLS usage guidance in [RFC7925] applies. During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials, access control lists, and authorization servers. At the end of the provisioning phase, the device will be in one of four security modes with the following information for the given mode. The "NoSec" mode in mandatory-to-implement for the TLS binding. The remaining mandatory-to-implement mode depends on the credential type used with the device. "PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-implement for the TLS binding. NoSec: TLS is disabled. PreSharedKey: TLS is enabled. The guidance in Section 4.2 of [RFC7925] applies. RawPublicKey: TLS is enabled. The guidance in Section 4.3 of [RFC7925] applies. Certificate: TLS is enabled. The guidance in Section 4.4 of [RFC7925] applies. In the "NoSec" mode, the system simply sends the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. The other three security modes are achieved using TLS and are indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port. --_000_CY1PR03MB23802864A5545B972020826283920CY1PR03MB2380namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Apologies for the long delay in preparing this propo= sal. An extended illness after Seoul conspired against me.

 

Following the security discussion for coap-tcp-tls a= t IETF 97, G=F6ran and I have been iterating on more nuanced

text.  I’ve applied the changes to the ed= itor’s draft, but kept - https://githu= b.com/core-wg/coap-tcp-tls/issues/11 - open

for tracking and further updates until there’s= broader agreement.

 

Summary of Changes:

 

* Added a “Securing CoAP” section which = is a mind-meld between the related RFC7252 section and the RFC7925 profile.=

  The draft attempts to avoid too much duplicat= ion, but may be too minimal for some tastes.

 

* Added an informative reference to draft-ietf-core-= object-security to illustrate an alternative approach

* Added an informative reference to Security Challen= ges for the Internet of Things from the IAB workshop

 

There is one question that needs broader review. In = RFC7252, the NoSec and RawPublicKey modes were mandatory-to-implement.=

Should this requirement be maintained for coap-tcp-t= ls ? For the moment, the current draft follows the direction of RFC7925:

 

   The mandatory-to-implement functionality will= depend on the

   credential type used with IoT devices.= <= /o:p>

 

 

7.  Securing CoAP

 

   Security Challenges for the Internet of Thing= s [SecurityChallenges]

   recommends:

 

      ... it is essential that Io= T protocol suites specify a mandatory

      to implement but optional t= o use security solution.  This will

      ensure security is availabl= e in all implementations, but

      configurable to use when no= t necessary (e.g., in closed

      environment).  ... eve= n if those features stretch the capabilities

      of such devices.=

 

   A security solution MUST be implemented to pr= otect CoAP over TCP and

   MUST be enabled by default.  This docume= nt defines the TLS binding,

   but alternative solutions at different layers= in the protocol stack

   MAY be used to protect CoAP over TCP when app= ropriate.  Note that

   there is ongoing work to support a data objec= t-based security model

   for CoAP that is independent of transport (se= e

   [I-D.ietf-core-object-security]).<= /span>

 

7.1.  TLS binding for CoAP over TCP=

 

   The TLS usage guidance in [RFC7925] applies.<= o:p>

 

   During the provisioning phase, a CoAP device = is provided with the

   security information that it needs, including= keying materials,

   access control lists, and authorization serve= rs.  At the end of the

   provisioning phase, the device will be in one= of four security modes

   with the following information for the given = mode.  The "NoSec" mode

   in mandatory-to-implement for the TLS binding= .  The remaining

   mandatory-to-implement mode depends on the cr= edential type used with

   the device.  "PreSharedKey", &= quot;RawPublicKey", or "Certificate" is

   mandatory-to-implement for the TLS binding.

 

   NoSec:  TLS is disabled.

 

   PreSharedKey:  TLS is enabled.  The= guidance in Section 4.2 of

      [RFC7925] applies.

 

   RawPublicKey:  TLS is enabled.  The= guidance in Section 4.3 of

      [RFC7925] applies.

 

   Certificate:  TLS is enabled.  The = guidance in Section 4.4 of

      [RFC7925] applies.

 

   In the "NoSec" mode, the system sim= ply sends the packets over normal

   TCP which is indicated by the "coap+= tcp" scheme and the TCP CoAP

   default port.  The system is secured onl= y by keeping attackers from

   being able to send or receive packets from th= e network with the CoAP

   nodes.

 

   The other three security modes are achieved u= sing TLS and are

   indicated by the "coaps+tcp" sc= heme and TLS-secured CoAP default

   port.

--_000_CY1PR03MB23802864A5545B972020826283920CY1PR03MB2380namp_-- From nobody Fri Dec 23 07:08:25 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4CA129453 for ; Fri, 23 Dec 2016 07:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0vi28jv6MHE for ; Fri, 23 Dec 2016 07:08:20 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20103.outbound.protection.outlook.com [40.107.2.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF1E1293F4 for ; Fri, 23 Dec 2016 07:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=314QoGcI3Z98rV+0tBEswoHuXAGXKRfkxBxIkKkoPlw=; b=d5RaCS8psZwj9I6HgrxBs0rhCDte5umGBo2YCSFWWJj+QZm2GZsYuuxIDa/GPoPhK74SXWPes5URacGPo9WqCMBFB63aO4ssiFwiQ7M5d+vJ8fn8/6oBgMy4nGoSKxxV283cMcb4u19+aB0g92f1FOPHugdByV3sK+HlLk56N3c= Received: from HE1P122CA0004.EURP122.PROD.OUTLOOK.COM (129.75.100.146) by AM3P122MB0018.EURP122.PROD.OUTLOOK.COM (129.75.100.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.15; Fri, 23 Dec 2016 15:08:16 +0000 Received: from DB3FFO11FD003.protection.gbl (2a01:111:f400:7e04::183) by HE1P122CA0004.outlook.office365.com (2603:10a6:23:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.15 via Frontend Transport; Fri, 23 Dec 2016 15:08:16 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; ioterop.com; dkim=none (message not signed) header.d=none;ioterop.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by DB3FFO11FD003.mail.protection.outlook.com (10.47.216.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10 via Frontend Transport; Fri, 23 Dec 2016 15:08:15 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0172.MGDPHG.emi.philips.com (141.251.190.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Fri, 23 Dec 2016 15:08:14 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0789.018; Fri, 23 Dec 2016 15:08:14 +0000 From: "Dijk, Esko" To: David Navarro Thread-Topic: [core] More comments on draft-ietf-core-resource-directory-09 Thread-Index: AQHSWxZx2cpzK8S5SUC9CspaB4WrTqESQwCAgANiXhA= Date: Fri, 23 Dec 2016 15:08:14 +0000 Message-ID: <78bf826408554382b5387551dfecec40@HE1PR9001MB0170.MGDPHG.emi.philips.com> References: <1482275487.2683.17.camel@newmarch.name> <041e01d25b7c$97707e50$c6517af0$@ioterop.com> In-Reply-To: <041e01d25b7c$97707e50$c6517af0$@ioterop.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.138.53] X-MS-Office365-Filtering-Correlation-Id: 4ed98072-7278-4cec-020a-08d42b45856f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9001MB0172.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39840400002)(39410400002)(39850400002)(2980300002)(428002)(55784002)(13464003)(85714005)(55904004)(189002)(199003)(374574003)(6916009)(38730400001)(229853002)(2950100002)(110136003)(189998001)(5660300001)(626004)(47776003)(97736004)(7696004)(24736003)(102836003)(4326007)(50466002)(69596002)(108616004)(2906002)(230783001)(86362001)(7736002)(356003)(2900100001)(305945005)(3846002)(66066001)(92566002)(33646002)(101416001)(68736007)(106466001)(23676002)(6116002)(81166006)(81156014)(8936002)(50986999)(76176999)(8676002)(105586002)(54356999)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3P122MB0018; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD003; 1:YhvJp7y+XYE/Y59ZbkD1rr8sFXKf0e/M6y+7Z+IjDat+vJNbOZ7O1lTURVOX2xuojh79hfx3toUSZUWJ70ZBxH95KAxKmP+LBZ9d01fMZTcD1uinBIy6HhjzmkehZc2hZDYF9HT3w6Ct9Pm74X9Ns6CBt0n+hyIaZaxr8hyLY/1cI8XQc+r+RQw+Px3780bTXVTyZ+4bYCm2i7bK9SVH3WcBdFu3I8GEcebPMo4p49D2m5WvzWhZgWCk6ripYwukSkmvDiI2htS6lYUHZXNNx1v5WNBqfNqHYqX+w/NQR6seFB0eKIhfBG+gDYUBBUQl5z6jzzIySCiRNztWP9I9jfxezUQEOjaaAt4naH3NwaJCrrCUttkAAH6mDnXHpR1+PGQpElswzZijY+aDFVdvlvp71HrUIplpzIQwOKCdxB+NbBMm/mvbOpP8gCaR4q0ASVFcl8lsa7MinVxs7TwjdxI8X4TXP7kT0xKKAeQ8mEKMRmr2Tk5gjQwmBycn9d50VmvaDg1ISJZWqNRHk7uyxQ== X-CrossPremisesHeadersPromoted: DB3FFO11FD003.protection.gbl X-CrossPremisesHeadersFiltered: DB3FFO11FD003.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3P122MB0018; X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0018; 3:/P4XBrxbXZJL+/0xzDa166txFkVy0Hy/0jB32td4bUFS1LjmAGrUSw+Q3g/cxP0rtXXfKB4/jlPacY4qDNb2J3RZacuZtJ0mlXlx5+kARHlYmq0WR94TcWXhuxRp3/sDNuhwrzPNoCXwYnWIe/kawLreAz8bmgRiK9ZeJOoABleABlXb4K8lc3NDgKCwcAYKkutSi1om17VR+Y++zKj29ITpFP/Y31B9b/enTSkyy0j2fSjymJEE/OQGU7PPy+999h/WVv+V7+/+FGamY/41g1EhNJLpGujicXv4nZEvf0Ndh8tw08H5hTWCM+goLAZkUcR2gYDb/TMAlOVYXB5Ek0kIjsyACHNU7XgzYCU4llU=; 25:fCY1ANlvYe9s+cQzor/dV0imi30zl1BjSe1Eq/DVYZtoZfr2hoKTTWAcbB/OZuqMXtK1f6NB6+FA7+icyi5Wq6WjEAOw+jf9oTG552TMn3hRfJ9KSM9LU3T3Mkk8Izm0RXk8es373Zo7yhmZwJN6yN5dwqPpsTWIf9ZzA2tJkak2J4rOB7V06drQhNQFxt9PqqqBAdhs2xvjX4ioQn52gwZcCNL9/J5HGv8yNACB4aBLlXujUuKJxpCPoxlgvi315JjiRbodhJsk+rt43XxIOF6mISKObmvphJ7UHfuGA7JvmayhGpK89zXguAoRCeV9cg2htlGksx1LHq6CquDC5f4hqdJnOzpbLDPYO1T9gQuHIIsqVW7rUM5SUPT1BJuHH9q/DhBps2FMz97pUIDJP9zwOk6esnmT7GOOHJirMxUjvtDKvTy/4YHhKv+7nU+C6lvf5cVRvRq2m8axHFGR5A== X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0018; 31:m5VuMFMVZKiyaEUsSnfwNmjcZ+41IG6ECRsb+0cSCz626b3Hr+gA2pzSk49sFzS69BIgtlXcVVbj8RROEz2kxFoTwtKTWYKC012lON6Ot4vHw/3Ur3RrbgNQNqvE6SNpDY5k0WtRspozBVGjjOwA5/E2tjpxJ7ib2xFqzY0wuyWg56wqNc14wPzmz7pB+HlUISd/fkQU8FaO5AbyetjwvlCt4IVjV/+zy68epvG2FtC6F5QWDq0VREQhXWxlsdbzda4ZXRCSXEKKOcwobgQ/nvBrSZzf7Jkiia9pbrvZN6k=; 20:vZ09idDVenNZCf4QadljHhepfgtsjwuk8vqBJWfVO1Fg0yuNL/Bg640gEglRuXaLTNdPFWwU8A8caLFjIvlxe2rnPqKOhRlTb6WIbJK5HN6r5vETKN+qy8OdtzW57xsHb7vAh+/mOLe6Jf3Jk/dbaTqwdANtRPRTD+m4dz8dOCYCV4jirjv88ubOKwF3N5XLuYaY0cyYXpQ11Pc+8ubTfOEzzL5szLgpyofUs0PTnAIiLwb6ZH5qgm+VQM8+aBXGkY8UBCwilj/rEXIYfwaccxUKJWOLp10U8EYv/8Bhd7ipwXtRbrwOBjtwbmTZORY4PvnufKao0vM3ZWuZNmpmil+yg/rKbb0ODLcVib7C2bFb95j35RTVxRCp8VzYHfICZ/IqcGE6PPHUR5WLcRyHb0BvOFAgnqFWsikTyQx4I4y+kIocIBwx73hCRfhURxIOIoomHrqMIIIKzb72JKlxlRINT3dMGL6vTjxRcirwCX4Joh9+dF6obmxHn8vRq6AS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(13016025)(13018025)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:AM3P122MB0018; BCL:0; PCL:0; RULEID:; SRVR:AM3P122MB0018; X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0018; 4:tuj6Wl1CX2U3WSdoti1z8ex5echndwTdrHZtuaP/p9qoUBbu4q3UJUi8+yUwXPkrQ1wzSFoENCDuwIbKnWFdVPZ9XAP8pGT2pGYEHjdLzOXDSOYFnPoT7+5rqGWDbSYKTV9avE9t7oovPWTWATCmlyT5gNsqUZEO0wFhPfMAO4SRSRF6WelztTMoDanVDxp96YrH+EjMXtXeiKxsMukv8K5fq+bGkEw311OmMM1SI2Q81Fnow43GycDqDws4VMVbaCMmAFs5KkmdGYKGxNztyeo6OXWmbfklafTuEcIqRNgFJQ/wzk1VqOv0hJgfe+OByyYtjybQldSSlt/hIJewRM2yy/KkJZzWH+h7F4IDrasHGYT7DJiZ05l0y0QtNTmCvLXp6472IpSiAMJpAnpueRxvhUuJrBn48//WBWMywI7rbsrdUUV/b6JsQafvpRXaXiyL9Krvv1tvDT2lj27cApl+xbxirrUymdkF73EjXvi7Ul3zisx4bZ3D5taYNUcABQrbCVno8lr/+q0hMOyymIeBSxM0xFiQMbnfj4KdA/0sVYtRRwdztYiRUysdf6VDq4PKFhRY/X3clelPcTKuN/VKV0bYv0ARPXGUz+GXvTw3d9CTiS8tdhOj/ROLkam+aDsvbb96/2fDQBi+VDIK8tlqjUDYdsMOm+f1A8KOQeY= X-Forefront-PRVS: 016572D96D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQMTIyTUIwMDE4OzIzOllIVm0rYTVXQ2p6dmxzZEU1QTRyUnAyUG83?= =?utf-8?B?SWNQQUZrZVBZQjJ1eDkzeU5KQVJGbGNOR0RQSGZHdWFLRmhneTlhWjE1czdD?= =?utf-8?B?dWFpc2k5MzZmb3BaMW9SS29laUs0T2M1QTJ2a3dCNFJ5Y0YrTnBHOHB6M0Yx?= =?utf-8?B?c3RqbGZJYmFuMkwwL2NNZ0xtZThBNjRTQzZwYS9nS1NCWjFLck5wdEZwZjlR?= =?utf-8?B?TjVlaDhncElranJRMkxWZnVPcjJFM0FJOVE3TzFIeFRtbFRwNlFSVXlmSUhC?= =?utf-8?B?TVJTNUdTbW1iZXp0cUNIM0Y2cG9NZkRpcmhQc2FWSVEyOEZ5WjNMQ0JWZU9u?= =?utf-8?B?TnRtVzRSdDFpVkQ1T1IreGxuL2I1Nm1zckQyM3JLRjlXS3FtcUIxMEF3WTJl?= =?utf-8?B?SWFuRzZMd0Y5K3Qya3BCaHRtSGlFc3pKY1NBdkNOVmZNRWJabmhyWmVhVUJL?= =?utf-8?B?eDBMRFUrTDJwTkR3V3BDRDBVcUIzMUdOYmRNaUlqckJMQy9UR2tpNnJOdlNS?= =?utf-8?B?ZTc4VlkxQjI5d3pNdmRLdVY0cmhKWnVoMWZXSFV6K1doQTdQbU81ZnJzMVhs?= =?utf-8?B?Ti9pdDhhRXl2S29XZlBVWEthdUdBbVgxeFZLa0hrMk9rMUxTa3k1eU14RmVU?= =?utf-8?B?cHlSeU4yLzdtWlpLZUtrMTlXaUxSMU5FMnVmWmVQMUpzQU5PSmtIWmlURnli?= =?utf-8?B?cUxWZlpwVTZCeXhDcXIwUnYySTk5VlV4dThEY3gvU3NqeGt0MHVSVGRZNTc0?= =?utf-8?B?OEg2YVVNK003S00rNHNFSzhrd2c2VGxicExVdTU2bmM4NU5JdFVPcm9tdEtZ?= =?utf-8?B?T25HWWFjbDdjUk44eVpJL29oN1E0RVRnSUtEVTBBTDZOM1dLdm1nYk02NjV3?= =?utf-8?B?WDkxeGVKa214UFcwaS9GZit6SVVObVF5SkZ5TUNjYjMvUjA0dGUwVGRLTWx1?= =?utf-8?B?bFFPcWdUWFd0MWhNOWNqMG9KTWp4UlRWcGRhUWlxOXhaazIxSTlWbTJHVm9X?= =?utf-8?B?WS83VC9FVHBrb242dUpYMFdIOFM0cmI1WGRRM1htMjZNYmcxeVZ5c21MU0Nj?= =?utf-8?B?M3BudkF6dW9YQ1FoSiswYlR5Slp0QVd3VWxVMkxZU052Vmd3MkFCV3lYUUlK?= =?utf-8?B?UWhmRzVqMnJNV1E5dyt4N2VBSDVGZzNpTUxwK0NsenViQ3VHKzE0V3o4bEV3?= =?utf-8?B?SzBBZ3ZmODBqRE1FRkJOc3k0RFpNWXFjOXZkR0hGbXNPd3RoSGFkV0Nna2RG?= =?utf-8?B?dkF3Z1RvOGZRd1YzckNQZmY4VHlyMXJWMmx0NW1BdGhZU2E2WnlGcWNoWnJW?= =?utf-8?B?bGlnT05INXJXV1dtd09KQ0k3VU9yUWdvOWM1Mnk5VHU3bHZNV0V0Y0FBcmdi?= =?utf-8?B?TlVvZWUzQnFjTzFxNVovOWsrUmt3bXd3NVl5M3ZHWWY4TlJQU1pHTlN1Z0NR?= =?utf-8?B?eWtheVlyQ2E3bjlDNzRaelNPeDZ1UWlNQzlhTXhNZE9Nd3lmYlFrV2NVL1Zi?= =?utf-8?B?OXR4NmlRaVhiQklmZjE2aVVZMTlFVzRhUUpuaWtoZkt5UGQ4STgwOURhaEdk?= =?utf-8?B?WUNvTkdUWS81TjNnMEV0K2RuVFNXWUNKK0FWakxzbHJERmlRYlo5VENhanpj?= =?utf-8?B?WXR5L1AxUlJpWjNDZ2JwYzM2bzdxQXF6NWxXT3JmNWI2VzBjUzJaaGZkUnU1?= =?utf-8?B?dXBYemlQVjVIdXM2RTBiZ2hPYjgySnZoMGlsT1Zmc1ZCQkxmdkVmOTJwanFU?= =?utf-8?B?SkE1WHN6U0tNeTVNQmsrS1NLazEwTVV1SmpaWlV6UzFUei82OURFSWdOVU9Z?= =?utf-8?B?aFNCL1cyNlRZWHppYmd2WE94dTRiODVKU2MyYVRmVERRZ1B6U3Qzak4yZFdF?= =?utf-8?Q?0DHU3b42Oeo=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0018; 6:iBSv9TRS6RoN+3s3mjn/VIVNCMJkExR024f9SBMjTSqQvPLZh3VAgjr39bGRxuIm94CIS0Nn1B1tFWjYFioXh9dCvdkV1H/gWqzh0VcIobB5wkV+eMZYSJS1WCu+8o9K0cEmd1H6q9a4xc76BJ7/qElyTOAutwyUQJv2vp7b+/QLhCvbAzF9oK+lYymVRtI+C3uWqBEFPbXWEw5WF+LPdpGtixbzHf9TJ4ANLUDvzIvvXYOWGu14JsQk5pT6nmVoaZ8RGUoKeQjRfWab5sdDhlw2QwJv5x2pJUO7AdBi5SEYHxOgc/fjXuV+TuV8lKXEDEegD2fYoCmntJHNF9Iyk9hB3rBnhoRsC1xe3leAEfeEBP5azBvYZePNDrigN+jsFAdVwET845G39VXBS5s2MGRe02i9Cn9jdpPCL/oS1bpU+9C+bgx1KD+YIacClbCfu5ZIC/sm9bJCyjsA4BTFig==; 5:2hJ1KGo4LRZqHlCsdFD4+To3+5NgVy689JjAt5EgJwYk7LpqTjykP2hU9JPof1vObMknjWyaRbxiPIIfqGJIar5kMer4FleCSzotQQ1W5efzjQNFoyO5ZR2WYGrIXZ3EFqaoQRRJFEjsONCzsB63qg==; 24:XIT1NiQ5g1S6jFAmZej4mi9ILCXEr+nr1j6Vw/0hnJr18Wpm49dPUTrR4W4srtY2V5bmyQsfAOiqJtG8/uGJrJTGCQOY9z/J+qUVb9sMxTk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0018; 7:Z4A/Z6yPpvEhJljg+uR1u3jMpZPeT6HVJClw1hiAE4Fhhc+lTXJXzcOe0C4SEO2VB+gNlfdvptnLYGNSKV58SQkfHTojrG3Wprek30oNdC3mAWSpMvW6BSb6Y8Z5MXfvw3erkdTtSMzge5QATvg4M2UENdrLmTvdm2qa69PbQIm9LqWUaJ/A+eSuyyfklTb0AeXPJv37buF36/W5oGGXdCldiclOG8pmsIiuDBl0ctGsawEZsqVg+/Ubxz9b8qWKb+dLygZjg0251d6Xoq4+8x4L4Kq9AYt7Z6BBB7AaN52ArE9GmdjA4wZz+jYswyrY8zzaJaqYnpbdjnHVL5x1AATFav8r1XGFZlK+zvnEgl2pQglz/yBe6fd9+z+cx7MUWLoRDE0vsQGl1Fg34u1bIDZRGj+2zWTxu2ye5Qu1eZf4EkFGdvYnOstCr82D0RoF1CKQPUIk2vp2kt2qjz6W4w== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2016 15:08:15.5593 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3P122MB0018 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR9001MB0170.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 83.85.138.53 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: AM3P122MB0018.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "core@ietf.org" Subject: Re: [core] More comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 15:08:23 -0000 SGVsbG8gRGF2aWQsDQoNCmluIGZhY3QgdGhlIGV4YW1wbGUgb24gcGFnZSAyNyAodG9wKSBvZiB0 aGUgTGlnaHR3ZWlnaHQgTTJNIHNwZWMgMS4wIGlzIHdyb25nLiBUaGF0IGV4YW1wbGUgZG9lcyBu b3QgY29tcGx5IHRvIFJGQyA2NjkwIGFzIGl0IGNsYWltcyB0by4gU2luY2UgdGhlIHNwZWMgZG9l cyBub3Qgc3BlY2lmaWNhbGx5IHN0YXRlcyBpdCBkZXZpYXRlcyBmcm9tIFJGQyA2NjkwLCBJIGhh dmUgdG8gYXNzdW1lIGl0IGlzIGFuIGVycm9yIGluIHRoZSBleGFtcGxlIGFuZC9vciBlcnJvciBp biBpbnRlcnByZXRhdGlvbiBvZiBSRkMgNjY5MC4gT2YgY291cnNlIEkgY2FuIHVuZGVyc3RhbmQg dGhhdCB0aGlzIGVycm9yIHJlYWxseSBoZWxwcyBpbiBnZXR0aW5nIHRoZSBwYXlsb2FkIHNpemUg ZG93biAuLi4gb25lIG9mIHRoZSBnb2FscyBvZiBMV00yTS4NCg0KVGhlIGV4YW1wbGUgaW4gdGhl IFJEIGRyYWZ0IGlzIGNvcnJlY3QuDQoNCnJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEYXZpZCBOYXZhcnJvDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDIxLCAy MDE2IDEyOjIzDQpUbzogY29yZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRp cmVjdG9yeUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBNb3JlIGNvbW1lbnRzIG9uIGRy YWZ0LWlldGYtY29yZS1yZXNvdXJjZS1kaXJlY3RvcnktMDkNCg0KSGksDQoNCkFsbG93IHRvIGpv aW4gdGhlIGNvbnZlcnNhdGlvbiB0byBwb2ludCBhbm90aGVyIHNtYWxsIGlzc3VlIGluIHRoZSBP TUEgTGlnaHR3ZWlnaHRNMk0gZXhhbXBsZS4NCg0KICAgIDEzLjIuMy4gIEFsdGVybmF0ZSBCYXNl IFVSSQ0KDQogICAgICAgSWYgdGhlIExXTTJNIGVuZHBvaW50IGV4cG9zZXMgb2JqZWN0cyBhdCBh IGJhc2UgVVJJIG90aGVyIHRoYW4gdGhlDQogICAgICAgZGVmYXVsdCBlbXB0eSBiYXNlIHBhdGgs IHRoZSBlbmRwb2ludCBtdXN0IHJlZ2lzdGVyIHRoZSBiYXNlIFVSSQ0KICAgICAgIHVzaW5nIHJ0 PSJvbWEubHdtMm0iLiAgQW4gZXhhbXBsZSBsaW5rIHBheWxvYWQgdXNpbmcgYWx0ZXJuYXRlIGJh c2UNCiAgICAgICBVUkkgd291bGQgYmU6DQoNCiAgICAgICA8L215X2x3bTJtPjtydD0ib21hLmx3 bTJtIiw8L215X2x3bTJtLzE+LDxteV9sd20ybS8xLzA+LDxteV9sd20ybS81Pg0KDQogICAgICAg VGhpcyBsaW5rIHBheWxvYWQgaW5kaWNhdGVzIHRoYXQgdGhlIGx3bTJtIG9iamVjdHMgd2lsbCBi ZSBwbGFjZWQNCiAgICAgICB1bmRlciB0aGUgYmFzZSBVUkkgIi9teV9sd20ybSIgYW5kIHRoYXQg b2JqZWN0IElEIDEgKHNlcnZlcikgaXMNCiAgICAgICBzdXBwb3J0ZWQsIHdpdGggYSBzaW5nbGUg aW5zdGFuY2UgMCBleGlzdGluZywgYW5kIG9iamVjdCA1IChmaXJtd2FyZQ0KICAgICAgIHVwZGF0 ZSkgaXMgc3VwcG9ydGVkLg0KDQpJbiBjdXJyZW50IExXTTJNIHNwZWNpZmljYXRpb24sIHRoZSBs aW5rIHBheWxvYWQgd291bGQgYmU6DQogICAgPC9teV9sd20ybT47cnQ9Im9tYS5sd20ybSIsPC8x LzA+LDwvNT4NCg0KTFdNMk0gZXhwZWN0cyB0aGUgYmFzZSBwYXRoIHRvIGJlIHByZXBlbmRlZCB0 byB0aGUgb3RoZXIgVVJJcy4gVGhpcyBpcyBwcm9iYWJseSBtYWtpbmcgTFdNMk0gbm90IFJELWNv bXBsaWFudC4NCg0KUmVnYXJkcywNCkRhdmlkIE5hdmFycm8NCg0KLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQpEZSA6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgSmFuIE5ld21hcmNoIEVudm95w6kgOiBtZXJjcmVkaSAyMSBkw6ljZW1icmUgMjAx NiAwMDoxMSDDgCA6IGNvcmVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29yZS1yZXNvdXJjZS1kaXJl Y3RvcnlAaWV0Zi5vcmcNCkNjIDogSmFuIE5ld21hcmNoIDxqYW5AbmV3bWFyY2gubmFtZT4NCk9i amV0IDogW2NvcmVdIE1vcmUgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRp cmVjdG9yeS0wOQ0KDQpUaGFua3MgZm9yIHJlc3BvbnNlcyB0byBteSBlYXJsaWVyIHF1ZXJpZXMu IEp1c3QgdHdvIG1vcmU6DQoNClNtYWxsIGVycm9yIGluIDYuMz8NCg0KImNvbiA6PSAgQ29udGV4 dCAob3B0aW9uYWwpLiAgVGhpcyBwYXJhbWV0ZXIgc2V0cyB0aGUgc2NoZW1lLA0KICAgICAgICAg YQ0KZGRyZXNzIGFuZCBwb3J0IGF0IHdoaWNoIHRoaXMgc2VydmVyIGlzIGF2YWlsYWJsZSBpbiB0 aGUgZm9ybQ0KICAgICAgICAgcw0KY2hlbWU6Ly9ob3N0OnBvcnQuICBJbiB0aGUgYWJzZW5jZSBv ZiB0aGlzIHBhcmFtZXRlciB0aGUNCiAgICAgICAgIHNjaGVtZQ0Kb2YgdGhlIHByb3RvY29sLCBz b3VyY2UgSVAgYWRkcmVzcyBhbmQgc291cmNlIHBvcnQgb2YNCiAgICAgICAgIHRoZQ0KcmVnaXN0 ZXIgcmVxdWVzdCBhcmUgYXNzdW1lZCINCg0KVGhlIHNvdXJjZSBwb3J0IG9mIHRoZSByZXF1ZXN0 IHdpbGwgYmUgYSB0cmFuc2llbnQgcG9ydC4gVGhpcyBpc24ndCB0aGUgcG9ydCBvZiB0aGUgc2Vy dmljZS4gSXQgc2hvdWxkIGJlIHRoZSBkZWZhdWx0IHBvcnQNCg0KICAgIEluIHRoZSBhYnNlbmNl IG9mIHRoaXMgcGFyYW1ldGVyIHRoZSBzY2hlbWUgb2YgdGhlIHByb3RvY29sLCBzb3VyY2UgSVAg YWRkcmVzcyByZWdpc3RlciByZXF1ZXN0IGFyZSBhc3N1bWVkLiBUaGUgcG9ydCBpcyBhc3N1bWVk IHRvIGJlIHRoZSBkZWZhdWx0IHBvcnQsIDU2ODMuDQoNClJlbGF0aW9uIGJldHdlZW4gUkQgYW5k IFdLL0M6DQoNClJlc291cmNlcyByZWdpc3RlcmVkIHdpdGggV0svQyBpbmNsdWRlIGNvcmUucmQs IGNvcmUucmQtbG9va3VwIGFuZCBjb3JlLnJkLWdyb3VwLiBOb3RoaW5nIGlzIHNhaWQgYWJvdXQg dGhlICdzdWItcmVzb3VyY2VzJyAveytyZC1sb29rdXAtIGJhc2V9L3tsb29rdXAtdHlwZX0gc3Vj aCBhcyAvcmQtbG9va3VwL3JlcyBldGMuIEkgd291bGQgYXNzdW1lIHRoZXNlIGFyZSBub3QgbWVh bnQgdG8gYmUgdmlzaWJsZS4gU2hvdWxkIHRoaXMgYmUgc3RhdGVkIGV4cGxpY2l0bHk/IElmIHRo ZXkgY291bGQgYmUgdmlzaWJsZSwgd2hhdCB3b3VsZCBiZSB0aGVpciByZXNvdXJjZSB0eXBlICdy dCc/DQoNClRoZSBzYW1lIHdpdGggcmVzb3VyY2VzIHJlZ2lzdGVyZWQgd2l0aCBSRCBzdWNoIGFz IC9yZC80NTIxLiBJZiB0aGV5IHdlcmUgdmlzaWJsZSB0aHJvdWdoIFdLL0MgdGhhdCB3b3VsZCBn aXZlIGFub3RoZXIgbG9va3VwIG1lY2hhbmlzbSBiZXNpZGVzIHRoZSBMb29rdXAgRnVuY3Rpb24g U2V0LiBQcm9iYWJseSBiZXN0IHRvIGV4Y2x1ZGUgdGhhdCBleHBsaWNpdGx5Lg0KDQpUaGUgcGFj a2FnZSBJIGFtIHVzaW5nIChhaW9jb2FwKSBtYWtlcyBhbGwgcmVzb3VyY2VzIHZpc2libGUgdGhy b3VnaCBXSy9DLCBzbyB3b3VsZCBuZWVkIGNoYW5nZXMgaWYgdGhleSBhcmUgbm90IHRvIGJlIHZp c2libGUuDQoNClRoYW5rcw0KDQpKYW4NCi0tDQpEciBKYW4gTmV3bWFyY2gsDQpEaXJlY3RvciBv ZiBIaWdoZXIgRWR1Y2F0aW9uIChCdXNpbmVzcyBhbmQgSUNUKSBAIEJveCBIaWxsLCBBZGp1bmN0 IFByb2Zlc3NvciBAIFVuaXZlcnNpdHkgb2YgQ2FuYmVycmENCg0KRSBqYW5AbmV3bWFyY2gubmFt ZQ0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3Nh Z2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGlj YWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3Nl ZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From nobody Fri Dec 23 07:09:46 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C738129453 for ; Fri, 23 Dec 2016 07:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRxjDagUM-BF for ; Fri, 23 Dec 2016 07:09:42 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0086.outbound.protection.outlook.com [104.47.0.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623E71200A0 for ; Fri, 23 Dec 2016 07:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GXyRvF1qTcs4ub7xBEuw68J3N4Kr9T68qEL3lRkhh+w=; b=R0iI/FiA1r31LQwjJYQHdmqEmkf/Vw8PA14zBGr83sUhy+951G1FBckC8x1AXVvHeDKveIVYSAtNA07R75n8JbQjLhTudj5+Gb10m8EZVIFmWWUztq/RWuGSwEeVY5Hj8Tx/LuthWGnxceaLTOqMWKIrs8xZPJGVdik+cX80www= Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com (10.175.34.148) by HE1PR0802MB2474.eurprd08.prod.outlook.com (10.175.34.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 23 Dec 2016 15:09:38 +0000 Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) by HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) with mapi id 15.01.0789.018; Fri, 23 Dec 2016 15:09:38 +0000 From: Hannes Tschofenig To: 'Brian Raymor' , "'core@ietf.org WG'" Thread-Topic: Securing coap-tcp-tls Thread-Index: AdJcpRDdSlKL1bwuQ0m25+zFtG6gsgAgSEqA Date: Fri, 23 Dec 2016 15:09:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.195] x-ms-office365-filtering-correlation-id: 7bcf5edb-dea4-4efe-db52-08d42b45b6e3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0802MB2474; x-microsoft-exchange-diagnostics: 1; HE1PR0802MB2474; 7:MIkjh5Lqejk0hulHDtWoPOYrKTKvlZoxrM5um7MfWO1ZOXBnpvJHJVZqbAj+o9pAL4JClj3/xvfAdVEJhJaXHxpFWyt5kMQNmkqSv+N9VNEctFNX8ln3K6vF/Ekl95PfX5PeuTkX63BL9hYcr3b3CTEyWHbACslkH+y1qWrsmeFDEN58IRX2i7aaplxDYbWcrEaLpMU2dCj5BdZYWya3FnfDBDvE3eYp4Q5M//wKZEwfiScEkw1QjMlpp3IXiTS7O14hc7FrZcg/EoJVZ++rFwdisj7KWqEOvrHyZZ2TIhkz1htl8kS+FMyt0pVtgDGDGcuzbSCFioMkuoCm7aGp78rNnCXb2NvkczT1vInZECBJ4YslQFazMml7iYqW+n7clpB3knUAMLBICuv+fF1c8rNafrlE0CcTt99jwfTowkuD82W5/ZETGan8Ef1yGYRhT+Rt3QpKvOtua9cNcXR0SQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:HE1PR0802MB2474; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0802MB2474; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39410400002)(39860400002)(39850400002)(39840400002)(39450400003)(199003)(51914003)(40434004)(189002)(7696004)(5001770100001)(97736004)(2950100002)(7906003)(561944003)(33656002)(8676002)(25786008)(81166006)(86362001)(76576001)(1511001)(230783001)(74316002)(606005)(81156014)(2561002)(76176999)(54356999)(3660700001)(8666007)(3280700002)(101416001)(5890100001)(77096006)(50986999)(5660300001)(6436002)(189998001)(122556002)(2421001)(38730400001)(229853002)(4326007)(3846002)(9326002)(2906002)(2900100001)(9686002)(790700001)(6116002)(102836003)(105586002)(68736007)(66066001)(6506006)(8936002)(106356001)(7736002)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0802MB2474; H:HE1PR0802MB2475.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0802MB2475D69BD9CF5AB86786D21DFA950HE1PR0802MB2475_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2016 15:09:38.4254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2474 Archived-At: Cc: 'Juan Perez' Subject: Re: [core] Securing coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 15:09:44 -0000 --_000_HE1PR0802MB2475D69BD9CF5AB86786D21DFA950HE1PR0802MB2475_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks for the write-up. It looks good for me. Regarding the question below: Yes, there is indeed the risk that devices us= ing different TLS profiles do not talk to each other. But since we already added an option for object security I think we have ma= de it already worse (in terms of options) than it was previously. Hence, sa= ying that "The remaining mandatory-to-implement mode depends on the credent= ial type used with the device." sounds reasonable to me. A small editorial issue: s/The "NoSec" mode in mandatory-to-implement for t= he TLS binding./ The "NoSec" mode is mandatory-to-implement. Ciao Hannes From: Brian Raymor [mailto:Brian.Raymor@microsoft.com] Sent: 23 December 2016 00:21 To: core@ietf.org WG Cc: G=F6ran Selander; Francesca Palombini; Hannes Tschofenig; Juan Perez Subject: Securing coap-tcp-tls Apologies for the long delay in preparing this proposal. An extended illnes= s after Seoul conspired against me. Following the security discussion for coap-tcp-tls at IETF 97, G=F6ran and = I have been iterating on more nuanced text. I've applied the changes to the editor's draft, but kept - https://gi= thub.com/core-wg/coap-tcp-tls/issues/11 - open for tracking and further updates until there's broader agreement. Summary of Changes: * Added a "Securing CoAP" section which is a mind-meld between the related = RFC7252 section and the RFC7925 profile. The draft attempts to avoid too much duplication, but may be too minimal fo= r some tastes. * Added an informative reference to draft-ietf-core-object-security to illu= strate an alternative approach * Added an informative reference to Security Challenges for the Internet of= Things from the IAB workshop There is one question that needs broader review. In RFC7252, the NoSec and = RawPublicKey modes were mandatory-to-implement. Should this requirement be maintained for coap-tcp-tls ? For the moment, th= e current draft follows the direction of RFC7925: The mandatory-to-implement functionality will depend on the credential type used with IoT devices. 7. Securing CoAP Security Challenges for the Internet of Things [SecurityChallenges] recommends: ... it is essential that IoT protocol suites specify a mandatory to implement but optional to use security solution. This will ensure security is available in all implementations, but configurable to use when not necessary (e.g., in closed environment). ... even if those features stretch the capabilities of such devices. A security solution MUST be implemented to protect CoAP over TCP and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over TCP when appropriate. Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see [I-D.ietf-core-object-security]). 7.1. TLS binding for CoAP over TCP The TLS usage guidance in [RFC7925] applies. During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials, access control lists, and authorization servers. At the end of the provisioning phase, the device will be in one of four security modes with the following information for the given mode. The "NoSec" mode in mandatory-to-implement for the TLS binding. The remaining mandatory-to-implement mode depends on the credential type used with the device. "PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-implement for the TLS binding. NoSec: TLS is disabled. PreSharedKey: TLS is enabled. The guidance in Section 4.2 of [RFC7925] applies. RawPublicKey: TLS is enabled. The guidance in Section 4.3 of [RFC7925] applies. Certificate: TLS is enabled. The guidance in Section 4.4 of [RFC7925] applies. In the "NoSec" mode, the system simply sends the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. The other three security modes are achieved using TLS and are indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_HE1PR0802MB2475D69BD9CF5AB86786D21DFA950HE1PR0802MB2475_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Brian, <= /span>

 

Thanks for the write-u= p. It looks good for me.

 

Regarding the question= below: Yes, there is indeed the risk that devices using different TLS prof= iles do not talk to each other.

But since we already a= dded an option for object security I think we have made it already worse (i= n terms of options) than it was previously. Hence, saying that “The r= emaining mandatory-to-implement mode depends on the credential type used with the device.” sounds reasonable to m= e.

 

A small editorial issu= e: s/The "NoSec" mode in mandatory-to-implement for the TLS bindi= ng./ The "NoSec" mode is mandatory-to-implement.

 

Ciao=

Hannes

 

From: Brian Raymor [mailto:Brian.Raymor@microsoft.com]
Sent: 23 December 2016 00:21
To: core@ietf.org WG
Cc: G=F6ran Selander; Francesca Palombini; Hannes Tschofenig; Juan P= erez
Subject: Securing coap-tcp-tls

 

Apologies for the long delay in= preparing this proposal. An extended illness after Seoul conspired against= me.

 

Following the security discussi= on for coap-tcp-tls at IETF 97, G=F6ran and I have been iterating on more n= uanced

text. I’ve applied the ch= anges to the editor’s draft, but kept - https://githu= b.com/core-wg/coap-tcp-tls/issues/11 - open

for tracking and further update= s until there’s broader agreement.

 

Summary of Changes:<= /span>

 

* Added a “Securing CoAP&= #8221; section which is a mind-meld between the related RFC7252 section and= the RFC7925 profile.

The draft attempts to avoid too= much duplication, but may be too minimal for some tastes.

 

* Added an informative referenc= e to draft-ietf-core-object-security to illustrate an alternative approach<= o:p>

* Added an informative referenc= e to Security Challenges for the Internet of Things from the IAB workshop

 

There is one question that need= s broader review. In RFC7252, the NoSec and RawPublicKey modes were mandato= ry-to-implement.

Should this requirement be main= tained for coap-tcp-tls ? For the moment, the current draft follows the dir= ection of RFC7925:

 

The mandatory-to-implement func= tionality will depend on the

credential type used with IoT d= evices.

 

 

7. Securing CoAP

 

Security Challenges for the Int= ernet of Things [SecurityChallenges]

recommends:

 

... it is essential that IoT pr= otocol suites specify a mandatory

to implement but optional to us= e security solution. This will

ensure security is available in= all implementations, but

configurable to use when not ne= cessary (e.g., in closed

environment). ... even if those= features stretch the capabilities

of such devices.

 

A security solution MUST be imp= lemented to protect CoAP over TCP and

MUST be enabled by default. Thi= s document defines the TLS binding,

but alternative solutions at di= fferent layers in the protocol stack

MAY be used to protect CoAP ove= r TCP when appropriate. Note that

there is ongoing work to suppor= t a data object-based security model

for CoAP that is independent of= transport (see

[I-D.ietf-core-object-security]= ).

 

7.1. TLS binding for CoAP over = TCP

 

The TLS usage guidance in [RFC7= 925] applies.

 

During the provisioning phase, = a CoAP device is provided with the

security information that it ne= eds, including keying materials,

access control lists, and autho= rization servers. At the end of the

provisioning phase, the device = will be in one of four security modes

with the following information = for the given mode. The "NoSec" mode

in mandatory-to-implement for t= he TLS binding. The remaining

mandatory-to-implement mode dep= ends on the credential type used with

the device. "PreSharedKey&= quot;, "RawPublicKey", or "Certificate" is

mandatory-to-implement for the = TLS binding.

 

NoSec: TLS is disabled.

 

PreSharedKey: TLS is enabled. T= he guidance in Section 4.2 of

[RFC7925] applies.

 

RawPublicKey: TLS is enabled. T= he guidance in Section 4.3 of

[RFC7925] applies.

 

Certificate: TLS is enabled. Th= e guidance in Section 4.4 of

[RFC7925] applies.

 

In the "NoSec" mode, = the system simply sends the packets over normal

TCP which is indicated by the &= quot;coap+tcp" scheme and the TCP CoAP

default port. The system is sec= ured only by keeping attackers from

being able to send or receive p= ackets from the network with the CoAP

nodes.

 

The other three security modes = are achieved using TLS and are

indicated by the "coaps= 3;tcp" scheme and TLS-secured CoAP default

port.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_HE1PR0802MB2475D69BD9CF5AB86786D21DFA950HE1PR0802MB2475_-- From nobody Fri Dec 23 07:28:00 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2199B1296A2; Fri, 23 Dec 2016 07:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_5H_UD8d8xn; Fri, 23 Dec 2016 07:27:56 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10099.outbound.protection.outlook.com [40.107.1.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9450E12969E; Fri, 23 Dec 2016 07:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oT6fiTnWYLN4HupX69IkOUaa/nV5X17/s/poxid9M5A=; b=M7mpqIFfouZRcmavcHvLPsPueEdKD3+hSYCIJKbexYjHaqnsfD/397ZaqLZ+hmqUwtmPvEZfLZuWL9ogA+74RYbmuCuhahEInCBsPlerS97+2KjVXnzgbepzA5jbtDgMcbU6NG4tK1Nmsft54bqoNkvn3eysVsO5st65BBWrmeM= Received: from DB5P122CA0002.EURP122.PROD.OUTLOOK.COM (129.75.100.208) by DB5P122MB0022.EURP122.PROD.OUTLOOK.COM (129.75.100.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.15; Fri, 23 Dec 2016 15:27:52 +0000 Received: from DB3FFO11FD044.protection.gbl (2a01:111:f400:7e04::139) by DB5P122CA0002.outlook.office365.com (2603:10a6:20:2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.15 via Frontend Transport; Fri, 23 Dec 2016 15:27:52 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; newmarch.name; dkim=none (message not signed) header.d=none;newmarch.name; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by DB3FFO11FD044.mail.protection.outlook.com (10.47.217.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10 via Frontend Transport; Fri, 23 Dec 2016 15:27:52 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0169.MGDPHG.emi.philips.com (141.251.190.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Fri, 23 Dec 2016 15:27:50 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0789.018; Fri, 23 Dec 2016 15:27:50 +0000 From: "Dijk, Esko" To: Jan Newmarch , "draft-ietf-core-resource-directory@ietf.org" Thread-Topic: [core] More comments on draft-ietf-core-resource-directory-09 Thread-Index: AQHSWxZx2cpzK8S5SUC9CspaB4WrTqEVp7EQ Date: Fri, 23 Dec 2016 15:27:50 +0000 Message-ID: References: <1482275487.2683.17.camel@newmarch.name> In-Reply-To: <1482275487.2683.17.camel@newmarch.name> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.138.53] X-MS-Office365-Filtering-Correlation-Id: 508860a0-464d-4f19-dfe8-08d42b4842d8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9001MB0169.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39410400002)(39450400003)(39840400002)(2980300002)(428002)(374574003)(13464003)(189002)(55904004)(199003)(85714005)(189998001)(356003)(33646002)(38730400001)(68736007)(7696004)(108616004)(69596002)(305945005)(230783001)(7736002)(101416001)(97736004)(5001770100001)(2906002)(2950100002)(4326007)(66066001)(6116002)(8936002)(2501003)(24736003)(23676002)(5660300001)(106116001)(102836003)(86362001)(47776003)(50986999)(105586002)(76176999)(54356999)(3846002)(81166006)(81156014)(229853002)(92566002)(8676002)(626004)(106466001)(50466002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5P122MB0022; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD044; 1:C9eolymbrDST/iw69OqDPXKPAv0vrY77k0PFon1uLnjFWYSXppe4mLqRo3GnGPj6PBCl1m6VwDJHwvNa9Cc9eDIbT3GaVpHgSiRrv6pPbRx7WwG5V0o82RpRkxSYqFnsvDz9WV6M8hLslGqcs/veUNuqtYE9kLA1C1XduId+l+lW9Zs9MMDfb8Z2BXHgoO3caTOi6I1qZ1ygRFDXPw+Dj49M8Gp7YcUXbVQBQoMe4StJ+JOxzi0chuhLnQTlKavjDW6eMFYxL62d+6fvhjcS1r/ib1in4lyxE7eMErIN7ZrGfNU9ywPtbt6AYuizsMkm4Y06BbAkih27NirqzaQFhsrMwUSkjBgWnwRRf+Ec7LA1p8RZl4hJVFW3TJ+s4uiN+5VzRH94ntGZzT4I5+mj32xmfFQqj6/j9pT3+V17cD62pVtCxehWyJ4DzK/HOuAdGu72mGdLNYUzTCGS5nAI9qGf8pfh81n6uy7SQhcYS2wgUiq4td+CTT87XXq167XgZPFwDAdGP8b+A0xso/9Faw== X-CrossPremisesHeadersPromoted: DB3FFO11FD044.protection.gbl X-CrossPremisesHeadersFiltered: DB3FFO11FD044.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5P122MB0022; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0022; 3:K7Z1h6lz1+bh68gw8qwMAssaB+tXuaVTReAGaQRkbxR7FEv8bLYeWTTpuMgPoaiy2i/LOL+XvsU3cBCsQB9N0EKebO0TJJHu4lR42B9sEM6I7IqGdcUHk9BKyv1LNS6w7FTbDCvxbD+0JWDMgz0LVZlOS/MeLVQHbKHE7dYCRPTR27po04dKBaB0vpZ0MNUxXAanB4mBrWk4ciBaI62exNiufRj5JuZZ/N/hM61TZirofIvB6uKmq5nrCihbIEgmZhchtdxdvi6JlVip08avvxa+tv7mRyHsqauNhlDSoExbQ+2Jiq25lO1gQzWs8eI1PImB6qg3K7lDLnxEHWAnnEcJMu0laViwYmoUG3qec1I= X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0022; 25:+CD5s54ztJKl2UdYTK1GS6+o9A6XSzWhKjbFNyM+zoWVv2D8cACBmMVnR0IZhQOtMuNBXj3Ms9x1p/W3milenO2kBO+SOAo0gk/0QUn0C13anwvVrhrOUMh/qZh/gl33pPYDIOmZagcJuubT8LUhd6ELo2tTocUv8rFvIGnI6Tp7N8Mf4j74+X/w3b6vSx5MfeKiU2SmsWBNoaVL3htzyHgl56fx2gzBKzfUtMC3JLKqjct/JOyhVdTGK4IR5Bohr3O+Y1lQdUuKvd1c8SEjvfbPxNST7mYQzAC6jtFkAB17J1lXf4PfflzV9QwaN30idswln3Q8DPcD4TA2fSzMHL2iIT2lUP3csj8wBLeLFefziFyExpmRJf6oJ1JwlMewwoZIr99GbUHN+4N0UcRCml45CsqXySp9eluV9qSecvYZQBAwBm6luWp2jX5yeutaF23mpTeQG9qhdKHasY2rrDiivrIgiJvOF8uNjXWCOcG3J9gIf4YGblHJ3rrlDB7iQkouebIHBp/Cw+wG405ZiN4S/A6KTPCqXGjDx/NN0CxMqJldEvskeIP9F5n5RknYoWgH6/OEMpl68Epiya3Bv+eHx+886+AJ1YjUF8QE3nyjbgn3CFoOo3hXWbqu1VYospk5Q0yVpgSU2JDucIewSWmql74Jp0lsgBDnE2m600IGLLqyyZJlDIxy3WBg5qGiIpNN5m7GjTI3Dct1utWub+GHlVZT8I55dHC7E1hDgnYzy3jF0cVArFGPO0BpqOPIrOjBCnpWAfv50lHWLMYVDMdyAvyA5IV6n7Jv9pwIXDzWNIU+bjZoW8ZnNTlCrWl503hMkI4bM2V5ylzaHJqwz2eoqNL6vV8YucyQ+frvl+c254x5b/1POYOQoLxK68/9CmFxTWX2N2A8MkH0BWJWS3VXLmRimum3AWa5HE8B3feUDPWwXJi12LdmKeU8sD6S X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0022; 31:bQajbIDZPfGTB6RI+ct2fyTgwe6s9AC9epkiHgZchcSa6F+Y/0hV0Bh8mfeJdJhV/I8LGBMJuJvBCm7cl2OuoJyYKVI0BG+zXDTqj/mVIndHAoWm1I7AT7KIiuRg8gIrPr08/G+wdLgbGeLMsfst/zsuq3WBfKzUxSTBR5LyYwkw6rpI3p9LSME7bvCI6gaqb+4AVHpKV+sdIJ9RsY2FFSbKe0x8D1iZ0WaWdTb0pnf2KYgU268mQTknpo81aKT8U7tsCH7Xq7zsWYpitK1quXEBu+on8KQm9Mh+dQi8sYM=; 20:gkZH4Dd76q2tNuORSUovG4fEg2SL16eTONH00J7XzNZBtCBSEirIO/HAt4fJL8/JWZI2UvUIdjVhN/DPuitfRJjXfVhSHyG0uoPMNXihc/ABlzQVBvcsXvXi6ysVR0e4iKMYim9jCF8feEHFiUhNu5+LJ0j2czAyxcShD7q+SQOys9z9UUqRitDEqVNaSvU4FmxNV55xMguDBwxTAneLzvbhizwuhdBlsXpIyX2+OsfJbB6pdISbrrFE9OLhKTwyR4JyaNoQo7ZyBcPeehQ2QTe4EFES8XGVjK/EiiuwKP8/pdDIgQ5W10MX7it6uF9rFuydCaQv1IXteuKPqNv91gNf8+GVioBWWxa02q94B9jt+EiWj8S0es+VxKyTm0jSr2kH3G5vD3TyOGM7MoyCZB6u6Nu1fuoEOxpXv6Z+TLCs/45Q0UQ0PNyMkea+L3pURJrkzvaHnVt2JC1saYItqCLMnBlk5KrKdoOg5UjH4W9FPiCAjWaJ7wC00H8AvGb6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(13016025)(13018025)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:DB5P122MB0022; BCL:0; PCL:0; RULEID:; SRVR:DB5P122MB0022; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0022; 4:Smem/YWFTsEw0H0HXBagyPHnKBc0pc5jhW09gSmySBJTZhL4JTFI8qEUdb5Qiy8QbXFzpViz83it0KaIy5E1GT2IPx82Uy1RFijqLOLimVGFVdDMJAremlSKMJJU6u2xqggDKxFebkILzR3mbodtqFe27CWf4vTkUi9ArEkjO7wh9TrdwrCpkAbFwuM3WGGeW0HHmeUoNjpFYQUNVBuUGeNYdDb+WsavV+GjuozOAGhRsxOJ56HNdpEaV5vN+uRgfluKWkRzQ+cNCleXNVg3/I0bCmlJhqH1PwDe3U0BDVpw/mdrNeN7hRLXzGvLAmZKJaXtNG6sdPbs+PVE00lM2Q3XjRAeghplBdYWo0Bp5bDgwSPtL2QdDMAyUicDDgfEDmxwVXv3fbQweZe9/z8yjJYHZihQY3PZbr54Ap5GbLJsSInyQzdFXpZaKmkQQZVorg87OMq0C/xIg6xCyy3yRFTYeJ7nD+eq4oSVSwJzzPWKFN0KOvDHAGtn4FC3re+fT4/ZVyEYdRgZCI8sKQL3AidFG3LyQCRLwo0aYQsTcxeIiSE/W1aJmVMoD+BPpFaU6jydp6lcS/jB9Cw8DP5fckIwzh+ELaQR1MASUwEnxvAhZqGeTCoCXlT6YcmEt4nyiI3yaNFmQzkhQN8KqOULMX9mGWPbjKqwGxzyiiRCgsU= X-Forefront-PRVS: 016572D96D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQMTIyTUIwMDIyOzIzOitsV1hoaWgvNnlwKzQ2SmhUblNXVlhYZStF?= =?utf-8?B?dXJOTmdGc3cxbmVCT05iTEtYWi9oT3VhZFE5RS9wKzVNcG5pVGpWSmFVc0w0?= =?utf-8?B?ZzU0b2t6UGI0N243NUV6SHF1R1V1ZEpuNVJSdWZMeWg3VnB6RVlFaXhLWHNZ?= =?utf-8?B?d1BsZDFkNzhYbkYva3hvck1hZlJoSFNDdzNQalRyRVc0R2M4RWlUOVVtUjBE?= =?utf-8?B?MzJYUHpsdy9JR29ySEdrcHE3ZXVVcWNQZ085Q2RJYW1DQXB3bW92NHNSV2lJ?= =?utf-8?B?VU5DTTRZZlMzQ25SK1ZhbkJXMjJGNndySWZNTzZ2MDF5d2p6S3RIV3BIdytt?= =?utf-8?B?Y052VzdYc2ltYkx6WWZOZVRKcEJhcnFFdCtSaHV1SEE3NVlDNEsyQjBsMjNS?= =?utf-8?B?b2NZMzdJb3lyUzBzUDkxeStSbFBiYjd4aldZQzIxaFRJdHY2UzZVQitMMzhq?= =?utf-8?B?cnF6SThqWStzWW1hMjIwaDVhOHp1Zk1ZdXlaenZ0S1Byd1JoUEhzcWlKdll6?= =?utf-8?B?TWtKcXJZSXZqVUpSd3BQcUhnZHVFc3BjSWdYZG50MGI4N2dIOFZpekIyL0hD?= =?utf-8?B?TXptM0ttL01rb2JoS0l4MVI3bnp3NGNaTlEwUmhFMUZzajBQVkhxRVB5OU1I?= =?utf-8?B?bHN1RTdYZVNHdFoyM3hIVTlzVDNIdzEzKzVicmpsVEoxYlU5Z2ZQM0FZcmpY?= =?utf-8?B?SEx0SFhFTDc5ZFBwZ2Nub2lCUnI0SiszTXRYQ3BkMlRCTm9yd01uMVdaUEgv?= =?utf-8?B?WkphckJXSnZjeFV0SWlCM1kyVnljMkk4ZitHakxWSVRJWWQ2Vm5Pb3hUbnhM?= =?utf-8?B?QkxyVGZGVXVuZ1g5amVlR2NjWTlOTlpBc1U4cUJVMGxTS1Z6d0FvQTRtOTBZ?= =?utf-8?B?Ykg3SmVneXNEczZwbFZRZnF2WVM1clJRY0NYeEo2bVJDdUtkRktmNHpIM3lz?= =?utf-8?B?dVFZOGxHRHZySGgyc2ZYK1JRSFZLdXNEVFZhY0NWa0dkeHI0NG1YRjRoUFZW?= =?utf-8?B?cVpOZGU0cytUdXNhbkdmR3dzdlpXV2RSZU5xOUJ2K0R0aThtQk1KV2pIeUd1?= =?utf-8?B?VGt2NTg0OWtJUWN2QWZzQ2h3K0VqU1p6TFBYNkxFOGlWcXNEUDg1UTRPNFJC?= =?utf-8?B?aGpkTk54UEQvMEFUQXRCM0FrekJsN2Y5bjg0R3NxZzBqV0JTSGprSWVEZmZD?= =?utf-8?B?d01QSXpGajR1dWxacm1oNFBEa1hzUldhcFZLamd6RC9xWURFQUdtL3VIbHFk?= =?utf-8?B?cmpSeWhlZjgwUk9mbHRrS3JVemp5aTdtTjB6eHhROFNXdlNIN3MyQXVZU0Ev?= =?utf-8?B?YWdSUnZDQnpTQXFOT0VwYkpjWXhBbCtVdG5sU1pLa1Ivcmhzc0VBd1FybHVW?= =?utf-8?B?R2VmVGpNdTFzWnNDVnA4QWJWNDF0NVJmdi9DbzZhZzFtU2prN252MDBDZjMr?= =?utf-8?B?LytHVzZ4Nnh6MUF1YnRGQnVvQzhGNDBpbTlPMTJCTnNRNkdvRFA4ZzNxYUda?= =?utf-8?B?eVZiVHBzUUhrenFCRzBOS0Rvci93R2QwVi9QbE5aRDJUZmxkY1c1c21EQVFy?= =?utf-8?B?bzgyVVU3Wmw3VWRROWxYRTJQNm51ZmpJcW9iVm1tUEEvUnBZQit5blYxSXgw?= =?utf-8?B?L0k4Q3I2VUlOaXIyVWxUSnltY092YlpRTzg3TDBIOVB4VVAyNzYzbWpZdk5i?= =?utf-8?B?Sm5MSW1mVU9PMDluOEczVnhBa1d5NFRsSGt5Q0RBUVRscFJuaVNha0RJN0ZQ?= =?utf-8?B?RG5UVDdFUkpCOFZoTFErUS9iYWVZL1pEMUlubVNENXRzdzJWUjBZY0xEcEs2?= =?utf-8?B?NEJ5Y0JmNnlFdVJ3UVNoYWVqR1JLRGcwalRlYVBkRWhQUjZ5VHplN2pRNXFi?= =?utf-8?Q?bdpzQClPD7w=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0022; 6:pIwnXs3Fyt24K4qPFInwgMuwwuIpZGwTQy15YgCPyoWC6scyyxS72Q4E1dciKdDENwE4lOYN81ja016nvzhUWVeYbywJuNAdPhWCzqdPSRkSuZcjOAzgyzHTFpf7QVDMQqo3BZgP9F4KRV25OY+FK3WRl9GkI6n9VU3G0LChfJHiVVHhSogtquRjBDrqj+I0UMlfc3LJjSkvrxMaGcdKywS7/cuZk49r5hfBqf6+g1LqS9zi8S0n4MYuJsJvrUWxiebMa0Rv25twMuv/LTOEInHjtP2KNcOX/emMb6+wnLHR6t7VU+MtbZr3RW9xh15cHtVrxy/yWOmv+HSVcaApMTOs1/M8S0B22M0amSBm/W651hMM/mZUDPHJXekRUrInP6oWoOF02C4OChOpqyOCJgvyTI9nNLCdBjeeeN7ZfdFYODHV4tDYyVsPhHOZOFUL0amfQWR0t/tcaOGTXFyO8A==; 5:t9TG0wywNYsH7KSIcOCbDXhyOgeDa1fYvv7Wrx5+1Swsq9X5ahQRqwWr4BawpkY3kukNRwoSRsF1zyt8nCEesmUz2rXmMlTmvetIc3rK6a8ILS7BXE9vpnRxpA68zOe3Dt0Ry7uHHFxGMBGKE3/ppg==; 24:0TJyEwxnPjJznwtgqHrSsCj+YRlzLN/eKGUYLYkO4cdQOSsQci4D2SYhyybPlpeSXT68NZAl748coT6j/dtJ+628EvWCTtfvXWOqfPlrr9w= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0022; 7:F+PPtTXepEyqKJjELGp8Apwm/Xq0FioeNtV6yJ138mKN1b4pV5NrfVVKVvO3rvhe+wEl9o41sAHysSCdj/8gqsu0flxYVueWLK80IVw4D3dUAt3E6XPcMVkYAlUXjhlQpEQPJKXWfxi3JpxmcjTodGMJ7j7ALMM2RsByTc5Wbv43BLjNQAVL+u9Yvc3wdlyVVaoFG/RxcF47i61ezqm6cjl8hLSeT6ffbicjRL4QQBZGZ2w1ckpk/mX0rcSeFzArhOMYR1i5DTo/Vlgwf21uNWvhYuKT+MqbXFy3kxNBr+eNvF9Qi2QsvOTCWHB8Rkq+QHQnFy2jIq9wXDisuloX0R7siKiC7ink/pKbWlOXhUlIviZjJd2oikEmXjZHPL72pWimP/ExLu3yeHza9m76SXQuc751BeT9GtQy2xan+IuzfpBBKNtz01fITyMJgcNFtYAP4TsBgwgtimPiuE3mUg== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2016 15:27:52.4139 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5P122MB0022 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR9001MB0170.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 83.85.138.53 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: DB5P122MB0022.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "core@ietf.org" Subject: Re: [core] More comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 15:27:58 -0000 SGVsbG8gSmFuLA0KDQppbmRlZWQgdGhlIHNvdXJjZSBwb3J0IG9mIHRoZSByZWdpc3RlciByZXF1 ZXN0IHdpbGwgdHlwaWNhbGx5IGJlIGEgdHJhbnNpZW50IHBvcnQgdGhhdCdzIGNob3NlbiBieSB0 aGUgQ29BUCBsaWJyYXJ5LCBub3QgdGhlIGFwcGxpY2F0aW9uLg0KSG93ZXZlciAtIEknbSBub3Qg c3VyZSB0aGUgb3JpZ2luYWwgaW50ZW50aW9uIG9mIHRoZSB0ZXh0IHdhcyB0byBtZWFuIHRoZSBk ZWZhdWx0IHBvcnQgKDU2ODMpOyBtYXliZSBpdCB3YXMgaW50ZW5kZWQgdGhlIHdheSB3cml0dGVu IGFzc3VtaW5nIHRoYXQgdGhlIENvQVAgY2xpZW50IGl0c2VsZiBkb2VzIG5vdCBob3N0IHNvbWV0 aGluZyBvbiBwb3J0IDU2ODMvNTY4NCBzbyBpdCBjYW4gZnJlZWx5IHVzZSB0aGVzZSBwb3J0cyBh cyBzb3VyY2UgcG9ydHMoPykNCg0KSWYgb25seSBkZWZhdWx0IHBvcnQgNTY4MyBpcyBzdXBwb3J0 ZWQgd2hlbiB0aGUgImNvbiIgcGFyYW1ldGVyIGlzIGxlZnQgb3V0LCBpdCBpbXBsaWVzIHRoYXQg YW55IHJlZ2lzdHJhdGlvbnMgZm9yIHNlY3VyZSAoY29hcHM6Ly8pIHJlc291cmNlcyBvbiBwb3J0 IDU2ODQgd291bGQgYWx3YXlzIG5lZWQgdGhlICJjb24iIHBhcmFtZXRlci4NCkRvIHRoZSBSRCBh dXRob3JzIGtub3cgd2hhdCB3b3VsZCBiZSBpbnRlbmRlZCBoZXJlPw0KDQpJcyBXSy9DIHRoZSBX YWthYW1hIGxpYnJhcnk/ICBZb3UgYXJlIHJpZ2h0IHRoYXQgdHlwaWNhbGx5IHRoZSBzdWItcmVz b3VyY2VzIHdvdWxkIG5vdCBiZSB2aXNpYmxlIHdoZW4gZG9pbmcgZGlzY292ZXJ5IHNpbmNlIC9y ZCBvciAvcmQtbG9va3VwIHdpdGggdGhlaXIgcmVzcGVjdGl2ZSAncnQnIHZhbHVlcyBhbG9uZSB0 ZWxsIGFsbCB5b3UgbmVlZCB0byBrbm93LiBCdXQgdGhleSBjYW4gYmUgdmlzaWJsZS4gSWYgc3Vi LXJlc291cmNlcyBhcmUgdmlzaWJsZSB0aGV5IHdvdWxkIG5vdCBoYXZlIGFueSAncnQnIGFzc29j aWF0ZWQuDQpUaGUgaW50ZW50aW9uIG9mIFJEIGlzIEkgYmVsaWV2ZSB0byBub3Qgc2hvdyB0aGUg cmVnaXN0ZXJlZCAoY3JlYXRlZCkgcmVzb3VyY2VzIGxpa2UgL3JkLzQ1MjEgdmlhIHRoZSByZWd1 bGFyIC8ud2VsbC1rbm93bi9jb3JlIGJyb3dzaW5nIGZ1bmN0aW9uLCBob3dldmVyIGlmIHRoZSBS RCB3YW50cyB0byBkbyB0aGF0IGl0IGNhbi4gVGhlcmUgc2VlbXMgY3VycmVudGx5IG5vdGhpbmcg aW4gdGhlIFJEIHNwZWMgYmxvY2tpbmcgdGhpcy4NCg0KcmVnYXJkcw0KRXNrbw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEphbiBOZXdtYXJjaA0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJl ciAyMSwgMjAxNiAwOjExDQpUbzogY29yZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLXJlc291 cmNlLWRpcmVjdG9yeUBpZXRmLm9yZw0KQ2M6IEphbiBOZXdtYXJjaCA8amFuQG5ld21hcmNoLm5h bWU+DQpTdWJqZWN0OiBbY29yZV0gTW9yZSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvcmUtcmVz b3VyY2UtZGlyZWN0b3J5LTA5DQoNClRoYW5rcyBmb3IgcmVzcG9uc2VzIHRvIG15IGVhcmxpZXIg cXVlcmllcy4gSnVzdCB0d28gbW9yZToNCg0KU21hbGwgZXJyb3IgaW4gNi4zPw0KDQoiY29uIDo9 ICBDb250ZXh0IChvcHRpb25hbCkuICBUaGlzIHBhcmFtZXRlciBzZXRzIHRoZSBzY2hlbWUsDQog ICAgICAgICBhDQpkZHJlc3MgYW5kIHBvcnQgYXQgd2hpY2ggdGhpcyBzZXJ2ZXIgaXMgYXZhaWxh YmxlIGluIHRoZSBmb3JtDQogICAgICAgICBzDQpjaGVtZTovL2hvc3Q6cG9ydC4gIEluIHRoZSBh YnNlbmNlIG9mIHRoaXMgcGFyYW1ldGVyIHRoZQ0KICAgICAgICAgc2NoZW1lDQpvZiB0aGUgcHJv dG9jb2wsIHNvdXJjZSBJUCBhZGRyZXNzIGFuZCBzb3VyY2UgcG9ydCBvZg0KICAgICAgICAgdGhl DQpyZWdpc3RlciByZXF1ZXN0IGFyZSBhc3N1bWVkIg0KDQpUaGUgc291cmNlIHBvcnQgb2YgdGhl IHJlcXVlc3Qgd2lsbCBiZSBhIHRyYW5zaWVudCBwb3J0LiBUaGlzIGlzbid0IHRoZSBwb3J0IG9m IHRoZSBzZXJ2aWNlLiBJdCBzaG91bGQgYmUgdGhlIGRlZmF1bHQgcG9ydA0KDQogICAgSW4gdGhl IGFic2VuY2Ugb2YgdGhpcyBwYXJhbWV0ZXIgdGhlIHNjaGVtZSBvZiB0aGUgcHJvdG9jb2wsIHNv dXJjZSBJUCBhZGRyZXNzIHJlZ2lzdGVyIHJlcXVlc3QgYXJlIGFzc3VtZWQuIFRoZSBwb3J0IGlz IGFzc3VtZWQgdG8gYmUgdGhlIGRlZmF1bHQgcG9ydCwgNTY4My4NCg0KUmVsYXRpb24gYmV0d2Vl biBSRCBhbmQgV0svQzoNCg0KUmVzb3VyY2VzIHJlZ2lzdGVyZWQgd2l0aCBXSy9DIGluY2x1ZGUg Y29yZS5yZCwgY29yZS5yZC1sb29rdXAgYW5kIGNvcmUucmQtZ3JvdXAuIE5vdGhpbmcgaXMgc2Fp ZCBhYm91dCB0aGUgJ3N1Yi1yZXNvdXJjZXMnIC97K3JkLWxvb2t1cC0gYmFzZX0ve2xvb2t1cC10 eXBlfSBzdWNoIGFzIC9yZC1sb29rdXAvcmVzIGV0Yy4gSSB3b3VsZCBhc3N1bWUgdGhlc2UgYXJl IG5vdCBtZWFudCB0byBiZSB2aXNpYmxlLiBTaG91bGQgdGhpcyBiZSBzdGF0ZWQgZXhwbGljaXRs eT8gSWYgdGhleSBjb3VsZCBiZSB2aXNpYmxlLCB3aGF0IHdvdWxkIGJlIHRoZWlyIHJlc291cmNl IHR5cGUgJ3J0Jz8NCg0KVGhlIHNhbWUgd2l0aCByZXNvdXJjZXMgcmVnaXN0ZXJlZCB3aXRoIFJE IHN1Y2ggYXMgL3JkLzQ1MjEuIElmIHRoZXkgd2VyZSB2aXNpYmxlIHRocm91Z2ggV0svQyB0aGF0 IHdvdWxkIGdpdmUgYW5vdGhlciBsb29rdXAgbWVjaGFuaXNtIGJlc2lkZXMgdGhlIExvb2t1cCBG dW5jdGlvbiBTZXQuIFByb2JhYmx5IGJlc3QgdG8gZXhjbHVkZSB0aGF0IGV4cGxpY2l0bHkuDQoN ClRoZSBwYWNrYWdlIEkgYW0gdXNpbmcgKGFpb2NvYXApIG1ha2VzIGFsbCByZXNvdXJjZXMgdmlz aWJsZSB0aHJvdWdoIFdLL0MsIHNvIHdvdWxkIG5lZWQgY2hhbmdlcyBpZiB0aGV5IGFyZSBub3Qg dG8gYmUgdmlzaWJsZS4NCg0KVGhhbmtzDQoNCkphbg0KLS0NCkRyIEphbiBOZXdtYXJjaCwNCkRp cmVjdG9yIG9mIEhpZ2hlciBFZHVjYXRpb24gKEJ1c2luZXNzIGFuZCBJQ1QpIEAgQm94IEhpbGws IEFkanVuY3QgUHJvZmVzc29yIEAgVW5pdmVyc2l0eSBvZiBDYW5iZXJyYQ0KDQpFIGphbkBuZXdt YXJjaC5uYW1lDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkg YmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxh dy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVj dGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From nobody Fri Dec 23 07:45:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED53912968D; Fri, 23 Dec 2016 07:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 drMTob-nnYMQ; Fri, 23 Dec 2016 07:45:25 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C84127ABE; Fri, 23 Dec 2016 07:45:24 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3BF5A45C45; Fri, 23 Dec 2016 16:45:22 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C84423F; Fri, 23 Dec 2016 16:45:20 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 86ED43BC; Fri, 23 Dec 2016 16:45:20 +0100 (CET) Received: (nullmailer pid 1197 invoked by uid 1000); Fri, 23 Dec 2016 15:45:00 -0000 Date: Fri, 23 Dec 2016 16:45:00 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jan Newmarch Message-ID: <20161223154500.suexsthp6bmxyoza@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t3jrd4xckomf2tyg" Content-Disposition: inline In-Reply-To: <1482275487.2683.17.camel@newmarch.name> User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Subject: Re: [core] More comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 15:45:27 -0000 --t3jrd4xckomf2tyg Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jan, (or "hello again", as we've already talked about some of this on [1] with me wearing my Free Software developer hat, but this here is the better place) > The source port of the request will be a transient port. This isn't > the port of the service. It should be the default port I'd disagree here. A server that is registering itself at an RD could very well send the request from the socket it uses server-side too. The embedded library I've worked with (libcoap) works that way, as does aiocoap. A server *can* send the registration request from a different port (that would typically be a different socket), but then it would need to be very careful to send from the same IP address if it were to rely on any "take my address but change the port" mechanism. The server might be bound to a particular address, so if it were to send from a transient port, it would need to check for that anyway, and that's even without ephemeral addresses. > Resources registered with WK/C include core.rd, core.rd-lookup and > core.rd-group. Nothing is said about the 'sub-resources' /{+rd-lookup- > base}/{lookup-type} such as /rd-lookup/res etc. I would assume these > are not meant to be visible. Should this be stated explicitly? If they > could be visible, what would be their resource type 'rt'? IMO it does not hurt to have the resources visible, and it can be left to the applications to decide. As with any other resources that might be present due to functionality extensions of the RD or completely different tasks the same host is doing, both /rd-lookup/ep and /rd/4521 won't do no harm, and won't even be visible to someone querying /.w-k/c?rt=3Dcore.rd*. I wouldn't give them an rt, though, at least not a core one. All the best Christian [1] https://github.com/chrysn/aiocoap/issues/53 --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --t3jrd4xckomf2tyg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlhdRnYACgkQOY0REtOk veFNZg/+JEdHNv6gOJ2ctHxzESM/U/f48glREwb69wH0oBBZmy/44Mv3t+827LHG DS5tdynjF0/XQhrv46t8MKHjMRoRmSi690IQQ9EeoVKA1AdrwqGl+2wu99dVrsjD NvnoyropYUZEavIrKn12HwWQo44z5vTwaVLLyLBO0OvVDybkYPi66u9LT9yBK/ph +dyRhB7iJ/d+l+U7P2HKVlVYU1ntQJCMMg0YC+2/s5y1XIyTP7JEwHbPyFyGLJUf 0L5ZiYxLAR1YbwB/QE11XLSGUuCd+e9k3geLjnaYyyoVeVr36t6iNe0VqG9LLmwi CCw6NEYvPZkfb9klZJs4PY1ufn46AG4MIttW5TFzZTg4UjXbyNVlUtFPblRSelob uxDSBlwpn/TnQ4c7MBumbvtHXixV907efg47IcbNVTZ2hYv1fjuMMWeEXY1NdkJU 6aBkAfza+6xRLVxnKyXopGIXFJv0Wpgh8PVeYHw12Ukng+CNS7kUsjArucP6BRXl irMwoU+zdQ+TX9V1RNhd+BuLHdjktOgQnSBpsRRpDCQD+1M4pUcm5khPf0I3iDVD tQlawGhUCwBEEVf46EJyFKZe1NYmZpPL0Rj/aD8VcBbw3OO2XhZhJf/RHw47l5lw gpdZNW6pYK6ItV6D0/51XOshz0TNO3YKiFikW2TDf894pWnW8sQ= =ouoP -----END PGP SIGNATURE----- --t3jrd4xckomf2tyg-- From nobody Fri Dec 23 08:32:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77411299B4 for ; Fri, 23 Dec 2016 01:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, 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 6S2xDuXGWIbT for ; Fri, 23 Dec 2016 01:15:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB7A1294B1 for ; Fri, 23 Dec 2016 01:15:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 99CBAB801FF; Fri, 23 Dec 2016 01:15:31 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161223091531.99CBAB801FF@rfc-editor.org> Date: Fri, 23 Dec 2016 01:15:31 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 23 Dec 2016 08:32:09 -0800 Cc: rfc-editor@rfc-editor.org, core@ietf.org Subject: [core] [Editorial Errata Reported] RFC7252 (4895) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 09:15:33 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7252&eid=4895 -------------------------------------- Type: Editorial Reported by: Esko Dijk Section: 6.4 Original Text ------------- Note that these rules completely resolve any percent-encoding. Corrected Text -------------- Note that these rules completely resolve any percent-encoding. Also note that a trailing slash character in the component represents a separate, zero-character path segment (see [RFC3986] Section 3.3 ABNF) and therefore it is encoded using a Uri-Path Option of zero length. Notes ----- The current specification for decomposing a URI into CoAP Options (Section 6.4) is correct; however the text may still be unclear to implementers who may think that the phrase "not including the delimiting slash characters" means simply omitting a trailing slash character in the URI path. This is incorrect. See the discussion outcome in email thread https://www.ietf.org/mail-archive/web/core/current/msg08223.html . Therefore, a minor clarification is proposed in the notes after the parsing steps. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Dec 27 15:46:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA57129789; Tue, 27 Dec 2016 15:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 DRCr1TJ4mfKH; Tue, 27 Dec 2016 15:46:28 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 28E1B129785; Tue, 27 Dec 2016 15:46:28 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id y68so18595739pfb.1; Tue, 27 Dec 2016 15:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=ONx71oT0jOEnZV1VsR7qEJgiTouDkWUF+rjsOgAhVuY=; b=l5VdZmFBvXJKDGniD6WS+8iFE7xu2lj/V8g/fiIuBO4Jt2nAR1aN+15XxI4PAJkkxy 6qhSGgzt7T6HYZg2Rz+TMI9W4LR/l+rxpwZowKP7Ie5SQWqTX5BxaTU6kAhkQSsva7pb iGTsuIgPWNi/uvW6c+YCIxRjerNRciq4iQfSmrmKHTou7Jp7SpUErIpn/gk8a16H5n/f aQxmHiazH2c79OVzkKwsmDx2uzno9y7apwG8BJgtZ57Gz5V/oX2oaE9Tg3Chash7t/o0 KYGwNUarnkoMc1lmkNmSFF249PfYcDb8lBhd3edEjfwRpj/24nX7TancCIohdHAOH8Uy rx5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:message-id:subject:from:to:cc:date :in-reply-to:references:mime-version:content-transfer-encoding; bh=ONx71oT0jOEnZV1VsR7qEJgiTouDkWUF+rjsOgAhVuY=; b=YYgd8J+K6FZWPKP6hzhzijQeIIX6kdLHE3aPXVJFRZJTMBJDtESLLaYZWn199PYOFv /YO/tcJhJYcS2h5kQyEu3Lii5b9oUqS8jOihycSCKUBH0CUdSKv/zqwnxG5/lzrOyXMG +Oap5uW523bstu9qgapAVSO62R+ufcv7nX/W+u/u+YE2AlziB+7b0cowzznpGDy1mtwS 5EjXtjePowwktLzvKojN7mTwRaI18K7yNqONftYn37Tv2oebwTIVf1wRHk81aNKfDLS3 fQU80HtwYBNW0eh7kwb/fd+uHDSzrIljGDUQ067RKmdTzVno/m8AN0d4jB+179oHfJPc Mbfg== X-Gm-Message-State: AIkVDXJRu89+Ci0euqid8q19aFyr2MYrFIcJkB8/c5FDvCI1PBSgIuRmArscOSe6cl8Afw== X-Received: by 10.99.102.69 with SMTP id a66mr62174888pgc.49.1482882387701; Tue, 27 Dec 2016 15:46:27 -0800 (PST) Received: from desktop ([103.232.159.187]) by smtp.gmail.com with ESMTPSA id p5sm78865428pgk.23.2016.12.27.15.46.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 15:46:27 -0800 (PST) Sender: Jan Newmarch Message-ID: <1482882381.2683.132.camel@newmarch.name> From: Jan Newmarch To: Christian =?ISO-8859-1?Q?Ams=FCss?= Date: Wed, 28 Dec 2016 10:46:21 +1100 In-Reply-To: <20161223154500.suexsthp6bmxyoza@hephaistos.amsuess.com> References: <20161223154500.suexsthp6bmxyoza@hephaistos.amsuess.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Subject: Re: [core] More comments on draft-ietf-core-resource-directory-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 23:46:29 -0000 Hi Christian > The embedded library I've worked with (libcoap)  > [receives from the endpoints it sends the registration from], as  > does aiocoap.asyncio.get_event_loop().run_forever(main()) Okay, I was clearly using these libraries incorrectly (create a client context - with a transient port -  to register and a server context to handle queries). I now have my code working correctly using only the server context. I know it's implied, but could it be made more explicit in the spec as  In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed. The request should not be sent from a transient port, the registering agent is expected to be an endpoint for that scheme, IP and port.   > both /rd-lookup/ep and /rd/4521> won't do no harm, and won't even be > visible to someone querying> /.w-k/c/.w-k/c?rt=core.rd*. I'm thinking of someone just querying /.w-k/c, without a filter. They will see all /rd/xxxx resources, even if they don't know their type. Yes, the endpoint registering the resource is expected to use this when updating or removing the registration. Maybe I'm reading more into the spec than I should, but I'm thinking that no-one else apart from the original registering endpoint should be able to modify/delete the resources. Eventually that comes down to security but using obscurity through non-visibility helps achieve this. Cheers Jan -- Dr Jan Newmarch From nobody Thu Dec 29 15:56:17 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5812945E for ; Thu, 29 Dec 2016 15:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 PNVwlhEHAken for ; Thu, 29 Dec 2016 15:56:13 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE1112007C for ; Thu, 29 Dec 2016 15:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9lMxGFBtkKTi7ZTOU1WGHuHdK4UNZs9BMy3dBzl7G14=; b=fTeGuQFTkz5g2yERLo+9JvGO6MxEgzJZKUkeaF3P+cE6cQIx8OiUSg/qTGpMWVI3MVBCRPsxDH4EYfkgwVqynyw5WX6FnT+xKjwNbiFB6WqgVbPyfCRRJsMLRa4AlYwBszrHoyXxiLkwySoBJKUJDxybl3OLEXFXDaXMi+sdhqE= Received: from CO2PR03MB2373.namprd03.prod.outlook.com (10.166.93.21) by CY4PR03MB2439.namprd03.prod.outlook.com (10.168.163.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 29 Dec 2016 23:56:11 +0000 Received: from CO2PR03MB2373.namprd03.prod.outlook.com ([10.166.93.21]) by CO2PR03MB2373.namprd03.prod.outlook.com ([10.166.93.21]) with mapi id 15.01.0803.021; Thu, 29 Dec 2016 23:56:11 +0000 From: Brian Raymor To: Hannes Tschofenig , "core@ietf.org WG" , "draft-savolainen-core-coap-websockets@tools.ietf.org" Thread-Topic: Securing coap-tcp-tls Thread-Index: AdJcpRDdSlKL1bwuQ0m25+zFtG6gsgAgSEqAAUF6/AAAAKw18A== Date: Thu, 29 Dec 2016 23:56:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: 013ac256-4d4c-4645-6354-08d430464414 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR03MB2439; x-microsoft-exchange-diagnostics: 1; CY4PR03MB2439; 7:BuaDqzP3wAd6StADGnpccAaX87dW5jqKOlQIZtV1hEJBCxzP98o1fk5SgTcFqs2JcJDb2yrtAZupRvfZdxWtelx0hUDM5SljDfmsMyZREjxwHG+S4A7ldtWCyKCAgfkBuZLppxRw0OtuuNxEIyHos9orDVL2vqRQROX/72/9cEvQ2+uRmM1VVXvh7mijTayIyLNFNVmJhvt/lbTWYmzQgqv0dAeHHCHKQwp1ZIzqVK+QyPXephw3lP2k+5YBlzOHVV3MMrmqHV9L6oRD4oOyPlpG92+v6EvKxh331H02vuZKIE04G+ITMbCsvFa1+2CjZRjNGm4mRjQ2xAjPnTRuReqcT3cWRgRaRKkO/ayYg5H5nzwiLPrDtVD97VuI/Bjl1ijVKcRCoPHAWzYAauMFpXiA/2eCTMsoVHTn0Br2FvTdyfrsxqQgYxHntfkrTWgQeglGjH0oJZzwWgds2OALnVgFfwz5RYiOlBCMsCKdx7g= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(180628864354917)(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:CY4PR03MB2439; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2439; x-forefront-prvs: 01713B2841 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(40434004)(199003)(51914003)(189002)(377454003)(107886002)(86362001)(10090500001)(81156014)(122556002)(5890100001)(74316002)(101416001)(76176999)(92566002)(106356001)(105586002)(4326007)(2900100001)(8936002)(86612001)(4001430100002)(606005)(99286003)(77096006)(38730400001)(229853002)(6506006)(6436002)(25786008)(55016002)(54356999)(3280700002)(50986999)(8676002)(81166006)(2906002)(3660700001)(2950100002)(230783001)(5001770100001)(7906003)(68736007)(7736002)(2501003)(5660300001)(7696004)(9686002)(189998001)(5005710100001)(6116002)(10290500002)(102836003)(8990500004)(790700001)(3846002)(66066001)(33656002)(561944003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2439; H:CO2PR03MB2373.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB237366D6454CD843AE72A149836B0CO2PR03MB2373namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2016 23:56:11.1431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2439 Archived-At: Cc: Juan Perez Subject: Re: [core] Securing coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 23:56:15 -0000 --_000_CO2PR03MB237366D6454CD843AE72A149836B0CO2PR03MB2373namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resending with corrected CoRE WG address. + draft-savolainen-core-coap-websockets@tools.ietf.org Thanks Hannes. I updated the editor's draft to include your editorial comme= nt - https://github.com/core-wg/coap-tcp-tls/pull/100 Could the core-coap-websockets authors suggest any WebSocket-specific guida= nce (or pull requests) for WebSockets in the Securing CoAP section? I'm unf= amiliar with any production CoAP over WebSocket deployments as a source of = best practices to review. Thanks, ...Brian From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] Sent: Friday, December 23, 2016 7:10 AM To: Brian Raymor >; 'core@ietf.org WG' > Cc: 'G=F6ran Selander' >; 'Francesca Palombini' >; Juan Perez > Subject: RE: Securing coap-tcp-tls Hi Brian, Thanks for the write-up. It looks good for me. Regarding the question below: Yes, there is indeed the risk that devices us= ing different TLS profiles do not talk to each other. But since we already added an option for object security I think we have ma= de it already worse (in terms of options) than it was previously. Hence, sa= ying that "The remaining mandatory-to-implement mode depends on the credent= ial type used with the device." sounds reasonable to me. A small editorial issue: s/The "NoSec" mode in mandatory-to-implement for t= he TLS binding./ The "NoSec" mode is mandatory-to-implement. Ciao Hannes From: Brian Raymor [mailto:Brian.Raymor@microsoft.com] Sent: 23 December 2016 00:21 To: core@ietf.org WG Cc: G=F6ran Selander; Francesca Palombini; Hannes Tschofenig; Juan Perez Subject: Securing coap-tcp-tls Apologies for the long delay in preparing this proposal. An extended illnes= s after Seoul conspired against me. Following the security discussion for coap-tcp-tls at IETF 97, G=F6ran and = I have been iterating on more nuanced text. I've applied the changes to the editor's draft, but kept - https://gi= thub.com/core-wg/coap-tcp-tls/issues/11 - open for tracking and further updates until there's broader agreement. Summary of Changes: * Added a "Securing CoAP" section which is a mind-meld between the related = RFC7252 section and the RFC7925 profile. The draft attempts to avoid too much duplication, but may be too minimal fo= r some tastes. * Added an informative reference to draft-ietf-core-object-security to illu= strate an alternative approach * Added an informative reference to Security Challenges for the Internet of= Things from the IAB workshop There is one question that needs broader review. In RFC7252, the NoSec and = RawPublicKey modes were mandatory-to-implement. Should this requirement be maintained for coap-tcp-tls ? For the moment, th= e current draft follows the direction of RFC7925: The mandatory-to-implement functionality will depend on the credential type used with IoT devices. 7. Securing CoAP Security Challenges for the Internet of Things [SecurityChallenges] recommends: ... it is essential that IoT protocol suites specify a mandatory to implement but optional to use security solution. This will ensure security is available in all implementations, but configurable to use when not necessary (e.g., in closed environment). ... even if those features stretch the capabilities of such devices. A security solution MUST be implemented to protect CoAP over TCP and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over TCP when appropriate. Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see [I-D.ietf-core-object-security]). 7.1. TLS binding for CoAP over TCP The TLS usage guidance in [RFC7925] applies. During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials, access control lists, and authorization servers. At the end of the provisioning phase, the device will be in one of four security modes with the following information for the given mode. The "NoSec" mode in mandatory-to-implement for the TLS binding. The remaining mandatory-to-implement mode depends on the credential type used with the device. "PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-implement for the TLS binding. NoSec: TLS is disabled. PreSharedKey: TLS is enabled. The guidance in Section 4.2 of [RFC7925] applies. RawPublicKey: TLS is enabled. The guidance in Section 4.3 of [RFC7925] applies. Certificate: TLS is enabled. The guidance in Section 4.4 of [RFC7925] applies. In the "NoSec" mode, the system simply sends the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. The other three security modes are achieved using TLS and are indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_CO2PR03MB237366D6454CD843AE72A149836B0CO2PR03MB2373namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Resending with corrected CoRE WG address.=

 

+ draft-savolainen-core-coap-websockets@tools.ietf.org

 

Thanks Hannes. I updated the editor’s draft to= include your editorial comment - https://github= .com/core-wg/coap-tcp-tls/pull/100

 

Could the core-coap-websockets authors suggest any W= ebSocket-specific guidance (or pull requests) for WebSockets in the Securin= g CoAP section? I’m unfamiliar with any production CoAP over WebSocke= t deployments as a source of best practices to review.

 

Thanks,

…Brian

 

From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com]
Sent: Friday, December 23, 2016 7:10 AM
To: Brian Raymor <B= rian.Raymor@microsoft.com>; 'core@ietf.org WG' <core@ietf.org>
Cc: 'G=F6ran Selander' <goran.selander@ericsson.com>; 'Francesca Palombini' <francesca.palombini@ericsson.= com>; Juan Perez <juanp= ere@microsoft.com>
Subject: RE: Securing coap-tcp-tls

 

Hi Bria= n,

&n= bsp;

Thanks = for the write-up. It looks good for me.

&n= bsp;

Regardi= ng the question below: Yes, there is indeed the risk that devices using dif= ferent TLS profiles do not talk to each other.

But sin= ce we already added an option for object security I think we have made it a= lready worse (in terms of options) than it was previously. Hence, saying th= at “The remaining mandatory-to-implement mode depends on the credential type used with the device.” sounds re= asonable to me.

&n= bsp;

A small= editorial issue: s/The "NoSec" mode in mandatory-to-implement fo= r the TLS binding./ The "NoSec" mode is mandatory-to-implement.

&n= bsp;

Ciao

Hannes<= o:p>

&n= bsp;

From: Brian Raymor [mailto:Brian.Raymor@microsoft.com]
Sent: 23 December 2016 00:21
To: core@ietf.org WG
Cc: G=F6ran Selander; Francesca Palombini; Hannes Tschofenig; Juan P= erez
Subject: Securing coap-tcp-tls

 

Apologies for the long delay in preparing this propo= sal. An extended illness after Seoul conspired against me.

 

Following the security discussion for coap-tcp-tls a= t IETF 97, G=F6ran and I have been iterating on more nuanced

text. I’ve applied the changes to the editor&#= 8217;s draft, but kept - https://githu= b.com/core-wg/coap-tcp-tls/issues/11 - open

for tracking and further updates until there’s= broader agreement.

 

Summary of Changes:

 

* Added a “Securing CoAP” section which = is a mind-meld between the related RFC7252 section and the RFC7925 profile.=

The draft attempts to avoid too much duplication, bu= t may be too minimal for some tastes.

 

* Added an informative reference to draft-ietf-core-= object-security to illustrate an alternative approach

* Added an informative reference to Security Challen= ges for the Internet of Things from the IAB workshop

 

There is one question that needs broader review. In = RFC7252, the NoSec and RawPublicKey modes were mandatory-to-implement.=

Should this requirement be maintained for coap-tcp-t= ls ? For the moment, the current draft follows the direction of RFC7925:

 

The mandatory-to-implement functionality will depend= on the

credential type used with IoT devices.

 

 

7. Securing CoAP

 

Security Challenges for the Internet of Things [Secu= rityChallenges]

recommends:

 

... it is essential that IoT protocol suites specify= a mandatory

to implement but optional to use security solution. = This will

ensure security is available in all implementations,= but

configurable to use when not necessary (e.g., in clo= sed

environment). ... even if those features stretch the= capabilities

of such devices.

 

A security solution MUST be implemented to protect C= oAP over TCP and

MUST be enabled by default. This document defines th= e TLS binding,

but alternative solutions at different layers in the= protocol stack

MAY be used to protect CoAP over TCP when appropriat= e. Note that

there is ongoing work to support a data object-based= security model

for CoAP that is independent of transport (see<= /o:p>

[I-D.ietf-core-object-security]).

 

7.1. TLS binding for CoAP over TCP

 

The TLS usage guidance in [RFC7925] applies.

 

During the provisioning phase, a CoAP device is prov= ided with the

security information that it needs, including keying= materials,

access control lists, and authorization servers. At = the end of the

provisioning phase, the device will be in one of fou= r security modes

with the following information for the given mode. T= he "NoSec" mode

in mandatory-to-implement for the TLS binding. The r= emaining

mandatory-to-implement mode depends on the credentia= l type used with

the device. "PreSharedKey", "RawPubli= cKey", or "Certificate" is

mandatory-to-implement for the TLS binding.

 

NoSec: TLS is disabled.

 

PreSharedKey: TLS is enabled. The guidance in Sectio= n 4.2 of

[RFC7925] applies.

 

RawPublicKey: TLS is enabled. The guidance in Sectio= n 4.3 of

[RFC7925] applies.

 

Certificate: TLS is enabled. The guidance in Section= 4.4 of

[RFC7925] applies.

 

In the "NoSec" mode, the system simply sen= ds the packets over normal

TCP which is indicated by the "coap+tcp&quo= t; scheme and the TCP CoAP

default port. The system is secured only by keeping = attackers from

being able to send or receive packets from the netwo= rk with the CoAP

nodes.

 

The other three security modes are achieved using TL= S and are

indicated by the "coaps+tcp" scheme an= d TLS-secured CoAP default

port.

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

--_000_CO2PR03MB237366D6454CD843AE72A149836B0CO2PR03MB2373namp_--