From nobody Thu Sep 1 02:12: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 415A512D896 for ; Thu, 1 Sep 2016 02:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5bH6Bvx6GUh for ; Thu, 1 Sep 2016 02:12:17 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893CE12B059 for ; Thu, 1 Sep 2016 02:12:17 -0700 (PDT) Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta24.fe.bosch.de (Postfix) with ESMTP id 3C7EED8021F for ; Thu, 1 Sep 2016 11:12:14 +0200 (CEST) Received: from IMBVW2EXC00.bosch-si.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id A3C802E4075A for ; Thu, 1 Sep 2016 11:12:13 +0200 (CEST) Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by IMBVW2EXC00 ([10.55.1.51]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 11:12:35 +0200 From: "Kraus Achim (INST/ESY1)" To: "core@ietf.org WG" Thread-Topic: [core] Implications of IP address / port changes for CoAP & Co Thread-Index: AQHSA3Oph8BKpt9FVU2PsqNm6BqgGKBkVYqg Date: Thu, 1 Sep 2016 09:12:34 +0000 Message-ID: References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> In-Reply-To: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.144.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22546.006 X-TMASE-MatchedRID: vwDfdEWUC5fM5du6ILPva5mug812qIbzvXPle/NgW1IeH35Xwro9LtXf akMEIQ7HQ466dTA5zGzJo6l+yr3D0jJz3NGP4sGin4TOxGsZP0hQCOsAlaxN78pj/9aYiP+h0RA sk+VhCoQJKSZsZFjAXnQOrI4rsSvxoVVi0fhQg53Wmh5xCo4mMCnGh6cFQ6shY8r/ndGdDsXLsL vOp8aQisrfCsxYhUl5cmHAUC91bv1iZyE2UOy4HMnUT+eskUQPS2qKEFuCMh6Y9ZFUJrkz0qAxl HNAADt8jzgVoOjNndyuHF8XwCwpsy2W7Y+Npd9RCFaAixm5eU+Hxi2fvkKUM3e9QDr8+LTcxbsk XFeoFkOI/YkOGzjRtzEg+3KNkVnRxdqG4jH8d+UAKzYLecaUGCseSAhqf1rRFJfW7wEu1kA62xg U98hiEap3muhLqOMEmFon3S75kCo86jprCBoTOeLdprnA5EQRY9JlLwL1dg0toOKrlTFnpXlgWA IEhZArpFWSyofFJaUC+YYCP7Qu06gSz5LfW6gEjSOVeRIcbV55y+Nu7/EOOruqk4cq52pz0vjOt IIVol658Ekbt0Wd7CV/L61HAy7j2+sv1ZHxJcodxBAG5/hkWyGi0ftsSkQyZ5yuplze9pu5h6FE WqTnjX3mWGw+DdrAhXRMKA3Zk2+pl11JQiuwkuwSNio74PJoGPx27R2NrHsR34ro7k23nWFwmoC 00lhIW0ASbXTw1ghQ7O10u0levThUupg4y4m6kE7MrqaPYs2Vq+okl1rYD6yA0UDhY9J1Fd8oDK JoE51IwttzS159QzDEq5IKtYgDz1FYyuHjH/ueAiCmPx4NwIRgZNP+6bISxEHRux+uk8jpP8tMO yYmaA== Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co 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 Sep 2016 09:12:21 -0000 Hi Hannes, thank you!=20 I appreciate your writing, because it sum up the critical topics using CoAP= and DTLS in an IPv4 environment. The current "work around" for DTLS may be to always emit a "DTLS session re= sume", if the last sent message was some time ago, unfortunately the "some time" is rather small an= just a couple of seconds. The observe seems for me only be usable, if we expect frequently notifies (= also just a couple of seconds). Any other usage of observe (say for notifies just for a couple of minutes o= r longer), seems for me raising issues. Even, if we use the DTLS resume approach above, the "epoch" seems t= o be just the same "number", but in fact, this is more the result, that epoch 1 is the first after a suc= cessful handshake then really the same (so RFC7252 9.1.2 . "The DTLS session MUST be the same, and the epoch MUST = be the same." smells to be faked. Some statement from encryption experts may be required). =20 Mit freundlichen Gr=FC=DFen / Best regards Achim Kraus Bosch Software Innovations GmbH Communications (INST/ESY1) Stuttgarter Stra=DFe 130 71332 Waiblingen GERMANY www.bosch-si.de www.blog.bosch-si.com=20 Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB = 148411 B Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn -----Urspr=FCngliche Nachricht----- Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Hannes Tschofenig Gesendet: Mittwoch, 31. August 2016 12:37 An: core@ietf.org WG Betreff: [core] Implications of IP address / port changes for CoAP & Co Hi all, in the OMA device management group we have been discussing the implications= of IP address and/or port number changes of devices (particularly with dev= ices that sleep for an extended period of time). The challenge from a protocol point of view is to use an identifier that do= es not depend on the IP address and port. Of course, when a IP packet has t= o be sent to a specific node then IP address and port information has to be= used from somewhere but my expectation is that at least the protocol machi= nery shouldn't break when an IP address changes (or there should be a story= for how to recover). In CoAP the 'endpoint' appears to be an important identifier. In an attempt= to define what an endpoint is the CoAP specification is a bit confusing: Section 1.2 says: " Endpoint An entity participating in the CoAP protocol. Colloquially, an endpoint lives on a "Node", although "Host" would be more consistent with Internet standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port number and a security association (Section 4.1). "=09 Section 4.1 of RFC 7252 says: =09 " A CoAP endpoint is the source or destination of a CoAP message. The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9): With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode. " The two definitions do not appear to be in sync, particularly when using DT= LS to secure CoAP since the DTLS record layer adds nothing with respect to = additional multiplexing. I also did not find text that describes what the d= ifferent endpoint definition is when DTLS is used. In any case, when DTLS is used an IP address / port change at the client wi= ll prevent the CoAP server from finding the right security context and a ne= w (hopefully abbreviated) handshake has to be run. Luckily the implications of an IP address/port change are quite minimal for= CoAP itself since the only impact (as far as I can tell) is with regards t= o the use of request/response exchange, as described in Section 5.3.2 "Request/Response Matching Rules". The likelihood that a client chang= es IP address in the middle of a request/response interaction are IMHO mini= mal. The story is more interesting when we look at extensions to CoAP, like CoAP= Observe. Section 4.1 of https://tools.ietf.org/html/rfc7641 says: " The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. " With Observe a token is used for demultiplexing (in addition to the endpoin= t info). I assume that the spec uses the same definition of endpoint as in = CoAP. While the spec does not say what is actually being updated or replaced one = can assume that a client sending a request with a new IP address and port (= which corresponds to the endpoint definition in CoAP) gets at least that in= formation updated. The spec is IMHO unclear what should happen in case of an IP address/port c= hange. I suspect that an implementation would send a new register message a= nd the server would update state. Of course, when the IP address / port of = the client is not in sync with what is being stored at the server then the = notifications sent by the server will not reach the client. The story for RD appears to be different again. First, there appears to be = a different definition of endpoint being used (which I prefer more).=20 For multiplexing it does not use IP address & port information. Of course, = RD will still have to maintain this information but at least one can be sur= e that packets are not dropped after the IP address and/or port at the clie= nt change. Section 11.1 of draft-ietf-core-resource-directory-08 says: " An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. " It appears that the way how state is indexed is different throughout the sp= ecifications developed in the CORE working group and I am curious whether s= omeone else has been looking at the implications of IP address and/or port = changes on the protocol operation. I would certainly appreciate your though= ts on this topic. Ciao Hannes _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Sep 1 03:29: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 2D00612D90D; Thu, 1 Sep 2016 03:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCnd59pT0YNS; Thu, 1 Sep 2016 03:29:28 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0B666127058; Thu, 1 Sep 2016 03:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1472725767; d=isode.com; s=june2016; i=@isode.com; bh=NoT1W2j0ZPfy2NKvyGdPdiuzqWRseCAM6g5/Elsd3KE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=M+2lO+sjIyQwXpngk+K4GC27erLPXDniX1yf2MTaaMi7psLMDRLU8m9WId13pwfHCcC82c xrCgi8/lCkHtkac3Bmy92tb3JV3NrhEGQGOVuaC6CLA0J835qYNj5ZiTa52lZUSuIyHoiS fQZ4FfsN2RkB2Hq9z62Np6vztf3V0h4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 1 Sep 2016 11:29:27 +0100 From: Alexey Melnikov To: core@ietf.org Message-ID: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> Date: Thu, 1 Sep 2016 11:29:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: core-chairs@ietf.org Subject: [core] AD review comments on draft-ietf-core-http-mapping-13 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 Sep 2016 10:29:29 -0000 In Section 4: I think you should add an informative reference to HTML5. In 5.4.1.1, example 3: Would it be better to define a separate variable (in addition to "tu") which doesn't include the scheme? I don't see how your current example 3 is valid as written, because your ABNF in 5.4.1 says that the scheme URI part is always included. In 6.3: is the table fixed or can implementations do variations of it? Excuse my ignorance, but does does "htc" attribute need registering with IANA? In 9.2: "encoding consideration" should say "binary", because if the specific content format is not known, we can't say anything more specific than "binary". "Provisional Registration" - should be "no". In 10.3, last para: is this actually a good idea? What about opportunistic security and desire to prevent pervasive monitoring? You are using Obsolete RFC 2616 reference. Please point to one or more latest HTTP/1.1 RFC. Reported by ID-nits: RFC 2119 keyword use template doesn't match expected text. Should the document cover HTTP PATCH? From nobody Thu Sep 1 03:39: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 5025D12D0D9; Thu, 1 Sep 2016 03:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 jU_6fwdIqTer; Thu, 1 Sep 2016 03:39:42 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 4B08912D777; Thu, 1 Sep 2016 03:39:42 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id i32so137533684uai.2; Thu, 01 Sep 2016 03:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DF5c5nWU8yLTup0yEY7BIqx2+NbLmfAZL3ckH/rCkIM=; b=XH56SzA3e/dnbPSKzXERd04KXoGIi1OEC+6i5nFlFhAvfkc0a2s/IdI5m0M8x+gfnH i8ukCjjj4IuRlZpnzOeFfq20onrYfm3rXIYdXwXYco+AK2Sk7xBmwsiHZBlNQMVTPosK CP1AffPhT+FBLv/7u9RYsv9ImWzFL4Nca1XQzJHPfj8RLeJ9Qrti0yTArm1vL4LUX3Rq GSZwuGXO3a4ziBsYMU0zZglvbjUnBGuZ6VmCHHS2JBX9iKzkV5Ccbok+LyihUZfu45hE 6lGQdK5QoEfLR6l/NqmaN6QFSycli12feZtiB3xXTs8sOFWYmtSJHLu6Qk66n3OOyTud hIkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DF5c5nWU8yLTup0yEY7BIqx2+NbLmfAZL3ckH/rCkIM=; b=PXCdgmp0tyHGvnfKDTdxq7FsjfEwthkV/QNSvOxKDQTr6313Y2PqoWJWDhM9RxXJOY E6ic8znHb1+kBmAdCTIpgCfsTkvIX0w1yrkJD0Kbx6V2DnJ/8L5HuEcnWTVAMt6E9Yq6 1eLn3j7odZzQcJz3fAsp7Ld7Qzpf2vYtDCCvwqoTWnCjxpfs6xdnvqMusGlgxtYyI3v1 zyEZn3AOeWZVdTv0pw68s9qhJxjiAM4nIyDLyagr0FygCJyyH0FBiesrVmKMr3fInGvO 3lXqqLnvAQ/zB7Vp6zofFWxcjMl0evgVbP/ZHlvJuyNFObHm5XlxBI6DP/BE7dnPdRhZ 2l8A== X-Gm-Message-State: AE9vXwN1fszCNwPqnYIcs2cHTtaN0iQ1vEU4gJagO66mnLzkA85sxq6Q8bRiSzOcRIM+qpjmoVjTvuhjiPY18g== X-Received: by 10.31.15.139 with SMTP id 133mr9040300vkp.37.1472726381420; Thu, 01 Sep 2016 03:39:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.132 with HTTP; Thu, 1 Sep 2016 03:39:41 -0700 (PDT) In-Reply-To: <9E8BCA5C-3020-4BFC-9C1D-321A6F53DD7E@ericsson.com> References: <9E8BCA5C-3020-4BFC-9C1D-321A6F53DD7E@ericsson.com> From: Zhen Cao Date: Thu, 1 Sep 2016 18:39:41 +0800 Message-ID: To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Content-Type: multipart/alternative; boundary=001a1143aee6d0e890053b6fd4c5 Archived-At: Cc: "draft-bormann-core-cocoa@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-bor?= =?utf-8?q?mann-core-cocoa?= 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 Sep 2016 10:39:44 -0000 --001a1143aee6d0e890053b6fd4c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I already voiced my support on the Berlin meeting. This work is a useful guidance to lower the latency for CoAP messages. Thanks for the work. On Mon, Aug 15, 2016 at 11:09 PM, Jaime Jim=C3=A9nez wrote: > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been requested > for draft-bormann-core-cocoa. At the IETF meeting the room consensus was > for adoption. Please reply to the list with your comments, including > although not limited to whether or not you support adoption. Non-authors > are especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call on *Au= gust > 26, 2016*. > > Thanks, > Jaime and Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a1143aee6d0e890053b6fd4c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I already voiced my support on the Berlin meeting.=C2=A0 T= his work is a useful guidance to lower the latency for CoAP messages. =C2= =A0=C2=A0

Thanks for the work.=C2=A0

On Mon, Aug 15, 2016 at 1= 1:09 PM, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
Dear CoRE-WG,

As we discussed at last IETF96, working group adoption has been requested f= or draft-bormann-core-cocoa. At the IETF meeting the room=C2=A0consensus wa= s for adoption.=C2=A0Please reply to the list with your comments, including= although not=C2=A0limited to whether or not you support adoption. Non-authors are especially=C2=A0encouraged to comment.
Since there are several concurrent WGA calls, we will end the call on=C2=A0= August 26, 2016.

Thanks,
Jaime and Carsten


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


--001a1143aee6d0e890053b6fd4c5-- From nobody Thu Sep 1 05:40: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 5134612DBA5; Thu, 1 Sep 2016 05:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZcS_-BKpWgs; Thu, 1 Sep 2016 05:40:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF7812D957; Thu, 1 Sep 2016 05:31:18 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 6DA11504E8B94; Thu, 1 Sep 2016 12:31:14 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u81CVHYP024751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2016 12:31:17 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u81CVGtg030218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Sep 2016 14:31:17 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.184]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 1 Sep 2016 14:31:16 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Alexey Melnikov , "core@ietf.org" Thread-Topic: [core] AD review comments on draft-ietf-core-http-mapping-13 Thread-Index: AQHSBDu9w9KVoyLgVkyeIw5xc36+tKBkgDcA Date: Thu, 1 Sep 2016 12:31:15 +0000 Message-ID: References: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> In-Reply-To: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" Subject: Re: [core] AD review comments on draft-ietf-core-http-mapping-13 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 Sep 2016 12:40:27 -0000 Hi Alexey, Thanks very much for your comments. >In Section 4: I think you should add an informative reference to HTML5. OK >In 5.4.1.1, example 3: > >Would it be better to define a separate variable (in addition to "tu") >which doesn't include the scheme? I don't see how your current example 3 >is valid as written, because your ABNF in 5.4.1 says that the scheme URI >part is always included. Last para of 5.4.1 "amends" the above ABNF saying: "The same considerations as in Section 5.3.1 apply, in that the CoAP scheme may be omitted from the Hosting HTTP URI." Do you think it's not enough? >In 6.3: is the table fixed or can implementations do variations of it? The table is the default. It is expected that an implementation can refine it based on a) application-specific knowledge, b) registration of new Content-Formats. >Excuse my ignorance, but does does "htc" attribute need registering with >IANA? My understanding from previous discussions is that, since there doesn't seem to be a registry for that, the hct attribute will be documented in the Description of the new core.hc resource type in the "Resource Type (rt=3D) Link Target Attribute Values" registry [1]. (I may be horribly wrong, though.) >In 9.2: "encoding consideration" should say "binary", because if the >specific content format is not known, we can't say anything more >specific than "binary". OK >"Provisional Registration" - should be "no". OK >In 10.3, last para: is this actually a good idea? What about >opportunistic security and desire to prevent pervasive monitoring? Personally, I agree with you. My co-authors might have a different opinion though? >You are using Obsolete RFC 2616 reference. Please point to one or more >latest HTTP/1.1 RFC. We do (normatively) reference the HTTPbis specs. The reference to 2616 is informative only -- it is used to highlight a difference in treating 201 responses' format between "original" HTTP and HTTPbis. >Reported by ID-nits: RFC 2119 keyword use template doesn't match >expected text. Pardon my ignorance, but I don't understand what we'd need to fix here. >Should the document cover HTTP PATCH? This point was also raised by Christian [2]. The consensus was to do avoid blocking this work on draft-etch (or any other protocol extension). The following text was added to reflect the outcome of that discussion: "This document describes HTTP mappings that apply to protocol elements defined in the base CoAP specification [RFC7252]. It is up to CoAP protocol extensions (new methods, response codes, options, content- formats) to describe their own HTTP mappings, if applicable." Cheers, t [1] http://www.iana.org/assignments/core-parameters/core-parameters.xhtml [2] https://www.ietf.org/mail-archive/web/core/current/msg07411.html From nobody Fri Sep 2 00:48:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6912D091; Fri, 2 Sep 2016 00:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Svp6gZUJlXcc; Fri, 2 Sep 2016 00:48:32 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C58C12D090; Fri, 2 Sep 2016 00:48:31 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id u827mR58026607; Fri, 2 Sep 2016 09:48:27 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6A15E1D53C1; Fri, 2 Sep 2016 09:48:26 +0200 (CEST) Received: from 92.11.32.46 by webmail.entel.upc.edu with HTTP; Fri, 2 Sep 2016 09:48:29 +0200 Message-ID: In-Reply-To: References: Date: Fri, 2 Sep 2016 09:48:29 +0200 From: "Carles Gomez Montenegro" To: "core@ietf.org WG" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Fri, 02 Sep 2016 09:48:27 +0200 (CEST) Archived-At: Cc: "draft-koster-core-coap-pubsub@ietf.org" Subject: Re: [core] =?iso-8859-1?Q?=F0=9F=94=94_Working_Group_Adoption_of_draft-koster-core-c?=oap-pubsub 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 Sep 2016 07:48:34 -0000 Hi, I support WG adoption of this document. Cheers, Carles > On Mon, Aug 15, 2016 at 11:10 AM, Jaime Jiménez > > wrote: > >> Dear CoRE-WG, >> >> As we discussed at last IETF96, working group adoption has been >> requested >> for draft-koster-core-coap-pubsub. At the IETF meeting the room >> consensus >> was strongly supporting adoption (~10 people). Please reply to the list >> with your comments, including although not limited to whether or not you >> support adoption. Non-authors are especially encouraged to comment. >> >> Since there are several concurrent WGA calls, we will end the call on >> *August >> 26, 2016*. >> >> Thanks, >> Jaime and Carsten >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > > > -- > James Nguyen > Email: james.huy.nguyen@gmail.com > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Sun Sep 4 04:54: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 4BE8412B0B7; Sun, 4 Sep 2016 04:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3XYi1EhRMCl; Sun, 4 Sep 2016 04:54:48 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 85452126B6D; Sun, 4 Sep 2016 04:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1472990087; d=isode.com; s=june2016; i=@isode.com; bh=6WmOVVz5DcJ/MVNmBOEa12MYowybWu/+I6F33uwxntI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vuI4Z5iJfeGcw3tpgwqXTA5DZffM6tjxybeIllnuUzo8g6dUnRDClk5snQB4Y6JJQjCDdu ivPSpbJkxh2SAP38PzHffYe2VCG7+z3HJa+eW7t4eblUJs9ZjepvH8yjWMx2by1+btzth4 jpABFQ8qmObdlrh5iOpG6UcHslVO2yM=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 4 Sep 2016 12:54:47 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13G36) In-Reply-To: Date: Sun, 4 Sep 2016 13:07:13 +0100 Message-Id: References: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> To: "Fossati, Thomas (Nokia - GB)" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" Subject: Re: [core] AD review comments on draft-ietf-core-http-mapping-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 11:54:50 -0000 Hi Thomas, > On 1 Sep 2016, at 13:31, Fossati, Thomas (Nokia - GB) wrote: >=20 > Hi Alexey, >=20 > Thanks very much for your comments. >=20 >> In Section 4: I think you should add an informative reference to HTML5. >=20 > OK >=20 >> In 5.4.1.1, example 3: >>=20 >> Would it be better to define a separate variable (in addition to "tu") >> which doesn't include the scheme? I don't see how your current example 3 >> is valid as written, because your ABNF in 5.4.1 says that the scheme URI >> part is always included. >=20 > Last para of 5.4.1 "amends" the above ABNF saying: >=20 > "The same considerations as in Section 5.3.1 apply, in that the CoAP > scheme may be omitted from the Hosting HTTP URI." >=20 > Do you think it's not enough? I missed that. I think it would be much better to have correct ABNF with no t= extual amendments. >=20 >> In 6.3: is the table fixed or can implementations do variations of it? >=20 > The table is the default. It is expected that an implementation can > refine it based on a) application-specific knowledge, b) registration of > new Content-Formats. Ok. You might want to clarify that. >=20 >> Excuse my ignorance, but does does "htc" attribute need registering with >> IANA? >=20 > My understanding from previous discussions is that, since there doesn't > seem to be a registry for that, the hct attribute will be documented in > the Description of the new core.hc resource type in the "Resource Type > (rt=3D) Link Target Attribute Values" registry [1]. (I may be horribly > wrong, though.) Ok. Maybe a registry should be created. Not necessarily in this document. >> In 9.2: "encoding consideration" should say "binary", because if the >> specific content format is not known, we can't say anything more >> specific than "binary". >=20 > OK >=20 >> "Provisional Registration" - should be "no". >=20 > OK >=20 >> In 10.3, last para: is this actually a good idea? What about >> opportunistic security and desire to prevent pervasive monitoring? >=20 > Personally, I agree with you. My co-authors might have a different > opinion though? >=20 >> You are using Obsolete RFC 2616 reference. Please point to one or more >> latest HTTP/1.1 RFC. >=20 > We do (normatively) reference the HTTPbis specs. The reference to 2616 is= > informative only -- it is used to highlight a difference in treating 201 > responses' format between "original" HTTP and HTTPbis. >=20 >> Reported by ID-nits: RFC 2119 keyword use template doesn't match >> expected text. >=20 > Pardon my ignorance, but I don't understand what we'd need to fix here. Update the sentence that talks about 2119 keywords to have the standard form= . If you go to datatracker.ietf.org for your document and click on id-nits, i= t should tell you more. >=20 >> Should the document cover HTTP PATCH? >=20 > This point was also raised by Christian [2]. The consensus was to do > avoid blocking this work on draft-etch (or any other protocol extension). draft-etch is now in IETF LC, so I think this argument is no longer valid. W= as there any specific text proposed to cover PATCH on the mailing list? >=20 > The following text was added to reflect the outcome of that discussion: >=20 > "This document describes HTTP mappings that apply to protocol elements > defined in the base CoAP specification [RFC7252]. It is up to CoAP > protocol extensions (new methods, response codes, options, content- > formats) to describe their own HTTP mappings, if applicable." > Cheers, t >=20 > [1] http://www.iana.org/assignments/core-parameters/core-parameters.xhtml > [2] https://www.ietf.org/mail-archive/web/core/current/msg07411.html >=20 From nobody Sun Sep 4 06:32: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 3449312B215; Sun, 4 Sep 2016 06:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHyVZma21-1n; Sun, 4 Sep 2016 06:32:22 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750AA12B01E; Sun, 4 Sep 2016 06:32:22 -0700 (PDT) Received: from mfilter42-d.gandi.net (mfilter42-d.gandi.net [217.70.178.172]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 0204BA80CB; Sun, 4 Sep 2016 15:32:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter42-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter42-d.gandi.net (mfilter42-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 9eo4znV_NZsk; Sun, 4 Sep 2016 15:32:19 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B3580A80C0; Sun, 4 Sep 2016 15:32:18 +0200 (CEST) Message-ID: <57CC2260.3050501@tzi.org> Date: Sun, 04 Sep 2016 15:32:16 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Alexey Melnikov References: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" Subject: Re: [core] AD review comments on draft-ietf-core-http-mapping-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 13:32:24 -0000 Alexey Melnikov wrote: >>> Should the document cover HTTP PATCH? >> > >> > This point was also raised by Christian [2]. The consensus was to do >> > avoid blocking this work on draft-etch (or any other protocol extension). > > draft-etch is now in IETF LC, so I think this argument is no longer valid. Was there any specific text proposed to cover PATCH on the mailing list? >> > http-mapping is an informational document that is making use of the extensive experience we have with mapping between HTTP and CoAP. We don't have all that experience for PATCH yet. Anything we could write would be more speculative and, probably, premature. I'd rather do this in a future document. Grüße, Carsten From nobody Sun Sep 4 07:40: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 8653812B068; Sun, 4 Sep 2016 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox2EbV1vWOWj; Sun, 4 Sep 2016 07:40:30 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D82DC12B243; Sun, 4 Sep 2016 07:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1473000029; d=isode.com; s=june2016; i=@isode.com; bh=dbOHaRC8VRc8eJ2lxwGiKPW5GbKZukf5c+Ab9Kd5y1o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VkV4YxhopVn55PvUQYvtK1ZU2A/jFP5/qaBPEgg06TIr9HJj+gh/Hyv+k4JsCnZVJC/XiI B8ymLyEtnTdBwT9y879r3osvHIdjJ66+MofAN69iIbIUvEr237Yg1jvhO01fKL5VtFTPsK eQmCJoxD+dG2nUrSpqHVwACNq+XzXOA=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 4 Sep 2016 15:40:28 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13G36) In-Reply-To: <57CC2260.3050501@tzi.org> Date: Sun, 4 Sep 2016 15:52:55 +0100 Message-Id: References: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> <57CC2260.3050501@tzi.org> To: Carsten Bormann MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" Subject: Re: [core] AD review comments on draft-ietf-core-http-mapping-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 14:40:31 -0000 > On 4 Sep 2016, at 14:32, Carsten Bormann wrote: >=20 > Alexey Melnikov wrote: >>>> Should the document cover HTTP PATCH? >>>>=20 >>>> This point was also raised by Christian [2]. The consensus was to do >>>> avoid blocking this work on draft-etch (or any other protocol extension= ). >>=20 >> draft-etch is now in IETF LC, so I think this argument is no longer valid= . Was there any specific text proposed to cover PATCH on the mailing list? >>>>=20 >=20 > http-mapping is an informational document that is making use of the > extensive experience we have with mapping between HTTP and CoAP. >=20 > We don't have all that experience for PATCH yet. Anything we could > write would be more speculative and, probably, premature. I'd rather do > this in a future document. Fair enough. From nobody Sun Sep 4 13:39:57 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 22F2D12B298; Sun, 4 Sep 2016 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=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 SK_9L0QAbLdp; Sun, 4 Sep 2016 13:39:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07050127076; Sun, 4 Sep 2016 13:39:52 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A28E59ED4A585; Sun, 4 Sep 2016 20:39:47 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u84KdoHe016373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Sep 2016 20:39:51 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u84KdnRU017086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Sep 2016 22:39:50 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.184]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 4 Sep 2016 22:39:49 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Alexey Melnikov , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] AD review comments on draft-ietf-core-http-mapping-13 Thread-Index: AQHSBDu9w9KVoyLgVkyeIw5xc36+tKBkgDcAgASfiICAAJ/0gA== Date: Sun, 4 Sep 2016 20:39:49 +0000 Message-ID: References: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" Subject: Re: [core] AD review comments on draft-ietf-core-http-mapping-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 20:39:55 -0000 Hi Alexey, On 04/09/2016 13:07, "Alexey Melnikov" wrote: >>>In 5.4.1.1, example 3: >>>=20 >>> Would it be better to define a separate variable (in addition to "tu") >>> which doesn't include the scheme? I don't see how your current example >>>3 >>> is valid as written, because your ABNF in 5.4.1 says that the scheme >>>URI >>> part is always included. >>=20 >> Last para of 5.4.1 "amends" the above ABNF saying: >>=20 >> "The same considerations as in Section 5.3.1 apply, in that the CoAP >> scheme may be omitted from the Hosting HTTP URI." >>=20 >> Do you think it's not enough? > >I missed that. I think it would be much better to have correct ABNF with >no textual amendments. Will do. >>=20 >>> In 6.3: is the table fixed or can implementations do variations of it? >>=20 >> The table is the default. It is expected that an implementation can >> refine it based on a) application-specific knowledge, b) registration of >> new Content-Formats. > >Ok. You might want to clarify that. Will do. >>=20 >>> Excuse my ignorance, but does does "htc" attribute need registering >>>with >>> IANA? >>=20 >> My understanding from previous discussions is that, since there doesn't >> seem to be a registry for that, the hct attribute will be documented in >> the Description of the new core.hc resource type in the "Resource Type >> (rt=3D) Link Target Attribute Values" registry [1]. (I may be horribly >> wrong, though.) > >Ok. Maybe a registry should be created. Not necessarily in this document. OK, I'd rather skip this then :-) >>>Reported by ID-nits: RFC 2119 keyword use template doesn't match >>> expected text. >>=20 >> Pardon my ignorance, but I don't understand what we'd need to fix here. > >Update the sentence that talks about 2119 keywords to have the standard >form. If you go to datatracker.ietf.org for your document and click on >id-nits, it should tell you more. I've been staring at the thing for a while and it appears correct to me. It looks like idnits doesn't take into consideration the RFC 2119 errata (specifically errata 499 at [1])? >>=20 >>> Should the document cover HTTP PATCH? >>=20 >> This point was also raised by Christian [2]. The consensus was to do >> avoid blocking this work on draft-etch (or any other protocol >>extension). > >draft-etch is now in IETF LC, so I think this argument is no longer >valid. Was there any specific text proposed to cover PATCH on the mailing >list? Below in this same thread I see you agree with Carsten's argument re: lack of implementation experience wrt the PATCH mapping. I'm going to drop this then. I'll be back with a revised version that takes into account your comments as well as the Gen-ART review shortly. Cheers, thanks, t [1] https://www.rfc-editor.org/errata_search.php?rfc=3D2119 From nobody Mon Sep 5 01:43: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 5CACE12B322; Mon, 5 Sep 2016 01:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA_Oa_g02MJY; Mon, 5 Sep 2016 01:43:00 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AB712B329; Mon, 5 Sep 2016 01:42:59 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-5e-57cd3012d2eb Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 52.61.02553.2103DC75; Mon, 5 Sep 2016 10:42:58 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.215]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Mon, 5 Sep 2016 10:42:51 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: Christian Groves Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBk?= =?utf-8?Q?raft-groves-core-dynlink?= Thread-Index: AQHR9wZnahU7ZPN6rEK7KKBHbT/BeqBbE3YAgAcWoYCACGlMAA== Date: Mon, 5 Sep 2016 08:42:51 +0000 Message-ID: References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> <3A9C9924-D032-4BEE-9B78-DF94680A7C95@ericsson.com> <57879b61-d9fc-2cce-d56a-7bd9c78c2ff7@nteczone.com> In-Reply-To: <57879b61-d9fc-2cce-d56a-7bd9c78c2ff7@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_2A9F4F45-3934-4779-A2DC-6CC7B89473C4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7oq6Qwdlwg2cbhSyOTLnLavHlfSOL xb6365ktVv14wujA4rFkyU8mjxXnZ7J4TFuUGcAcxWWTkpqTWZZapG+XwJXR9XMfe8Epi4pz s3qYGhhbTLsYOTkkBEwkjj47ydLFyMUhJLCeUWLfvnZGkISQwGJGiQ/L9EBsNgFniU/PGtm7 GDk4RIAa5p/VBKlnFpjMKPFi/0+wemGBGonPx1+xgtgiArUST/++hrKdJP7v3sAOYrMIqEhc vdTJAmLzCthL3NnbywSxeDXQ4kV9YIM4BRwkvn44BtbMKCAm8f3UGiYQm1lAXOLWk/lMEFeL SDy8eJoNwhaVePn4HyuErSSx6PZnJojrpjBKrLt5nBVim6DEyZlPWCYwisxCMmsWsrpZSOog irQlli18zQxha0rs714OFTeVeH30IyOEbS0x49dBNghbUWJK90P2BYwcqxhFi1OLk3LTjYz0 Uosyk4uL8/P08lJLNjECI/Lglt8GOxhfPnc8xCjAwajEw6uQeCZciDWxrLgy9xCjCtCcRxtW X2CUYsnLz0tVEuEN1D8bLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFq EUyWiYNTqoFx+iJBNc9anXf/7bRtfi0zfvJFO13Ry6vaVI/nhNFPlvgvthacv2rKbzJt6zm3 fc6p3SFTmVUzX38M9vSauGB30IyruwttyxJsrPR0WZZcMa55lzUnXkX+9WaJyhXvmuSbWw9Z yvzVLheYtJr1uNMW5hYn0UUV7AvmNebOij+zSuDx3BOqW4uVWIozEg21mIuKEwHSXa6c0AIA AA== Archived-At: Cc: "draft-groves-core-dynlink@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-groves-core-dynlink?= 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 Sep 2016 08:43:03 -0000 --Apple-Mail=_2A9F4F45-3934-4779-A2DC-6CC7B89473C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, there has been no feedback apart from that of the authors of this draft. = Therefore we will be extending the deadline for this draft and we will = try to reach a conclusion by the end of this week. Ciao, - - Jaime Jim=C3=A9nez > On 31 Aug 2016, at 03:15, Christian Groves = wrote: >=20 > No surprise as author I support the draft.. >=20 > Regards, Christian >=20 >=20 > On 26/08/2016 10:01 PM, Jaime Jim=C3=A9nez wrote: >> Hi all, >>=20 >> As people are on vacation, let=E2=80=99s extend the deadline few days = more to allow people to comment. >>=20 >> Ciao! >> - - Jaime Jimenez >>=20 >>> On 15 Aug 2016, at 18:05, Jaime Jim=C3=A9nez = > wrote: >>>=20 >>> Dear CoRE-WG, >>>=20 >>> As we discussed at last IETF96, working group adoption has been = requested for draft-groves-core-dynlink. This draft is the result of a = document split and thus the initial status is that of adoption, = nevertheless that has to be confirmed on the list. Please reply with = your comments, including although not limited to whether or not you = support adoption. Non-authors are especially encouraged to comment. >>>=20 >>> Since there are several concurrent WGA calls, we will end the call = on *August 26, 2016*. >>>=20 >>> Thanks, >>> Jaime and Carsten >>=20 >=20 --Apple-Mail=_2A9F4F45-3934-4779-A2DC-6CC7B89473C4 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDUwODQyNTBaMCMGCSqGSIb3DQEJBDEWBBQ2 /XE7ek6j2FdW53e0lHJXc460dDBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQCaPoztOcJj52TFyFk1TwM5afEqPG2VhhqMXfYoOkfj93xg20Pipkynqnj6GRlqGav4bpQmug+4 wAsEd8CDhRYvCUk8tZjl0S45fDfvS60GqmD61acTXUiLIMjttegmfSe4d51FM2pHJIzbd55O0Ux/ ZkAMdinTjN4PKYnYAwinW/QYyjGIRgrir3cZFqIlyhFcsDbNG+rGgL01pXtKnjpJDKdoJeFKVKXJ negBHCR6KjAPclJOi8Cj3PU8pmIJrJr0NM3jqsbliZWLoCaMFiFUQUnsrKMYli/m/jPrWOviymu3 w4HinvVu80JgttGPTfU1YFfr3iKxCHrL1spiYXyaAAAAAAAA --Apple-Mail=_2A9F4F45-3934-4779-A2DC-6CC7B89473C4-- From nobody Mon Sep 5 07:33: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 D34ED12B3FD; Mon, 5 Sep 2016 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=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 HO_tUSGB2rUX; Mon, 5 Sep 2016 07:33:21 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6339D12B408; Mon, 5 Sep 2016 07:33:04 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B6F4295DDD762; Mon, 5 Sep 2016 14:32:59 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u85EX1DP002587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2016 14:33:02 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u85EX1bY026729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Sep 2016 16:33:01 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.184]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 5 Sep 2016 16:33:01 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Alexey Melnikov , "core@ietf.org" Thread-Topic: [core] AD review comments on draft-ietf-core-http-mapping-13 Thread-Index: AQHSBDu9w9KVoyLgVkyeIw5xc36+tKBq65AA Date: Mon, 5 Sep 2016 14:33:01 +0000 Message-ID: References: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> In-Reply-To: <5ca327bc-4eab-8f1d-ac6d-691e59531292@isode.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <09561721A517FE408D96E52C964CC57F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" Subject: Re: [core] AD review comments on draft-ietf-core-http-mapping-13 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 Sep 2016 14:33:23 -0000 Hi Alexey, On 01/09/2016 11:29, "core on behalf of Alexey Melnikov" wrote: >In 10.3, last para: is this actually a good idea? What about >opportunistic security and desire to prevent pervasive monitoring? When we say: "By default, a HC proxy SHOULD reject any secured client request if there is no configured security policy mapping [...]" The secured client request we are talking about is the embedded CoAP client request, rather than the HTTP. In which case, I guess the current text is fine -- except that we will explicitly say "secured *CoAP* client request" to avoid any further discombobulation. Cheers, t From nobody Tue Sep 6 00:23: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 967B212B0D2 for ; Tue, 6 Sep 2016 00:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVRstXnK9zg0 for ; Tue, 6 Sep 2016 00:23:00 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72C012B091 for ; Tue, 6 Sep 2016 00:22:59 -0700 (PDT) Received: from vsmta14.fe.internet.bosch.com (unknown [10.4.98.54]) by imta24.fe.bosch.de (Postfix) with ESMTP id 58B63D80212 for ; Tue, 6 Sep 2016 09:22:56 +0200 (CEST) Received: from be6vw2exc00.bosch-si.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta14.fe.internet.bosch.com (Postfix) with ESMTP id E621FA406B1 for ; Tue, 6 Sep 2016 09:22:55 +0200 (CEST) Received: from BE6PW2EXD01.bosch-si.com ([fe80::5407:24a5:e587:d9d7]) by be6vw2exc00.bosch-si.com ([::1]) with mapi id 14.03.0224.002; Tue, 6 Sep 2016 09:23:19 +0200 From: "Hudalla Kai (INST/ESY1)" To: "core@ietf.org" Thread-Topic: [core] Implications of IP address / port changes for CoAP & Co Thread-Index: AQHSA3OpWmipJXOlRUiW3rf65AfMCqBr9okA Date: Tue, 6 Sep 2016 07:23:19 +0000 Message-ID: <1473146574.5588.23.camel@bosch-si.com> References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> In-Reply-To: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.56.65.50] Content-Type: text/plain; charset="utf-8" Content-ID: <0F10E1114042164F918E0B412669C4F1@bosch-si.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22556.006 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wkKcYi5Qw/RVFJFr2qlKix9QHRootjC6nHq8 FiyB7cW9lTJXKqh1ne3lPWOZdnoFfCnPugGsN3p5CFaAixm5eU+Hxi2fvkKUM0ENV4Lwnu7BAG6 jwzk3GfjoIqJYnT70stvCQJvMkAdmD71CZKFRa8Jz5CFYokzTg1AI6wCVrE3vdEG7y+D7o5B5Hv UK8H+FBsroQHliDcnitWLt+9LzHVZJ+HTEll5bHb8P2gGjGpF1k9atiES99p3EgdOHOsnRcxfd/ FXuN1HJxjxLgI2NiDfq9Pq/fj26fjzqOmsIGhM5R0BY8wG7yRBF60yD8pDnuSy6DFF5hapm9VEc r7eTzMtjQvs2OIy6SntZCpfMKy9f3Lit/ZLn13VPuMJi/ZAk8XnL427v8Q46u6qThyrnanPS+M6 0ghWiXrnwSRu3RZ3sJX8vrUcDLuPb6y/VkfElypVIEKhlTKps0w14HFJQjaPwJgHNac3RREjRI6 LihWOUaP3Fs19NB8kxeamNUxAG93upOhUR/AE8YR6QE8KYfsgfOdo4H355iCWrO+SgZCHmt1J5V mhqLvzz8wHBATsUGe7LLNinZnVCPOqr6B64RIBH4a2iJdV4MTQquvryvQIW17X4XB0kp3vBRwT7 V3s67YnUG+96/7NAZ6PqbR6kgO5sVT/AhHGTVC4uTw19Klh6MZm0+sEE9mudCqKtxM6bh7Xjz1T j1+sCMlOnhY6v1VhHsouQy6lQT0AVhvrFVbyTq1ZJZ2z+SbYdQSyPGb6mCEdmDSBYfnJR20Zc3X xE3uPSxyw2jzXOHUXz+fkcHI+PxJDbqFwyPYSeAiCmPx4NwMFrpUbb72MU1B0Hk1Q1KyLUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co 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, 06 Sep 2016 07:23:03 -0000 SGFubmVzLA0KDQp0aGFua3MgZm9yIHNwYXduaW5nIHRoaXMgdGhyZWFkLiBBcyBvbmUgb2YgdGhl IGNvbW1pdHRlcnMgZm9yIHRoZQ0KQ2FsaWZvcm5pdW0gQ29BUCBzdGFjayBJIGNhbiB0ZWxsIHlv dSB0aGF0IHdlIGFyZSBjdXJyZW50bHkgc3RydWdnbGluZw0KcXVpdGUgYSBsb3Qgd2l0aCB0aGUg ImFtYmlndWl0eSIgb2YgdGhlIENvQVAgc3BlYyB3aGVuIGl0IGNvbWVzIHRvDQpkZWZpbml0aW9u IGFuZCAiaWRlbnRpZnlpbmcgY2hhcmFjdGVyaXN0aWNzIiBvZiBFbmRwb2ludHMgYW5kIGl0cw0K aW1wbGljYXRpb25zIG9uIHJlcXVlc3QvcmVzcG9uc2UgbWF0Y2hpbmcuDQoNCkkgaGF2ZSBtYWRl IHNvbWUgY29tbWVudHMgYmVsb3cuLi4NCg0KUmVnYXJkcywNCkthaQ0KDQpPbiBNaSwgMjAxNi0w OC0zMSBhdCAxMjozNiArMDIwMCwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IEhpIGFsbCwN Cj4gDQo+IGluIHRoZSBPTUEgZGV2aWNlIG1hbmFnZW1lbnQgZ3JvdXAgd2UgaGF2ZSBiZWVuIGRp c2N1c3NpbmcgdGhlwqANCj4gaW1wbGljYXRpb25zIG9mIElQIGFkZHJlc3MgYW5kL29yIHBvcnQg bnVtYmVyIGNoYW5nZXMgb2YgZGV2aWNlc8KgDQo+IChwYXJ0aWN1bGFybHkgd2l0aCBkZXZpY2Vz IHRoYXQgc2xlZXAgZm9yIGFuIGV4dGVuZGVkIHBlcmlvZCBvZg0KPiB0aW1lKS4NCj4gDQo+IFRo ZSBjaGFsbGVuZ2UgZnJvbSBhIHByb3RvY29sIHBvaW50IG9mIHZpZXcgaXMgdG8gdXNlIGFuIGlk ZW50aWZpZXINCj4gdGhhdMKgDQo+IGRvZXMgbm90IGRlcGVuZCBvbiB0aGUgSVAgYWRkcmVzcyBh bmQgcG9ydC4gT2YgY291cnNlLCB3aGVuIGEgSVANCj4gcGFja2V0wqANCj4gaGFzIHRvIGJlIHNl bnQgdG8gYSBzcGVjaWZpYyBub2RlIHRoZW4gSVAgYWRkcmVzcyBhbmQgcG9ydA0KPiBpbmZvcm1h dGlvbsKgDQo+IGhhcyB0byBiZSB1c2VkIGZyb20gc29tZXdoZXJlIGJ1dCBteSBleHBlY3RhdGlv biBpcyB0aGF0IGF0IGxlYXN0DQo+IHRoZcKgDQo+IHByb3RvY29sIG1hY2hpbmVyeSBzaG91bGRu J3QgYnJlYWsgd2hlbiBhbiBJUCBhZGRyZXNzIGNoYW5nZXMgKG9yDQo+IHRoZXJlwqANCj4gc2hv dWxkIGJlIGEgc3RvcnkgZm9yIGhvdyB0byByZWNvdmVyKS4NCj4gDQpJIGRvbid0IHRoaW5rIHRo YXQgdGhlIENvQVAgcHJvdG9jb2wgImJyZWFrcyIgd2hlbiBhIHBlZXIncyBJUCBhZGRyZXNzDQoo b3IgcG9ydCkgY2hhbmdlcy4gVGhlIHByb2JsZW0gaXMgbW9yZSB0aGF0IHRoZSB3YXkgQ29BUCdz IHN0cmljdA0KcmVxdWVzdC9yZXNwb25zZSBtYXRjaGluZyBydWxlcyBjdXJyZW50bHkgcHJldmVu dCBzb21lIG9mIHRoZSBtb3JlDQppbnRlcmVzdGluZyB1c2UgY2FzZXMgKG9ic2VydmluZyByZXNv dXJjZXMpIHRvIGJlIGltcGxlbWVudGVkIHdpdGgNCmNvbnN0cmFpbmVkIGRldmljZXMgY29ubmVj dGVkIHRvIElQdjQgbmV0d29ya3MgdmlhIE5BVGVkIGZpcmV3YWxscw0KKHdoaWNoIGlzIGJhc2lj YWxseSBFVkVSWSBkZXZpY2UgY29ubmVjdGVkIHZpYSBhIG1vYmlsZSBuZXR3b3JrDQpjYXJyaWVy KS4NCg0KPiBJbiBDb0FQIHRoZSAnZW5kcG9pbnQnIGFwcGVhcnMgdG8gYmUgYW4gaW1wb3J0YW50 IGlkZW50aWZpZXIuIEluIGFuwqANCj4gYXR0ZW1wdCB0byBkZWZpbmUgd2hhdCBhbiBlbmRwb2lu dCBpcyB0aGUgQ29BUCBzcGVjaWZpY2F0aW9uIGlzIGENCj4gYml0wqANCj4gY29uZnVzaW5nOg0K PiANCj4gU2VjdGlvbiAxLjIgc2F5czoNCj4gDQo+ICINCj4gwqDCoMKgwqBFbmRwb2ludA0KPiDC oMKgwqDCoMKgwqDCoEFuIGVudGl0eSBwYXJ0aWNpcGF0aW5nIGluIHRoZSBDb0FQIHByb3RvY29s LsKgwqBDb2xsb3F1aWFsbHksDQo+IGFuDQo+IMKgwqDCoMKgwqDCoMKgZW5kcG9pbnQgbGl2ZXMg b24gYSAiTm9kZSIsIGFsdGhvdWdoICJIb3N0IiB3b3VsZCBiZSBtb3JlDQo+IMKgwqDCoMKgwqDC oMKgY29uc2lzdGVudCB3aXRoIEludGVybmV0IHN0YW5kYXJkcyB1c2FnZSwgYW5kIGlzIGZ1cnRo ZXINCj4gwqDCoMKgwqDCoMKgwqBpZGVudGlmaWVkIGJ5IHRyYW5zcG9ydC1sYXllciBtdWx0aXBs ZXhpbmcgaW5mb3JtYXRpb24gdGhhdA0KPiBjYW4NCj4gwqDCoMKgwqDCoMKgwqBpbmNsdWRlIGEg VURQIHBvcnQgbnVtYmVyIGFuZCBhIHNlY3VyaXR5IGFzc29jaWF0aW9uDQo+IMKgwqDCoMKgwqDC oMKgKFNlY3Rpb24gNC4xKS4NCj4gIgkNCj4gDQo+IFNlY3Rpb24gNC4xIG9mIFJGQyA3MjUyIHNh eXM6DQo+IAkNCj4gIg0KPiDCoMKgwqDCoEEgQ29BUCBlbmRwb2ludCBpcyB0aGUgc291cmNlIG9y IGRlc3RpbmF0aW9uIG9mIGEgQ29BUA0KPiBtZXNzYWdlLsKgwqBUaGUNCj4gwqDCoMKgwqBzcGVj aWZpYyBkZWZpbml0aW9uIG9mIGFuIGVuZHBvaW50IGRlcGVuZHMgb24gdGhlIHRyYW5zcG9ydCBi ZWluZw0KPiDCoMKgwqDCoHVzZWQgZm9yIENvQVAuwqDCoEZvciB0aGUgdHJhbnNwb3J0cyBkZWZp bmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiwNCj4gdGhlDQo+IMKgwqDCoMKgZW5kcG9pbnQgaXMg aWRlbnRpZmllZCBkZXBlbmRpbmcgb24gdGhlIHNlY3VyaXR5IG1vZGUgdXNlZCAoc2VlDQo+IMKg wqDCoMKgU2VjdGlvbiA5KTogV2l0aCBubyBzZWN1cml0eSwgdGhlIGVuZHBvaW50IGlzIHNvbGVs eSBpZGVudGlmaWVkDQo+IGJ5IGFuDQo+IMKgwqDCoMKgSVAgYWRkcmVzcyBhbmQgYSBVRFAgcG9y dCBudW1iZXIuwqDCoFdpdGggb3RoZXIgc2VjdXJpdHkgbW9kZXMsIHRoZQ0KPiDCoMKgwqDCoGVu ZHBvaW50IGlzIGlkZW50aWZpZWQgYXMgZGVmaW5lZCBieSB0aGUgc2VjdXJpdHkgbW9kZS4NCj4g Ig0KPiANCj4gVGhlIHR3byBkZWZpbml0aW9ucyBkbyBub3QgYXBwZWFyIHRvIGJlIGluIHN5bmMs IHBhcnRpY3VsYXJseSB3aGVuDQo+IHVzaW5nwqANCj4gRFRMUyB0byBzZWN1cmUgQ29BUCBzaW5j ZSB0aGUgRFRMUyByZWNvcmQgbGF5ZXIgYWRkcyBub3RoaW5nIHdpdGjCoA0KPiByZXNwZWN0IHRv IGFkZGl0aW9uYWwgbXVsdGlwbGV4aW5nLiBJIGFsc28gZGlkIG5vdCBmaW5kIHRleHQgdGhhdMKg DQo+IGRlc2NyaWJlcyB3aGF0IHRoZSBkaWZmZXJlbnQgZW5kcG9pbnQgZGVmaW5pdGlvbiBpcyB3 aGVuIERUTFMgaXMNCj4gdXNlZC4NCj4gDQpJbiBwYXJ0aWN1bGFyLCB0aGUgZGVmaW5pdGlvbiBp cyByZWZlcnJpbmcgdG8gbWlzc2luZyBpbmZvcm1hdGlvbi4NClNlY3Rpb24gOSBzaW1wbHkgZG9l c24ndCBjb250YWluIGFueSBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlDQppZGVudGlmeWluZyBj aGFyYWN0ZXJpc3RpY3MgKGF0IHRoZSBDb0FQIGxheWVyKSBvZiBhbiBlbmRwb2ludCB3aGVuDQp1 c2luZyBhbnkgb2YgdGhlIG5vbi1Ob1NlYyBzZWN1cml0eSBtb2Rlcy4gT3IgYXQgbGVhc3QgaXQg aXMgdW5jbGVhcg0Kd2hldGhlciB0aGUgZGV2aWNlJ3MgImlkZW50aXR5IiBlc3RhYmxpc2hlZCBi eSBtZWFucyBvZiBhdXRoZW50aWNhdGluZw0KaXQgZS5nLiBiYXNlZCBvbiBhIFBTSyBvciBhIGNl cnRpZmljYXRlIGlzIGFsc28gbWVhbnQgdG8gYmUgdXNlZCBhcyB0aGUNCmVuZHBvaW50IGlkZW50 aXR5IGF0IHRoZSBDb0FQIHByb3RvY29sIGxldmVsLiBJTUhPIHRoYXQgaXMgbm90IHRoZSBjYXNl DQphbmQgdGhhdCBpcyBhbHNvIHdoeSB3ZSBhcmUgYWx3YXlzIGp1c3QgdXNpbmcgdGhlIElQIGFk ZHJlc3MgYW5kIHBvcnQNCm51bWJlciBhcyB0aGUgaWRlbnRpZnlpbmcgY2hhcmFjdGVyaXN0aWNz IG9mIGFuIGVuZHBvaW50Lg0KDQo+IEluIGFueSBjYXNlLCB3aGVuIERUTFMgaXMgdXNlZCBhbiBJ UCBhZGRyZXNzIC8gcG9ydCBjaGFuZ2UgYXQgdGhlDQo+IGNsaWVudMKgDQo+IHdpbGwgcHJldmVu dCB0aGUgQ29BUCBzZXJ2ZXIgZnJvbSBmaW5kaW5nIHRoZSByaWdodCBzZWN1cml0eSBjb250ZXh0 DQo+IGFuZMKgDQo+IGEgbmV3IChob3BlZnVsbHkgYWJicmV2aWF0ZWQpIGhhbmRzaGFrZSBoYXMg dG8gYmUgcnVuLg0KPiANClRoZSBjbGllbnQgY291bGQgaW5kZWVkIHVzZSBhbiBhYmJyZXZpYXRl ZCBoYW5kc2hha2UsIGkuZS4gcmVzdW1lIHRoZQ0KRFRMUyBzZXNzaW9uLCBpZiBpdCB3ZXJlIGF3 YXJlIG9mIHRoZSBmYWN0IHRoYXQgaXRzIElQIGFkZHJlc3Mgb3IgcG9ydA0KaGFkIGNoYW5nZWQg ZHVyaW5nIGl0cyBsYXN0IHNsZWVwIGN5Y2xlLiBIb3dldmVyLCBmb3IgdGhhdCB0aGUgY2xpZW50 DQp3b3VsZCBwcm9iYWJseSBuZWVkIHRvIHVzZSBzb21ldGhpbmcgbGlrZSBTVFVOIGZpcnN0IC4u Lg0KDQo+IEx1Y2tpbHkgdGhlIGltcGxpY2F0aW9ucyBvZiBhbiBJUCBhZGRyZXNzL3BvcnQgY2hh bmdlIGFyZSBxdWl0ZQ0KPiBtaW5pbWFswqANCj4gZm9yIENvQVAgaXRzZWxmIHNpbmNlIHRoZSBv bmx5IGltcGFjdCAoYXMgZmFyIGFzIEkgY2FuIHRlbGwpIGlzIHdpdGjCoA0KPiByZWdhcmRzIHRv IHRoZSB1c2Ugb2YgcmVxdWVzdC9yZXNwb25zZSBleGNoYW5nZSwgYXMgZGVzY3JpYmVkIGluDQo+ IFNlY3Rpb27CoA0KPiA1LjMuMiAiUmVxdWVzdC9SZXNwb25zZSBNYXRjaGluZyBSdWxlcyIuIFRo ZSBsaWtlbGlob29kIHRoYXQgYQ0KPiBjbGllbnTCoA0KPiBjaGFuZ2VzIElQIGFkZHJlc3MgaW4g dGhlIG1pZGRsZSBvZiBhIHJlcXVlc3QvcmVzcG9uc2UgaW50ZXJhY3Rpb24NCj4gYXJlwqANCj4g SU1ITyBtaW5pbWFsLg0KPiANCkkgYWdyZWUsIHRoYXQgY2hhbmNlIGlzIG1pbmltYWwuIFRoZSBt b3JlIHByZXZhbGVudCBwcm9ibGVtIGlzIHRoYXQNCndpdGggY29uc3RyYWluZWQgZGV2aWNlcyBs aWtlIHNtYWxsIHNlbnNvciBub2RlcyB3aGljaCBzbGVlcCBtb3N0IG9mDQp0aGUgdGltZSwgdGhl IHByb2JhYmlsaXR5IHRoYXQgdGhleSB3YWtlIHVwIGFuZCB1c2UgYSBuZXcgSVAgYWRkcmVzcw0K KG9yIGEgbmV3IHBvcnQpIGZvciBvdXRib3VuZCBVRFAgcGFja2V0cyBpcyBjbG9zZSB0byAxLg0K DQoNCj4gVGhlIHN0b3J5IGlzIG1vcmUgaW50ZXJlc3Rpbmcgd2hlbiB3ZSBsb29rIGF0IGV4dGVu c2lvbnMgdG8gQ29BUCwNCj4gbGlrZcKgDQo+IENvQVAgT2JzZXJ2ZS4gU2VjdGlvbiA0LjEgb2Yg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NDENCj4gc2F5czoNCj4gDQo+ICINCj4g wqDCoMKgwqBUaGUgZW50cnkgaW4gdGhlIGxpc3Qgb2Ygb2JzZXJ2ZXJzIGlzIGtleWVkIGJ5IHRo ZSBjbGllbnQNCj4gZW5kcG9pbnQNCj4gwqDCoMKgwqBhbmQgdGhlIHRva2VuIHNwZWNpZmllZCBi eSB0aGUgY2xpZW50IGluIHRoZSByZXF1ZXN0LsKgwqBJZiBhbg0KPiBlbnRyeQ0KPiDCoMKgwqDC oHdpdGggYSBtYXRjaGluZyBlbmRwb2ludC90b2tlbiBwYWlyIGlzIGFscmVhZHkgcHJlc2VudCBp biB0aGUNCj4gbGlzdA0KPiDCoMKgwqDCoCh3aGljaCwgZm9yIGV4YW1wbGUsIGhhcHBlbnMgd2hl biB0aGUgY2xpZW50IHdpc2hlcyB0byByZWluZm9yY2UNCj4gaXRzDQo+IMKgwqDCoMKgaW50ZXJl c3QgaW4gYSByZXNvdXJjZSksIHRoZSBzZXJ2ZXIgTVVTVCBOT1QgYWRkIGEgbmV3IGVudHJ5IGJ1 dA0KPiBNVVNUDQo+IMKgwqDCoMKgcmVwbGFjZSBvciB1cGRhdGUgdGhlIGV4aXN0aW5nIG9uZS4N Cj4gIg0KPiANCj4gV2l0aCBPYnNlcnZlIGEgdG9rZW4gaXMgdXNlZCBmb3IgZGVtdWx0aXBsZXhp bmcgKGluIGFkZGl0aW9uIHRvIHRoZcKgDQo+IGVuZHBvaW50IGluZm8pLiBJIGFzc3VtZSB0aGF0 IHRoZSBzcGVjIHVzZXMgdGhlIHNhbWUgZGVmaW5pdGlvbiBvZsKgDQo+IGVuZHBvaW50IGFzIGlu IENvQVAuDQo+IA0KPiBXaGlsZSB0aGUgc3BlYyBkb2VzIG5vdCBzYXkgd2hhdCBpcyBhY3R1YWxs eSBiZWluZyB1cGRhdGVkIG9yDQo+IHJlcGxhY2VkwqANCj4gb25lIGNhbiBhc3N1bWUgdGhhdCBh IGNsaWVudCBzZW5kaW5nIGEgcmVxdWVzdCB3aXRoIGEgbmV3IElQIGFkZHJlc3MNCj4gYW5kwqAN Cj4gcG9ydCAod2hpY2ggY29ycmVzcG9uZHMgdG8gdGhlIGVuZHBvaW50IGRlZmluaXRpb24gaW4g Q29BUCkgZ2V0cyBhdMKgDQo+IGxlYXN0IHRoYXQgaW5mb3JtYXRpb24gdXBkYXRlZC4NCj4gDQo+ IFRoZSBzcGVjIGlzIElNSE8gdW5jbGVhciB3aGF0IHNob3VsZCBoYXBwZW4gaW4gY2FzZSBvZiBh biBJUMKgDQo+IGFkZHJlc3MvcG9ydCBjaGFuZ2UuIEkgc3VzcGVjdCB0aGF0IGFuIGltcGxlbWVu dGF0aW9uIHdvdWxkIHNlbmQgYQ0KPiBuZXfCoA0KPiByZWdpc3RlciBtZXNzYWdlIGFuZCB0aGUg c2VydmVyIHdvdWxkIHVwZGF0ZSBzdGF0ZS4gT2YgY291cnNlLCB3aGVuDQo+IHRoZcKgDQo+IElQ IGFkZHJlc3MgLyBwb3J0IG9mIHRoZSBjbGllbnQgaXMgbm90IGluIHN5bmMgd2l0aCB3aGF0IGlz IGJlaW5nDQo+IHN0b3JlZMKgDQo+IGF0IHRoZSBzZXJ2ZXIgdGhlbiB0aGUgbm90aWZpY2F0aW9u cyBzZW50IGJ5IHRoZSBzZXJ2ZXIgd2lsbCBub3QNCj4gcmVhY2jCoA0KPiB0aGUgY2xpZW50Lg0K PiANCg0KVGhlIG1vcmUgaW50ZXJlc3RpbmcgcHJvYmxlbSBpcyBob3cgd2UgZGVhbCB3aXRoIGEg Y2hhbmdlZCBJUA0KYWRkcmVzcy9wb3J0IG9uIHRoZSBDb0FQIHNlcnZlciBzaWRlLCBpLmUuIHdo ZW4gYSBjbGllbnQgaGFzIHN0YXJ0ZWQgdG8NCm9ic2VydmUgYSByZXNvdXJjZSBvbiB0aGUgc2Vy dmVyIGFuZCBub3cgZXhwZWN0cyBub3RpZmljYXRpb25zIGNvbWluZw0KaW4gZnJvbSB0aGF0IHNl cnZlci4gV2hlbiB0aGUgc2VydmVyJ3MgKHRoZSBjb25zdHJhaW5lZCBkZXZpY2UncykgSVANCmFk ZHJlc3Mgb3IgcG9ydCBjaGFuZ2VzLCBpdCBzZW5kcyBvdXQgbm90aWZpY2F0aW9ucyAoQ29BUCBy ZXNwb25zZXMpDQp3aXRoIGEgZGlmZmVyZW50IHNvdXJjZSBlbmRwb2ludCB0aGFuIHdoYXQgdGhl IGNsaWVudCBleHBlY3RzLg0KDQpUaGUgQ29BUCBzcGVjcyBzdGF0ZXMgaW4gc2VjdGlvbiA5LjEu MjoNCg0KIlRoZSBmb2xsb3dpbmcgcnVsZXMgYXJlIGFkZGVkIGZvciBtYXRjaGluZyBhIHJlc3Bv bnNlIHRvIGEgcmVxdWVzdDoNClRoZSBEVExTIHNlc3Npb24gTVVTVCBiZSB0aGUgc2FtZSwgYW5k IHRoZSBlcG9jaCBNVVNUIGJlIHRoZSBzYW1lLg0KDQpUaGlzIG1lYW5zIHRoZSByZXNwb25zZSB0 byBhIERUTFMgc2VjdXJlZCByZXF1ZXN0IE1VU1QgYWx3YXlzIGJlIERUTFMNCnNlY3VyZWQgdXNp bmcgdGhlIHNhbWUgc2VjdXJpdHkgc2Vzc2lvbiBhbmQgZXBvY2guwqDCoEFueSBhdHRlbXB0IHRv DQpzdXBwbHkgYSBOb1NlYyByZXNwb25zZSB0byBhIERUTFMgcmVxdWVzdCBzaW1wbHkgZG9lcyBu b3QgbWF0Y2ggdGhlDQpyZXF1ZXN0IGFuZCB0aGVyZWZvcmUgTVVTVCBiZSByZWplY3RlZCAodW5s ZXNzIGl0IGRvZXMgbWF0Y2ggYW4NCnVucmVsYXRlZCBOb1NlYyByZXF1ZXN0KS4iDQoNCm15IHVu ZGVyc3RhbmRpbmcgb2YgdGhpcyBwYXJhZ3JhcGggaXMgdGhhdCBhbnkgbm90aWZpY2F0aW9uIHJl Y2VpdmVkDQpmcm9tIGEgc2VydmVyIGFmdGVyIGl0cyBJUCBhZGRyZXNzIG9yIHBvcnQgaGFzIGNo YW5nZWQgbXVzdCBiZQ0KZGlzY2FyZGVkL3JlamVjdGVkIGJ5IHRoZSBjbGllbnQuIEhvd2V2ZXIs IHRoaXMgaXMgYmFzZWQgb24gdGhlDQphc3N1bXB0aW9uIHRoYXQgdGhlICJpZGVudGlmeWluZyBj aGFyYWN0ZXJpc3RpY3MiIG9mIGFuIGVuZHBvaW50ICh1c2luZw0KRFRMUykgYXJlIHN0aWxsIHRo ZSBJUCBhZGRyZXNzIGFuZCBwb3J0LCBoZW5jZSAicnVsZXMgYXJlIF9BRERFRF8gZm9yDQptYXRj aGluZyBhIHJlc3BvbnNlIHRvIGEgcmVxdWVzdCIuDQoNCk1heWJlIHRoZSBhdXRob3JzIG9mIHRo ZSBDb0FQIHNwZWMgY291bGQgcHJvdmlkZSBzb21lIGluc2lnaHQgd2hldGhlcg0KdGhpcyBpcyBp bmRlZWQgd2hhdCB0aGV5IHdhbnRlZCB0byBpbXBseSBvciB3aGV0aGVyIHRoZXkgc2ltcGx5IGZv cmdvdA0KdG8gYWRkIHNvbWUgbW9yZSBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlICJpZGVudGlm eWluZw0KY2hhcmFjdGVyaXN0aWNzIiBvZiBhbiBlbmRwb2ludCB3aGVuIHVzaW5nIG9uZSBvZiB0 aGUgbm9uLU5vU2VjDQpzZWN1cml0eSBtb2RlcyB3aXRoIERUTFMuDQoNCj4gVGhlIHN0b3J5IGZv ciBSRCBhcHBlYXJzIHRvIGJlIGRpZmZlcmVudCBhZ2Fpbi4gRmlyc3QsIHRoZXJlIGFwcGVhcnMN Cj4gdG/CoA0KPiBiZSBhIGRpZmZlcmVudCBkZWZpbml0aW9uIG9mIGVuZHBvaW50IGJlaW5nIHVz ZWQgKHdoaWNoIEkgcHJlZmVyDQo+IG1vcmUpLsKgDQo+IEZvciBtdWx0aXBsZXhpbmcgaXQgZG9l cyBub3QgdXNlIElQIGFkZHJlc3MgJiBwb3J0IGluZm9ybWF0aW9uLiBPZsKgDQo+IGNvdXJzZSwg UkQgd2lsbCBzdGlsbCBoYXZlIHRvIG1haW50YWluIHRoaXMgaW5mb3JtYXRpb24gYnV0IGF0IGxl YXN0DQo+IG9uZcKgDQo+IGNhbiBiZSBzdXJlIHRoYXQgcGFja2V0cyBhcmUgbm90IGRyb3BwZWQg YWZ0ZXIgdGhlIElQIGFkZHJlc3MgYW5kL29ywqANCj4gcG9ydCBhdCB0aGUgY2xpZW50IGNoYW5n ZS4NCj4gDQo+IFNlY3Rpb24gMTEuMSBvZiBkcmFmdC1pZXRmLWNvcmUtcmVzb3VyY2UtZGlyZWN0 b3J5LTA4IHNheXM6DQo+IA0KPiAiDQo+IMKgwqDCoMKgQW4gRW5kcG9pbnQgaXMgZGV0ZXJtaW5l ZCB0byBiZSB1bmlxdWUgYnkgYW4gUkQgYnkgdGhlIEVuZHBvaW50DQo+IMKgwqDCoMKgaWRlbnRp ZmllciBwYXJhbWV0ZXIgaW5jbHVkZWQgZHVyaW5nIFJlZ2lzdHJhdGlvbiwgYW5kIGFueQ0KPiBh c3NvY2lhdGVkDQo+IMKgwqDCoMKgVExTIG9yIERUTFMgc2VjdXJpdHkgYmluZGluZ3MuwqDCoEFu IEVuZHBvaW50IE1VU1QgTk9UIGJlDQo+IGlkZW50aWZpZWQgYnkNCj4gwqDCoMKgwqBpdHMgcHJv dG9jb2wsIHBvcnQgb3IgSVAgYWRkcmVzcyBhcyB0aGVzZSBtYXkgY2hhbmdlIG92ZXIgdGhlDQo+ IMKgwqDCoMKgbGlmZXRpbWUgb2YgYW4gRW5kcG9pbnQuDQo+ICINCj4gDQo+IEl0IGFwcGVhcnMg dGhhdCB0aGUgd2F5IGhvdyBzdGF0ZSBpcyBpbmRleGVkIGlzIGRpZmZlcmVudCB0aHJvdWdob3V0 DQo+IHRoZcKgDQo+IHNwZWNpZmljYXRpb25zIGRldmVsb3BlZCBpbiB0aGUgQ09SRSB3b3JraW5n IGdyb3VwIGFuZCBJIGFtIGN1cmlvdXPCoA0KPiB3aGV0aGVyIHNvbWVvbmUgZWxzZSBoYXMgYmVl biBsb29raW5nIGF0IHRoZSBpbXBsaWNhdGlvbnMgb2YgSVANCj4gYWRkcmVzc8KgDQo+IGFuZC9v ciBwb3J0IGNoYW5nZXMgb24gdGhlIHByb3RvY29sIG9wZXJhdGlvbi4gSSB3b3VsZCBjZXJ0YWlu bHnCoA0KPiBhcHByZWNpYXRlIHlvdXIgdGhvdWdodHMgb24gdGhpcyB0b3BpYy4NCj4gDQo+IENp YW8NCj4gSGFubmVzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ== From nobody Tue Sep 6 01:55: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 D35B812B17A for ; Tue, 6 Sep 2016 01:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfzvP66R_OoH for ; Tue, 6 Sep 2016 01:55:07 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC17F12B210 for ; Tue, 6 Sep 2016 01:55:06 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 79237E0D6B1D7; Tue, 6 Sep 2016 08:55:03 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u868t4Fh019355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 08:55:04 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u868t3ng000815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Sep 2016 10:55:04 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.184]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 6 Sep 2016 10:55:03 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "Hudalla Kai (INST/ESY1)" , "core@ietf.org" Thread-Topic: [core] Implications of IP address / port changes for CoAP & Co Thread-Index: AQHSA3OoxyHmUzEIzk+JkmWZMT8DoqBr9qaAgAAqYgA= Date: Tue, 6 Sep 2016 08:55:02 +0000 Message-ID: References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <1473146574.5588.23.camel@bosch-si.com> In-Reply-To: <1473146574.5588.23.camel@bosch-si.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <2480D49788C857489CBD3E06AF99734D@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co 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, 06 Sep 2016 08:55:12 -0000 Hi Kai, On 06/09/2016 08:23, "core on behalf of Hudalla Kai (INST/ESY1)" wrote: >>In any case, when DTLS is used an IP address / port change at the >> client=20 >> will prevent the CoAP server from finding the right security context >> and=20 >> a new (hopefully abbreviated) handshake has to be run. >>=20 >The client could indeed use an abbreviated handshake, i.e. resume the >DTLS session, if it were aware of the fact that its IP address or port >had changed during its last sleep cycle. However, for that the client >would probably need to use something like STUN first ... Yep. >The more interesting problem is how we deal with a changed IP >address/port on the CoAP server side, i.e. when a client has started to >observe a resource on the server and now expects notifications coming >in from that server. When the server's (the constrained device's) IP >address or port changes, it sends out notifications (CoAP responses) >with a different source endpoint than what the client expects. > >The CoAP specs states in section 9.1.2: > >"The following rules are added for matching a response to a request: >The DTLS session MUST be the same, and the epoch MUST be the same. > >This means the response to a DTLS secured request MUST always be DTLS >secured using the same security session and epoch. Any attempt to >supply a NoSec response to a DTLS request simply does not match the >request and therefore MUST be rejected (unless it does match an >unrelated NoSec request)." > >my understanding of this paragraph is that any notification received >from a server after its IP address or port has changed must be >discarded/rejected by the client. However, this is based on the >assumption that the "identifying characteristics" of an endpoint (using >DTLS) are still the IP address and port, hence "rules are _ADDED_ for >matching a response to a request". > >Maybe the authors of the CoAP spec could provide some insight whether >this is indeed what they wanted to imply or whether they simply forgot >to add some more information regarding the "identifying >characteristics" of an endpoint when using one of the non-NoSec >security modes with DTLS. The "Transport Agnostic SAs" proposal in the following draft might probably help: https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#section- 4 Cheers, t From nobody Tue Sep 6 02:28: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 6CD8512B2B9 for ; Tue, 6 Sep 2016 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=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 GHZoAsdKjk4C for ; Tue, 6 Sep 2016 02:28:27 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0007C12B2B3 for ; Tue, 6 Sep 2016 02:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dCxB7bbNPPBSOu+RmCz1wwvfP2zSVMOVAX+8QTTrum8=; b=h/4nKqWBXKZQCLpqdCAET2rfPtv6CyO/sESgUba2J4ThW7rVNq8XhwIhXh5FBMozPy04b5gRt9cfUxzn4Igi7S7LKZdRSBSI5rlaunNdt4tV7TBrxHHEG3fHiNC2EXeHrbyuOCJpcz9u2v1fQ28tbrI5rDv3hnupdahu1hcsOUI= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-29-iMRQA4qDOPGNxfRNIpb-BQ-1; Tue, 06 Sep 2016 10:28:22 +0100 Received: from VI1PR0802MB2383.eurprd08.prod.outlook.com (10.172.14.135) by VI1PR0802MB2383.eurprd08.prod.outlook.com (10.172.14.135) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Tue, 6 Sep 2016 09:28:21 +0000 Received: from VI1PR0802MB2383.eurprd08.prod.outlook.com ([10.172.14.135]) by VI1PR0802MB2383.eurprd08.prod.outlook.com ([10.172.14.135]) with mapi id 15.01.0587.019; Tue, 6 Sep 2016 09:28:21 +0000 From: Lauri Piikivi To: "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] Implications of IP address / port changes for CoAP & Co Thread-Index: AQHSA3Oa+qpxuGHVNUiouf4gU9RG7qBsGC2AgAAZoQCAAAlNAA== Date: Tue, 6 Sep 2016 09:28:21 +0000 Message-ID: References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <1473146574.5588.23.camel@bosch-si.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.140.96.140] x-ms-office365-filtering-correlation-id: 6d3880ef-ff3e-4976-9128-08d3d63824ce x-microsoft-exchange-diagnostics: 1; VI1PR0802MB2383; 20:RepK7X55UKEZTwoU0c8rmMaRD/b2/ekjPXC5qp3RbmPbD3QmU1MMHAtr0z44jnT5JjmC+ZVhvJIRmCI8ti6LwmAaJiRVSeSHWfwVMJRLTbh8AEIEdD7IpjX5AbmGHpr9kmKwV3bcZ8lHKvOP+Xlq+65FEQWIY1cWqbzKt+lMn0I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0802MB2383; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(278428928389397)(192374486261705)(82608151540597)(155532106045638); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:VI1PR0802MB2383; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0802MB2383; x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(40434004)(189002)(53754006)(24454002)(77096005)(36756003)(10400500002)(68736007)(7736002)(7846002)(561944003)(97736004)(105586002)(2950100001)(106116001)(3280700002)(92566002)(122556002)(81166006)(81156014)(8676002)(86362001)(189998001)(2900100001)(3846002)(586003)(6116002)(8936002)(19580405001)(110136002)(54356999)(76176999)(50986999)(3660700001)(4326007)(5002640100001)(106356001)(82746002)(101416001)(102836003)(87936001)(11100500001)(33656002)(66066001)(19580395003)(5660300001)(305945005)(15975445007)(2906002)(5890100001)(83716003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0802MB2383; H:VI1PR0802MB2383.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <25175BBD8B27C747ACB01EC5A57377CF@eurprd08.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2016 09:28:21.2361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2383 X-MC-Unique: iMRQA4qDOPGNxfRNIpb-BQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Implications of IP address / port changes for CoAP & Co 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, 06 Sep 2016 09:28:29 -0000 Hi alls, When the IP / port changes, the DTLS will fail as it can not map the receiv= ed message to a session. DTLS says (https://tools.ietf.org/html/rfc6347#pag= e-8) "Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with the host/port number.=94 I assume that a DTLS alert is sent back. Often the load balancers will already fail similarly, they direct the messa= ge to wrong server in the server pool based on the ip / port. BR, - Lauri > On 06 Sep 2016, at 11:55, Fossati, Thomas (Nokia - GB) wrote: > > Hi Kai, > > On 06/09/2016 08:23, "core on behalf of Hudalla Kai (INST/ESY1)" > wrote: >>> In any case, when DTLS is used an IP address / port change at the >>> client >>> will prevent the CoAP server from finding the right security context >>> and >>> a new (hopefully abbreviated) handshake has to be run. >>> >> The client could indeed use an abbreviated handshake, i.e. resume the >> DTLS session, if it were aware of the fact that its IP address or port >> had changed during its last sleep cycle. However, for that the client >> would probably need to use something like STUN first ... > > Yep. > >> The more interesting problem is how we deal with a changed IP >> address/port on the CoAP server side, i.e. when a client has started to >> observe a resource on the server and now expects notifications coming >> in from that server. When the server's (the constrained device's) IP >> address or port changes, it sends out notifications (CoAP responses) >> with a different source endpoint than what the client expects. >> >> The CoAP specs states in section 9.1.2: >> >> "The following rules are added for matching a response to a request: >> The DTLS session MUST be the same, and the epoch MUST be the same. >> >> This means the response to a DTLS secured request MUST always be DTLS >> secured using the same security session and epoch. Any attempt to >> supply a NoSec response to a DTLS request simply does not match the >> request and therefore MUST be rejected (unless it does match an >> unrelated NoSec request)." >> >> my understanding of this paragraph is that any notification received >> from a server after its IP address or port has changed must be >> discarded/rejected by the client. However, this is based on the >> assumption that the "identifying characteristics" of an endpoint (using >> DTLS) are still the IP address and port, hence "rules are _ADDED_ for >> matching a response to a request". >> >> Maybe the authors of the CoAP spec could provide some insight whether >> this is indeed what they wanted to imply or whether they simply forgot >> to add some more information regarding the "identifying >> characteristics" of an endpoint when using one of the non-NoSec >> security modes with DTLS. > > The "Transport Agnostic SAs" proposal in the following draft might > probably help: > > https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#sectio= n- > 4 > > Cheers, t > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > 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. From nobody Tue Sep 6 11:30:18 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 B354D12B276 for ; Tue, 6 Sep 2016 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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 hDBwYeGngVAz for ; Tue, 6 Sep 2016 11:30:14 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0135.outbound.protection.outlook.com [104.47.40.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B513712B26C for ; Tue, 6 Sep 2016 11:30:14 -0700 (PDT) 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=NKiDUaJVJqeYZlz0KcMOenIGFkHejBxOPvZZWlMw2xk=; b=FfHGF4ogqTARoJqfjxS7AOOJm8IZKLUNqDwbVn3pjI7Aji+iocag9+XD08sAzdacnLKE2GS6VqwkBEosJ/DBdJGIEaYd00RMQzuvyezvfzr9pmGPFq4bMNk9QTz+X3jtqepE3F0FuApX3a0CUdnRsM6Rox+iTHwVRMpDkWCK+dg= Received: from DM2PR0301MB0670.namprd03.prod.outlook.com (10.160.96.20) by DM2PR0301MB0671.namprd03.prod.outlook.com (10.160.96.21) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Tue, 6 Sep 2016 18:30:13 +0000 Received: from DM2PR0301MB0670.namprd03.prod.outlook.com ([10.160.96.20]) by DM2PR0301MB0670.namprd03.prod.outlook.com ([10.160.96.20]) with mapi id 15.01.0609.013; Tue, 6 Sep 2016 18:30:13 +0000 From: Brian Raymor To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt Thread-Index: AQHR/kux0vvo8uYlLUa/o5fnHPLus6BYnTxwgBQ95TA= Date: Tue, 6 Sep 2016 18:30:13 +0000 Message-ID: References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.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=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 8f302bb1-750e-4816-4308-08d3d683d789 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0671; 6:x/KyHgP+LcPZbwYETDrx4UjXzi1K2vYUFK7QT+PTJ5iFpuv+zu65VbXzXH9Fmj2Jtr0SD4bPGzeQXWzQhJUashRvWH0jBdYKXK+g8cOaiWyVF/nQFHJ6NtcXjPqmW/zq9C30LL/o7WESD6pKmGQVVC/a13DH6zWrbdw/mG5ByLzbBh20qdwQOqHokKK6Iu1Riy3w68PHm3FdpBlIaDX6i2VizD5NG2Qn4wTncAe8zLNmpTH3kNFPEm2kvLW6gIAFg9olP37pRndWoA9TRVElwjzrdxRziVD2N2x7Ifdm5rz9ECJ0Lg/EtgoHhOLphYJYcpOijX6j2Z8Q47VAT222HA==; 5:RLqU0YEqosUXZsWQD6UnuHsv7L9HDqUpbjIk8tYDF2B7ZnNGRDFYT2sHVys+nxt9eEjLqssGLucuMjougBZHOJZaD5siMhugNBPeR6vXCRd2P5DLNSaIZqluf21yx/run4aJCL/p70wmUq9w/HPX+Q==; 24:503UCacPCFJQ5cEVKLMSdJIXKheQKI87vLyc7/saskOweHixvgeybN/XHRPehPC1CvozE+sry0qgseRwHhWQojqHBHL3T0JH7jnSumdaBZs=; 7:/AkLwU82jEBUq37EzmbS2sLClI/gWi+7RX7/r3KOlJ8QVCKRuUCtjhDPtYBgFNPOuEc5A7ed5B5tYErOoDfAXcR5xN8fe3k57Xcj5lvjH9/gjlFFXxMH8gZaYmLuFSeT+VUTCcxxLCyzupBGbswLg9knpFPoUUEki24gRyc7IkVdhohlPEDjMSjVJHekc9o9YGERWGiPQa5oUYB9PDH2p0zHFpSYSb9OEfymr39oxwIyDn01csPE1yCM2CVexqfQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0671; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0671; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0671; x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(52024003)(13464003)(31014005)(377454003)(199003)(189002)(10090500001)(3280700002)(106116001)(9686002)(5640700001)(106356001)(15975445007)(2501003)(7696003)(305945005)(77096005)(3660700001)(81156014)(2906002)(5002640100001)(8676002)(7736002)(105586002)(74316002)(450100001)(7846002)(87936001)(11100500001)(81166006)(230783001)(99286002)(1730700003)(76576001)(86612001)(189998001)(19580405001)(10400500002)(10290500002)(68736007)(92566002)(5660300001)(8936002)(86362001)(5005710100001)(8990500004)(101416001)(110136002)(122556002)(586003)(50986999)(2900100001)(3846002)(102836003)(2950100001)(97736004)(19580395003)(33656002)(76176999)(66066001)(6116002)(2351001)(54356999)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0671; H:DM2PR0301MB0670.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2016 18:30:13.1436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0671 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 18:30:17 -0000 Refreshing this request for people returning from summer vacations ... I'd = appreciate feedback on whether a CoAP+TCP client may immediately send messa= ges after sending its CSM without waiting for the server CSM ...- https://g= ithub.com/core-wg/coap-tcp-tls/issues/58. I plan to publish -05 during the week of 9/12 which will address this set o= f issues - https://github.com/core-wg/coap-tcp-tls/milestone/3 Thanks, ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Wednesday, August 24, 2016 2:22 PM To: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt -04 addresses all the issues discussed at IETF 96 - with the exception of h= ttps://github.com/core-wg/coap-tcp-tls/issues/5. The authors are discussing= the scope for a section related to RFC7641 (Observing resources ...). In addition, I opened a new issue related to mandatory exchange of CSM - ht= tps://github.com/core-wg/coap-tcp-tls/issues/58 - where feedback would be h= elpful. Both of these issues are targeted for -05. ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Wednesday, August 24, 2016 2:09 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments of the IE= TF. Title : CoAP (Constrained Application Protocol) over TCP,= TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-04.txt Pages : 42 Date : 2016-08-24 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-tcp-tls-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Sep 8 02:21: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 8B80E12B312 for ; Thu, 8 Sep 2016 02:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JtuxE5jnZvyz for ; Thu, 8 Sep 2016 02:21:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E35112B14D for ; Thu, 8 Sep 2016 02:21:25 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-6a-57d12d925401 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id CB.5B.04209.29D21D75; Thu, 8 Sep 2016 11:21:23 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 8 Sep 2016 11:21:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ng3aR6MitOFDrwFiV5j5QocNtxrcNP5NL6JGt+ZSzp4=; b=ZFJE2tguT6BPQ1froOpBumLIyvXlQ97/7ZxQ3MPtBGZfkBIql9a3kiYdK6XbCvCucFWijHtMff27u8ntDgQ3IzX3LBwHw2G3bt1GTAdIcp9UCY7E9HRN9XtiOKjFUV7ITmNAOOHOreKSqEUD+9W/FbDVoa3Dq3UT2SX4U5hu5OE= Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Thu, 8 Sep 2016 09:21: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.0609.016; Thu, 8 Sep 2016 09:21:21 +0000 From: Francesca Palombini To: Jim Schaad , "draft-selander-ace-object-security@tools.ietf.org" Thread-Topic: Comments on draft-selander-ace-objet-security-05 Thread-Index: AdICNHSaZv2pAHPTRji2hykYHnUiIwHe+opg Date: Thu, 8 Sep 2016 09:21:20 +0000 Message-ID: References: <048901d20321$c8c5dc60$5a519520$@augustcellars.com> In-Reply-To: <048901d20321$c8c5dc60$5a519520$@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.176.1.81] x-ms-office365-filtering-correlation-id: 7e5e5b4f-55be-4024-dc69-08d3d7c97f18 x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2539; 6:+A0ttgiIoHIa//6k/NG9aKwBIteiB08ZfgJ5SvoiLDTNu+MI0C3kJ3nucS6pfUJ2XRw/iePUdvcXtO8r8cQtDmWxWMulII9hKVrdHMMd2V7O1mtgNxX2RiFk946JwXc6LmPjd/YV7tt3TGB9g/796teCwavYYk4Epmibk68JONrlf3GiTFiJOwjL3cQqeimaZSj2aPVy3bDkkyCdYiT7ZqeMxcsZdq06ReyHJEAKjSxMv5RizsMA/XOly0oWYA8+pYo1qO+1WdD0NSn0Buy3H1RT6Yb21Hy8ulZQUTwJWtM=; 5:O5wlAK/K2/UmNsh7POGMiny/bw6jzGrQCt3ULYzXmwWcCWfGEooooASWVDw5v25ohNZZ+Q2gYbRZUdi0mGhlIktvIzYM7Wut/78rbqYJ+mpfLKcUSlkBhiMXUHdgd5Jd7ab/6Zy8r5dK3hrQnbv+eQ==; 24:/4n1YuWXPS4zSeiVL0u4gPP4ycj0BEXiac5HjIg0NO7SBCMgMXXZA257DMn0FWJwlS1f+57q2XJgQyJQsVCtc8wNzigJ+2WdasJde8q25bA=; 7:frge20RAeShwl469bJ6bB77+2P14JHu8y0v2LujqZfZGOdkC4/t0bX091Beq11Mk42jE+D3ZK10lHnyOS7GjRu/kfaFdXhpQrTRFrTkOXaPfUK7MdJ4PQBAXgLvpXUP7Be8LfYlscn259mzTrQiLp1bsusiLl9EuY4KLw9IxZAjCfTpw9E9xDiOIrbHCbX3sMzwFDOWgxrhvF6lXOpO8VbQxGEAzZEvf2bECyPCovrcYc+kliZSYrpLsHyYSdl5W x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2539; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(35073007944872); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR0701MB2539; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2539; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(199003)(189002)(43784003)(101416001)(2950100001)(106356001)(76576001)(189998001)(19580405001)(105586002)(76176999)(54356999)(6116002)(102836003)(33656002)(97736004)(15650500001)(50986999)(68736007)(66066001)(92566002)(2906002)(81156014)(87936001)(8676002)(86362001)(11100500001)(3846002)(586003)(345774005)(122556002)(9686002)(81166006)(4326007)(8936002)(77096005)(5660300001)(3660700001)(74316002)(10400500002)(19580395003)(7736002)(230783001)(2501003)(15975445007)(7696003)(2900100001)(3280700002)(5002640100001)(7846002)(5001770100001)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2539; 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: 08 Sep 2016 09:21:20.7313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2539 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUyM2J7oO5k3YvhBu0PNCz2vV3PbHHg/HUW i9XTv7M5MHtsnDOdzWPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyvj17j5jwSeHirdP/zA1 MK437mLk5JAQMJFY8GELWxcjF4eQwHpGibMHm9ghnOOMEpPfvGYEcVgEepklvp+ZxgrSIiQw lUlixk8+iKqTjBL3fk0CS7AJ2EhcePieFSQhIjCFUaL1xFQ2kASzgLLE8dmHwYqEBWwlGt+f ZwexRQTsJJo3dzJB2EYS+1bvB6thEVCRWLNwK1gNr0CCRPPi6yxdjBxA2+wl3s/mAwlzCjhI vJv7Fmw8o4CsxJfG1cwQq8Qlbj2ZzwTxm4DEkj3nmSFsUYmXj/+xQtQnS1y53ccOEVeQODZj JQuE7Sux+WIzC8j9EgIf2CR+3ngBVeQhsWb/LUYIO19i5p4fUENzJXqnPmKEaNjDKLHiewPU JBmJjte32CASDWwSc0/0MkHCLlVi+dpWRkhISEncvdLJOIFRaxaSyyFsHYkFuz+xQdjaEssW vmaeBQ4MQYmTM5+wLGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRmE4ObvmtuoPx8hvH Q4wCHIxKPLwJshfChVgTy4orcw8xSnAwK4nwlutcDBfiTUmsrEotyo8vKs1JLT7EKM3BoiTO 6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXA2LZ7Afce94KKiheZa87263T0vbjgt3ZlT+jeT719 vP2TO069rlt7Iz3Q3z/vz/KVq9dxPX/ZHp21fOPl7t8PfmrcDFrOqRN3c/5WSfm6IM/q85+f hpRvi3ZYeKD8xPGbUid9BdYnqRUr7LZ0Y3NMn7bnRcabRzejFe9tdp3b7WT8Q2+thdBWeSWW 4oxEQy3mouJEAP73iTwjAwAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Comments on draft-selander-ace-objet-security-05 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, 08 Sep 2016 09:21:28 -0000 Hi Jim, Thank you for reading our draft again, we have created issues in the github= repository from many of them, and we'll deal with them soon. If you are interested you can follow and comment here: https://github.com/E= ricssonResearch/OSCOAP/issues=20 For the rest, I'd like to ask for explanations (inline). Thanks again! Francesca -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: den 31 augusti 2016 02:51 To: draft-selander-ace-cose-ecdhe@tools.ietf.org Cc: core@ietf.org Subject: Comments on draft-selander-ace-objet-security-05 Random Thoughts: Introduction: Given the scope of the analysis, I do not believe that you c= an restrict your solution to just dealing with the forwarding case. Specifically I think you need to deal with the pub/sub cases with or w/o an= agent. [FP] the pub/sub case should be dealt with by OSCON (Object Security of Con= tent - Appendix C), in which only the payload of the message would be prote= cted, not the entire request-response exchange. We really meant OSCOAP as a= challenge-response protocol (mentioned first in the abstract "OSCOAP provi= des (...) a secure binding between CoAP request and response messages"). Ot= her scenarios (such as multicast with unicast response) can be used with OS= COAP, with some adjustments (this is a work to come soon). Introduction: Is the determination of content being present based on the l= ength of the content or on the message type? For example think of a POST o= r a response with a zero length body. I would tend to create a COSE body i= n these cases rather than use the option for the body. [FP] Yes, in the case of a zero-length body, the COSE object should go in t= he CoAP payload of the protected message. Thank you for pointing that out, = we'll clarify this. Section 2 - I am not sure that the SHOULD NOT on caching makes complete sen= se. It would make sense to cache the response if correlated to the original request for reliability. Caching also makes sense in the pub-sub world [FP] I am not sure I understand this comment. What do you mean by "for reli= ability"? If you talk about message re-transmission, that's on CoAP message= layer or a lower layer than CoAP neither of which are in scope of OSCOAP. Section 2 - how does setting Max-Age interact with pub-sub and w/ caching f= or reliable transmission? [FP] again, what do you mean by reliable transmission? Section 2 - the last sentence seems to be odd - are you really given an exa= mple of option length or how different option lengths are encoded? [FP] You are right, we don't give an example, it would more exact to say th= at we detail the message overhead caused by the Object Security option. Section 3 - s/common keying material/common shared secret material/ [FP] OK Section 3 - s/of forward secret keying material/of secret material with the= property of forward secrecy/ [FP] OK Section 3.1 - You need to add a field for who is being talked to on the cli= ent side of the context. There is nothing to say that Cids are unique for = the client and therefore it needs to be able to determine which to use when= sending a message to the other side. This may also be required for server= s when doing unicast in the event that it will spontaneously send messages. [FP] We are adding a field Sender ID and a field Recipient ID that should s= olve this problem. These fields shall be unique, either globally (stochasti= cally) unique, or locally unique in case of globally (stochastically) uniqu= e Cid:s, and set up in a previous phase (for example while doing EDHOC).=20 Section 3.1 - The idea of flip-flopping the context when the client and ser= ver change roles seems to be a very bad idea. If the client sends message = and the server never receives it. Then they flip contexts and the= old server sends because it swapped server and recipient, then yo= u have a security leak problem. Once the contexts are established they sho= uld never be swapped. I think this is what the last paragraph in this sect= ion is suggesting. [FP] I think this paragraph may not have been clear. We meant that the cont= ext stayed the same even though the client became the server and the server= became the client. Each endpoint uses the same keying material and procedu= re for setting IV and protecting from replay as it did before, when sending= and receiving. So we agree with you, flip-flopping the context is a bad id= ea and we were trying to say that it must not be done, and also that there = is no need to re-negotiate new material. We'll try to clarify. Section 3.2 - there should be a big warning at the top of this section that= this procedure is only run once on a set of common secret material. Runni= ng it a second time is going to lead to bad things unless there is somethin= g added. [FP] You are right. Section 3.2 - I would prefer to add some additional items to the info struc= ture to make sure that things are going to agree on both sides. These woul= d include the algorithm and the lengths of the item being derived. Look at= the prefix derivation problems that can exist otherwise. [FP] OK, we'll add algorithm and length to the info structure. Section 3.2 - I have a problem with the text " The Context Identifier SHALL= be unique for all security contexts used by the party being server." As I = am not sure how to test this. A statement that a server will check and rej= ect is testable. I do not think that one can assume that a TTP will be abl= e to ensure this as there may be more than one of them and they may assign = the same type of uniqueness indicator (i.e. the addresses of both parties). Please do not assume there is only one authorization server. [FP] We understand, but we think this is something that an application usin= g OSCOAP should decide how to achieve. Section 3.2 - There is a fun thing that needs to be thought about. A clien= t which sends a token along with the request may try and register the same = Cid more than once because the response to its request may get lost. This = needs to be documented potentially as saying that the same Cid must result = in the same context being generated. [FP] I don't understand what you mean by "register the Cid", and what token= are you talking about here. Could you expand? Section 4 - When doing encryption only, I would remove the I column from fi= gure 4. I would just note that "E includes I" but "I" by itself would be a= different proposition. That is 'I' would be ONLY integrity protected or i= ntegrity protected in a signed or MAC only message. [FP] Yes, we'll remove the I column. Section 4 - The second paragraph below table 4 should not be dealing with d= uplication not integrity protection. That is the items it needs to talk a= bout are 1) encryption or not and 2) duplicate or not and if it is duplicat= ed are they evaluated separately or must the contents be the same - with th= e addition of new security services then it would also make sense to talk a= bout 3) integrity protect or not. [FP] Assuming you meant to write "should be dealing with duplication not in= tegrity protection", I agree. We'll change that. Section 5 - I would suggest making the mandatory algorithm declarations in = a single location so that it is easy to find rather than having it in multi= ple locations. [FP] OK Section 5 - Your maximum sequence number is going to be much smaller than 2= ^56-1. You need to factor in the reduced sized tag and the limits for GCM = into this size. I will need to do some research to figure out what the cor= rect limit is. It is going to be closer to 2^32 w/o adjusting for the abbr= eviated tag. [FP] Please elaborate on this. And you do mean CCM, right? Section 6.1 - OSCOAP should not be a challenge response protocol so this pa= ragraph is troubling. It needs to be able to support more than just this o= ne situation. [FP] Is this the same comment as before regarding e.g. pub-sub? I am going to play with some other details so I will probably have more com= ments following this. Jim From nobody Thu Sep 8 02:24:44 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 C38F612B3EB; Thu, 8 Sep 2016 02:24:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147332668279.30880.6734631148695323740.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2016 02:24:42 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-14.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: Thu, 08 Sep 2016 09:24:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Guidelines for HTTP-to-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-14.txt Pages : 36 Date : 2016-09-08 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 8 14:20:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00BD12B26C for ; Thu, 8 Sep 2016 14:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 iEeRGxcYhVPP for ; Thu, 8 Sep 2016 14:19:54 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB0712B26B for ; Thu, 8 Sep 2016 14:19:51 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Sep 2016 14:33:00 -0700 From: Jim Schaad To: 'Francesca Palombini' , References: <048901d20321$c8c5dc60$5a519520$@augustcellars.com> In-Reply-To: Date: Thu, 8 Sep 2016 14:19:31 -0700 Message-ID: <100401d20a16$b2aa7700$17ff6500$@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: AQEYBgepkxqrjAKtR4bKiNAbptCUIQLtGJFoocytyGA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: core@ietf.org Subject: Re: [core] Comments on draft-selander-ace-objet-security-05 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, 08 Sep 2016 21:19:56 -0000 > -----Original Message----- > From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] > Sent: Thursday, September 08, 2016 2:21 AM > To: Jim Schaad ; draft-selander-ace-object- > security@tools.ietf.org > Cc: core@ietf.org > Subject: RE: Comments on draft-selander-ace-objet-security-05 > > Hi Jim, > > Thank you for reading our draft again, we have created issues in the github > repository from many of them, and we'll deal with them soon. > If you are interested you can follow and comment here: > https://github.com/EricssonResearch/OSCOAP/issues > For the rest, I'd like to ask for explanations (inline). > > Thanks again! > Francesca > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: den 31 augusti 2016 02:51 > To: draft-selander-ace-cose-ecdhe@tools.ietf.org > Cc: core@ietf.org > Subject: Comments on draft-selander-ace-objet-security-05 > > Random Thoughts: > > Introduction: Given the scope of the analysis, I do not believe that you can > restrict your solution to just dealing with the forwarding case. > Specifically I think you need to deal with the pub/sub cases with or w/o an > agent. > > [FP] the pub/sub case should be dealt with by OSCON (Object Security of > Content - Appendix C), in which only the payload of the message would be > protected, not the entire request-response exchange. We really meant OSCOAP > as a challenge-response protocol (mentioned first in the abstract "OSCOAP > provides (...) a secure binding between CoAP request and response messages"). > Other scenarios (such as multicast with unicast response) can be used with > OSCOAP, with some adjustments (this is a work to come soon). This may be an issue with how the document is arranged then. I don't know that it makes sense to have OSCON be in an appendix if it is expected to be used in such a major situation as pub/sub. Being in an appendix makes it be low priority in my mind as being not too useful. > Section 2 - I am not sure that the SHOULD NOT on caching makes complete > sense. It would make sense to cache the response if correlated to the > original request for reliability. Caching also makes sense in the pub-sub > world > > [FP] I am not sure I understand this comment. What do you mean by "for > reliability"? If you talk about message re-transmission, that's on CoAP message > layer or a lower layer than CoAP neither of which are in scope of OSCOAP. Caching is part of what allows for re-transmission and reliable sending in my mind. I realize that this may not be a general feeling, however if a response is cached then the re-transmission can be short circuited at the cache rather than needing to go all the way back to the responder and thus having the same problems with getting the response all the way back because of collisions and time outs. When I say reliable transmission I am talking about it in the same sense as does RFC 7252 which is the CoAP specification. > > Section 2 - how does setting Max-Age interact with pub-sub and w/ caching for > reliable transmission? > > [FP] again, what do you mean by reliable transmission? > > Section 3.1 - You need to add a field for who is being talked to on the client side > of the context. There is nothing to say that Cids are unique for the client and > therefore it needs to be able to determine which to use when sending a message > to the other side. This may also be required for servers when doing unicast in > the event that it will spontaneously send messages. > > [FP] We are adding a field Sender ID and a field Recipient ID that should solve > this problem. These fields shall be unique, either globally (stochastically) unique, > or locally unique in case of globally (stochastically) unique Cid:s, and set up in a > previous phase (for example while doing EDHOC). You may still want to have an identity in the table ala a DNS name so that you can look up by that as well. You will need this type of information to do the initial lookup to say "I want to send to foo, what key material do I use?" I am sorry, I don't believe in your globally/locally unique Cid values. Feel free to ignore me on this. > Section 3.2 - I have a problem with the text " The Context Identifier SHALL be > unique for all security contexts used by the party being server." As I am not sure > how to test this. A statement that a server will check and reject is testable. I do > not think that one can assume that a TTP will be able to ensure this as there may > be more than one of them and they may assign the same type of uniqueness > indicator (i.e. the addresses of both parties). > Please do not assume there is only one authorization server. > > [FP] We understand, but we think this is something that an application using > OSCOAP should decide how to achieve. Then it is not clear that SHALL is the correct word. > > Section 3.2 - There is a fun thing that needs to be thought about. A client which > sends a token along with the request may try and register the same Cid more > than once because the response to its request may get lost. This needs to be > documented potentially as saying that the same Cid must result in the same > context being generated. > > [FP] I don't understand what you mean by "register the Cid", and what token are > you talking about here. Could you expand? By register the Cid, I mean put it into the key table that I am maintaining. Client Server Send request --> receive and process ||blocked <-- send response || or lost Resend same request ---> receive and process -- what do I do about the duplicate Cid??? Error or return the same response > Section 4 - The second paragraph below table 4 should not be dealing with > duplication not integrity protection. That is the items it needs to talk about are > 1) encryption or not and 2) duplicate or not and if it is duplicated are they > evaluated separately or must the contents be the same - with the addition of > new security services then it would also make sense to talk about 3) integrity > protect or not. > > [FP] Assuming you meant to write "should be dealing with duplication not > integrity protection", I agree. We'll change that. Yes, that is what I meant. > Section 5 - Your maximum sequence number is going to be much smaller than > 2^56-1. You need to factor in the reduced sized tag and the limits for GCM into > this size. I will need to do some research to figure out what the correct limit is. > It is going to be closer to 2^32 w/o adjusting for the abbreviated tag. > > [FP] Please elaborate on this. And you do mean CCM, right? No, I actually meant GCM not CCM in this case because I have an idea of what the limit is due to the long discussions on the TLS mailing list. I really have no idea at this time what the limit would be for CCM. I need to re-read the documents and make some guesses. Jim > I am going to play with some other details so I will probably have more > comments following this. > > Jim > > > > > > > > From nobody Mon Sep 12 15:53: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 89EF012B15A for ; Mon, 12 Sep 2016 15:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 KKn07zvsOK-H for ; Mon, 12 Sep 2016 15:53:31 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0135.outbound.protection.outlook.com [104.47.41.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D5512B109 for ; Mon, 12 Sep 2016 15:53:30 -0700 (PDT) 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=UzXE5Tqo1XgnKeb0XNnfvtRywq51v2IwO0QClc9FdXI=; b=D3TeEZxt6Yp4Pv8G21SnIsaIiJTNgGRbmmaAlWWQ8n63SjGZIOvz6nfUBlEvBIVEbIQqaTS+hvDUc9LYju1nrN/ZZwqOi9oD0ohfcHkphB0yaR/3VhK0PoDnyCFZ1RJCTmM3FT7TQTVP3alhqvZ4Qv4aT0gbwH4P3+sG06eg66g= Received: from CY1PR03MB2265.namprd03.prod.outlook.com (10.166.207.17) by CY1PR03MB2268.namprd03.prod.outlook.com (10.166.207.20) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Mon, 12 Sep 2016 22:53:29 +0000 Received: from CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) by CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) with mapi id 15.01.0619.011; Mon, 12 Sep 2016 22:53:29 +0000 From: Dave Thaler To: "core@ietf.org" Thread-Topic: New Version Notification for draft-thaler-core-redirect-00.txt Thread-Index: AQHSDUfaLE9COg7xkEiN3H6UVqvj36B2dT/A Date: Mon, 12 Sep 2016 22:53:29 +0000 Message-ID: References: <147372053832.3711.14886788365598645137.idtracker@ietfa.amsl.com> In-Reply-To: <147372053832.3711.14886788365598645137.idtracker@ietfa.amsl.com> 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=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:4::76a] x-ms-office365-filtering-correlation-id: 96c886b2-cbcc-4f74-1ce2-08d3db5f9d48 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2268; 6:nY7mRT2WrnSjmCtMZnVi2y7A7Kw+mKxy6sGdFiONoMWbMXGuwbvgzJWTBYP7AmV+QxPd1o6P3nZUGAaUhIz0yzwDuo5YgPV7LSoL1HShc4ldoIIip7OZpbcpzxa98DKXc7lb2GTPSpujWawX6zgDAdPNwJsnkQ9EXOASkOF1oDEn01u0k3rPLCpb7CyJLIoba1SCUKLGbYfFPcvWM33FAmutgI+0ZXMbq3DpljB0Y1HfTpu8PxPauyA/3aErP1Xccmcdabjc/ljm1cNESNqGXvCtCwbkimzJJSNhO9al76ZUI1t5dBEG89id8q3pZfawu2cWp9ODC5xJhAuMpccvow==; 5:OMJvcJ6RqdBVRR1/tnMhKzQJ2K2i1UinvYqhVXuBM7n/9vjTTjqZtlz6E1iaTno4qFowrhvvO1X81jFq6PDEnVOEsAaFxuY+0LgsG6FtgEG+oJi5cfple4Xp8c3urjrRSjOMM0xDm/L+8I8MsgbVzw==; 24:Uc5Kghie3f6fXl6qOtL68Kz61LFHNQdZ0C2bwf1fPWeGN7Y4oI4gNOVZQJhsAP1dIenJBTP5PeeSiJlmLwaZkZEJOtFfawmrXgSsnsVA1gE=; 7:k5Z2KP19pqfMLEm3PUrmDqVg6r76h200mfOibPeLslbFqzX7+pPfQXUqpG83nfrieDOuj4V/YD9wg8sTFdalpANA3jfmNhkynxVX7xNNnZ4XCmM7T6Us/4nFs/6Di526sIOmWIGfj/mOrk6DMZkzxAsLP9glDzw2L+yP3IQLABxIiIFqgyWKpzyDf6zONDrxFP8UOkPFAv0nygOID0rzLN3SbpVtCjBwZIKKAt2srg9utSvfyuwj6uOn+nN3L2z3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2268; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2268; x-forefront-prvs: 006339698F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(377424004)(377454003)(2950100001)(2900100001)(5640700001)(107886002)(305945005)(86612001)(86362001)(81166006)(81156014)(92566002)(97736004)(7846002)(7736002)(3280700002)(76576001)(15975445007)(1730700003)(8676002)(77096005)(10090500001)(54356999)(76176999)(33656002)(110136003)(99286002)(2906002)(50986999)(8990500004)(586003)(2351001)(105586002)(74316002)(3660700001)(68736007)(450100001)(106356001)(102836003)(6116002)(122556002)(106116001)(5005710100001)(230783001)(87936001)(2501003)(9686002)(5660300001)(10400500002)(19580405001)(10290500002)(7696004)(15650500001)(101416001)(5002640100001)(19580395003)(11100500001)(8936002)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2268; H:CY1PR03MB2265.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2016 22:53:29.4295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2268 Archived-At: Subject: [core] FW: New Version Notification for draft-thaler-core-redirect-00.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, 12 Sep 2016 22:53:33 -0000 Q09BUCBSZWRpcmVjdHMgaGF2ZSBiZWVuIHJlcXVlc3RlZCBieSB0aGUgT3BlbiBDb25uZWN0aXZp dHkgRm91bmRhdGlvbiAoT0NGKSwgaW4gd2hpY2gNCmEgY291cGxlIG9mIElFVEYnZXJzIChteXNl bGYsIE1pY2hhZWwsIERhcnNoYWssIGV0Yy4pIHBhcnRpY2lwYXRlLiAgQXMgb25lIG9mIHRoZSBJ RVRGIGZvbGtzIGluIHRoZQ0KZGlzY3Vzc2lvbiwgSSB0b29rIHRoZSBhY3Rpb24gaXRlbSB0byB3 cml0ZSB0aGUgSS1EIHRvIHN1Ym1pdCB0byB0aGUgQ29SRSBXRywgc2luY2UgaXQncyBub3QNCnJl YWxseSBPQ0Ytc3BlY2lmaWMuICAgTWljaGFlbCBhbmQgRGFyc2hhayBhcmUgd2VsY29tZSB0byBi YWNrIG1lIHVwIGhlcmUgOikNCg0KU2VlIHRoZSBJLUQgZm9yIHRoZSB1c2UgY2FzZSwgYWx0ZXJu YXRpdmVzIGNvbnNpZGVyZWQsIGFuZCBwcm9wb3NlZCBzb2x1dGlvbi4NCg0KRGF2ZQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVy IDEyLCAyMDE2IDM6NDkgUE0NClRvOiBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29t Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aGFsZXItY29y ZS1yZWRpcmVjdC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGhhbGVy LWNvcmUtcmVkaXJlY3QtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg RGF2ZSBUaGFsZXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtdGhhbGVyLWNvcmUtcmVkaXJlY3QNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlDT0FQIFJl ZGlyZWN0cw0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wOS0xMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJOA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aGFsZXItY29yZS1yZWRpcmVjdC0wMC50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aGFsZXIt Y29yZS1yZWRpcmVjdC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtdGhhbGVyLWNvcmUtcmVkaXJlY3QtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg ZG9jdW1lbnQgYWxsb3dzIGEgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVAp IHNlcnZlcg0KICAgdG8gcmVkaXJlY3QgYSBjbGllbnQgdG8gYSBuZXcgVVJJLiAgVGhlIHByaW1h cnkgdXNlIGNhc2UgaXMgdG8gYWxsb3cNCiAgIGEgY2xpZW50IHVzaW5nIG11bHRpY2FzdCBDb0FQ IGRpc2NvdmVyeSB0byBsZWFybiBhIENPQVBTIGVuZHBvaW50IG9mDQogICB0aGUgc2VydmVyLCB3 aXRob3V0IHRoZSBzZXJ2ZXIgcmV2ZWFsaW5nIHByaXZhY3ktc2Vuc2l0aXZlDQogICBpbmZvcm1h dGlvbi4gIFRoaXMgaW1wcm92ZXMgc2VjdXJpdHkgYW5kIHByaXZhY3kgaW4gZW52aXJvbm1lbnRz IHdpdGgNCiAgIHVudHJ1c3RlZCBjbGllbnRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From nobody Mon Sep 12 21:47: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 694C512B1D2 for ; Mon, 12 Sep 2016 21:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk9PDZdW_ceJ for ; Mon, 12 Sep 2016 21:47:38 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25512B1D1 for ; Mon, 12 Sep 2016 21:47:36 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id EC35519F414 for ; Tue, 13 Sep 2016 12:47:34 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.57]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9239019F409; Tue, 13 Sep 2016 12:47:34 +0800 (HKT) Message-ID: <114995FB6D604B92854BDA82FEC26123@WeiGengyuPC> From: "weigengyu" To: "Brian Raymor" , References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 13 Sep 2016 12:47:38 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 04:47:40 -0000 Hi Brian, It needs futher explanations. Although HTTP/2 optimized some performance of HTTP1.1, it seems not concern the Constrained feature of CoAP Node. The CoAP server may be effected if client immediately sends messages after sending its CSM without waiting for the server CSM. Is the probability of battery loss caused by inconsistency of CSM big or small? Is it a potential means for a client to attack the CoAP server by consuming its power? Reguards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Brian Raymor Sent: Wednesday, September 07, 2016 2:30 AM To: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt Refreshing this request for people returning from summer vacations ... I'd appreciate feedback on whether a CoAP+TCP client may immediately send messages after sending its CSM without waiting for the server CSM ...- https://github.com/core-wg/coap-tcp-tls/issues/58. I plan to publish -05 during the week of 9/12 which will address this set of issues - https://github.com/core-wg/coap-tcp-tls/milestone/3 Thanks, ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Wednesday, August 24, 2016 2:22 PM To: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt -04 addresses all the issues discussed at IETF 96 - with the exception of https://github.com/core-wg/coap-tcp-tls/issues/5. The authors are discussing the scope for a section related to RFC7641 (Observing resources ...). In addition, I opened a new issue related to mandatory exchange of CSM - https://github.com/core-wg/coap-tcp-tls/issues/58 - where feedback would be helpful. Both of these issues are targeted for -05. ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, August 24, 2016 2:09 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-04.txt Pages : 42 Date : 2016-08-24 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Sep 12 22:55: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 7750912B1F2 for ; Mon, 12 Sep 2016 22:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb0KA92jvryc for ; Mon, 12 Sep 2016 22:55:33 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957BB12B1F1 for ; Mon, 12 Sep 2016 22:55:33 -0700 (PDT) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id D2DAAFB8BF; Tue, 13 Sep 2016 07:55:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id WYN5Cl9kMh2A; Tue, 13 Sep 2016 07:55:30 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9E1B8FB883; Tue, 13 Sep 2016 07:55:29 +0200 (CEST) Message-ID: <57D794D2.7060303@tzi.org> Date: Tue, 13 Sep 2016 07:55:30 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Dave Thaler References: <147372053832.3711.14886788365598645137.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 05:55:36 -0000 Dave Thaler wrote: > The primary use case is to allow > a client using multicast CoAP discovery to learn a COAPS endpoint of > the server, without the server revealing privacy-sensitive > information. Hi Dave, so far we have attempted to avoid adding redirect to the CoAP state machinery. The specific use case mentioned here already appears to be covered by the server providing a link-format document with a pointer to one or more coaps:// accessible link-formats. But maybe I don't fully understand the use case. Grüße, Carsten From nobody Tue Sep 13 11:37: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 268A312B4D6 for ; Tue, 13 Sep 2016 11:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 QCrnjsf7kSUX for ; Tue, 13 Sep 2016 11:37:33 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B6F12B4D3 for ; Tue, 13 Sep 2016 11:37:33 -0700 (PDT) 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=4Ms3FzvPoK19UuYnrta9UgHC5fvKralVI/fPH3sSSm8=; b=V6x39/zb8hSsXtLMjbljXstDuzc2HTh6/ILaltx4oZiAqHG5Ue3hOGzLNZjr2GNfFg4NwlxgtuSkXODP+VboXmA1OGYmGZTt2f9gK2L9L43SzJHXzbSP2Wu+VyJdFsbQp8U81e0U5op0W/wvkGT0izpEn9metZfgh/LnxNOVzvI= Received: from CY1PR03MB2265.namprd03.prod.outlook.com (10.166.207.17) by CY1PR03MB2265.namprd03.prod.outlook.com (10.166.207.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Tue, 13 Sep 2016 18:37:32 +0000 Received: from CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) by CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) with mapi id 15.01.0619.011; Tue, 13 Sep 2016 18:37:32 +0000 From: Dave Thaler To: Carsten Bormann Thread-Topic: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt Thread-Index: AQHSDUfaLE9COg7xkEiN3H6UVqvj36B2dT/AgAB3DwCAANAhoA== Date: Tue, 13 Sep 2016 18:37:32 +0000 Message-ID: References: <147372053832.3711.14886788365598645137.idtracker@ietfa.amsl.com> <57D794D2.7060303@tzi.org> In-Reply-To: <57D794D2.7060303@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=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:5::5e] x-ms-office365-filtering-correlation-id: 4cf201a3-750e-4c02-76b3-08d3dc05061f x-microsoft-exchange-diagnostics: 1; CY1PR03MB2265; 6:Ve5r3jXxFa/+cPIHmCFxeYHUP5K1ZyUuGEOX9SsLD9kxuAGST180xedd2NTEtvpsJMawTxcsaPReM23Nschlw1W+zlH843syeMUFwTByBEhpGJeYODIZqAD8I0J+LCbSIp2/yriOgxeAxJrnTx4pwDLZp3reqv1V1TnR/eVDkaJ0ggtPEf2LwzMoszwRFbrkAm3w6AsL7lakZ0gnIxBX585KOzhLZPV2ZC763pp5nndoQ+kPU5iVUBhfbFgpeRXgKNVdV8EzuOASkbHfRh2TN6N8CtVwBQUPSe3lvr8Rfz1dkYZp8vxEOs0cZUpTniwKhEzIFadx2kBGIwGU1NkSIw==; 5:MnIahR6miAorI4lT3ndYSi9Ug7N562miTbESDPcfxaTdF9Pe0Blu1jBD3YrC14nbFh0NmJBfAiFb3QGK4+XQDZIrP/OyiuvbNePKn6VrPI3zsGDigeZqxNL3p319PjfahHN2ha9pgVyWApZQcSD+Gg==; 24:y2mpKDe8G1yFAWDItkG4CfXwqHNcfNyWOEvxczI9mBXzM6+trLWcqwmlbtnPRvgEb/4LIKBRNgStB7JJv89inCwoK4XTaHWZZDBFV+DON8c=; 7:3SZ6aVHD9QOjYqaxfuk7SRNcTuVngiQp2LNgrnD9ArwrHv7QiBRaQM2brJiX79hQ2jM93qil4ems0JeGXj/MDCLFKtWJROOYimnOJiPnMG9gx+WX4Zojo7FT29is0A3DkszV3gYBGcP3PyB8OEiWazL79B2QmgnhcKkvfpUfQLV5wVm/4whambuM0j18ftbJ6pR+4+rjqjjvJTyU0YkuRpsrgpd5RN1CUyOzzrsSLNydc+W6inQnjYp+zzenqGgl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2265; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2265; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2265; x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(24454002)(6116002)(102836003)(8990500004)(11100500001)(8936002)(7696004)(99286002)(86612001)(2906002)(189998001)(86362001)(106116001)(105586002)(81166006)(586003)(7736002)(87936001)(106356001)(10090500001)(8676002)(305945005)(33656002)(81156014)(97736004)(74316002)(7846002)(68736007)(50986999)(54356999)(122556002)(2950100001)(2900100001)(76176999)(3280700002)(10290500002)(101416001)(92566002)(230783001)(77096005)(10400500002)(5005710100001)(561944003)(9686002)(76576001)(4326007)(5660300001)(3660700001)(110136003)(5002640100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2265; H:CY1PR03MB2265.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2016 18:37:32.4043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2265 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 18:37:36 -0000 Q2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KPiBzbyBmYXIgd2UgaGF2ZSBhdHRlbXB0ZWQgdG8gYXZv aWQgYWRkaW5nIHJlZGlyZWN0IHRvIHRoZSBDb0FQIHN0YXRlDQo+IG1hY2hpbmVyeS4NCj4gDQo+ IFRoZSBzcGVjaWZpYyB1c2UgY2FzZSBtZW50aW9uZWQgaGVyZSBhbHJlYWR5IGFwcGVhcnMgdG8g YmUgY292ZXJlZCBieSB0aGUNCj4gc2VydmVyIHByb3ZpZGluZyBhIGxpbmstZm9ybWF0IGRvY3Vt ZW50IHdpdGggYSBwb2ludGVyIHRvIG9uZSBvciBtb3JlDQo+IGNvYXBzOi8vIGFjY2Vzc2libGUg bGluay1mb3JtYXRzLg0KPiANCj4gQnV0IG1heWJlIEkgZG9uJ3QgZnVsbHkgdW5kZXJzdGFuZCB0 aGUgdXNlIGNhc2UuDQoNClRoZXJlJ3MgYWxyZWFkeSBhbiBleGlzdGluZyByZXNvdXJjZSB0aGF0 IHRoZSBPQ0YgY2xpZW50cyB1c2UgZm9yIG11bHRpY2FzdCBkaXNjb3ZlcnkgdGhhdA0KaGFzIHBy aXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiAgIFRoZSBleGlzdGluZyByZXNvdXJjZSBjYW4n dCBiZSBjaGFuZ2VkIHdpdGhvdXQNCmJyZWFraW5nIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCBi dXQgaXQgaXMgb2sgdG8gYnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaWYgdGhlDQpzZXJ2 ZXIgaXMgY29uZmlndXJlZCB0byBiZSBpbiBhIHByaXZhY3ktc2Vuc2l0aXZlIG1vZGUuDQoNCkJ5 ICJwcm92aWRpbmcgYSBsaW5rLWZvcm1hdCBkb2N1bWVudCIsIEkgYXNzdW1lIHlvdSBtZWFuIGEg bmV3IHJlc291cmNlIChsZXQgbWUga25vdw0KaWYgSSBtaXN1bmRlcnN0YW5kKS4gICBTbyBJIGJl bGlldmUgeW91J3JlIHN1Z2dlc3RpbmcgY3JlYXRpbmcgYSBuZXcgcmVzb3VyY2UgZm9yIG5vbi1s ZWdhY3kNCmNsaWVudHMgdG8gdXNlIHRoYXQgd2lsbCByZXR1cm4gcm91Z2hseSB3aGF0IGEgcmVk aXJlY3Qgd291bGQgaGF2ZSByZXR1cm5lZCwgYW5kIGhhdmUNCnRoZSBleGlzdGluZyByZXNvdXJj ZSBub3QgcmVzcG9uZD8gIE9yIHJldHVybiBhbiBlcnJvcj8NCg0KVGhlcmUncyBhIGNvdXBsZSBj YXNlcyBvbiB0aGUgc2VydmVyIHNpZGU6DQoxKSBTZXJ2ZXIgaXMgY29uZmlndXJlZCBmb3Igbm9u LXByaXZhY3ktc2Vuc2l0aXZlIGNvbmZpZzogZXhpc3RpbmcgcmVzb3VyY2UgY2FuIHJlc3BvbmQg dG8gbXVsdGljYXN0DQoyKSBTZXJ2ZXIgaXMgY29uZmlndXJlZCBmb3IgcHJpdmFjeS1zZW5zaXRp dmUgY29uZmlnOiBleGlzdGluZyByZXNvdXJjZSBtdXN0IGZhaWwuDQoNCkFuZCBvbiB0aGUgY2xp ZW50IHNpZGU6DQoxKSBBIGxlZ2FjeSBjbGllbnQgd2lsbCBzZW5kIG11bHRpY2FzdCBxdWVyeSBm b3IgZXhpc3RpbmcgcmVzb3VyY2U6IGl0IHdpbGwgd29yayBub3JtYWxseSB3aXRoIHNlcnZlcnMN CiAgICBpbiB0aGUgbm9uLXByaXZhY3ktc2Vuc2l0aXZlIGNvbmZpZy4gICBJdCB3aWxsIGZhaWwg d2l0aCBzZXJ2ZXJzIGluIHRoZSBwcml2YWN5LXNlbnNpdGl2ZSBjb25maWcsDQogICAgdGhvdWdo IGhvdyBpdCBmYWlscyB2YXJpZXMgYmFzZWQgb24gd2hhdCBzb2x1dGlvbiBpcyBjaG9zZW4uDQoN CjIpIEEgbmV3IGNsaWVudCB3aWxsIHNlbmQgbXVsdGljYXN0IHF1ZXJ5IGZvciBuZXcgcmVzb3Vy Y2U6IG5ldyBzZXJ2ZXIgd2lsbCByZXNwb25kIHdpdGggc3VjY2VzcywNCiAgICAgcGFzc2luZyBi YWNrIHRoZSBzb3J0IG9mIGRhdGEgaXQgd291bGQgaGF2ZSBwdXQgaW4gYSByZWRpcmVjdCwgaGFk IHJlZGlyZWN0cyBiZWVuIHVzZWQuDQogICAgIEJ1dCBsZWdhY3kgc2VydmVycyB3b24ndCByZXNw b25kIGF0IGFsbCwgYW5kIHRoZSBjbGllbnQgd29uJ3QgZ2V0IHRoZSBhbnN3ZXIgZnJvbSB0aGlz IHF1ZXJ5LA0KICAgICBidXQgaGFzIHRvIHNlbmQgb3V0IGEgbGVnYWN5IHF1ZXJ5IHRvIHRoZSBl eGlzdGluZyByZXNvdXJjZSBpbiBhZGRpdGlvbi4NCg0KICAgICBUaGUgbmV3IGNsaWVudCBkb2Vz bid0IGtub3cgd2hldGhlciBzZXJ2ZXJzIGFyZSBpbiBhIHByaXZhY3ktc2Vuc2l0aXZlIGNvbmZp ZyBvciBub3QsIHNvIGl0IGhhcyB0byBzZW5kDQogICAgIG91dCBhIHF1ZXJ5IChvciBxdWVyaWVz KSB0aGF0IHdpbGwgZ2V0IHJlc3BvbnNlcyBmcm9tIGJvdGggdHlwZXMuICAgVGh1cyB3aXRoIGEg bmV3IHJlc291cmNlLA0KICAgICB5b3VyIHByb3Bvc2FsIGRvdWJsZXMgdGhlIG51bWJlciBvZiBt dWx0aWNhc3QgcXVlcmllcyBvbiB0aGUgbmV0d29yay4gICBJZiB0aGUgbGVnYWN5IHF1ZXJ5DQog ICAgIHJlc3VsdHMgaW4gYW4gZXJyb3IgKHJhdGhlciB0aGFuIG5vIHJlc3BvbnNlKSBmcm9tIHBy aXZhY3ktc2Vuc2l0aXZlIHNlcnZlcnMsIHRoaXMgYWxzbyBkb3VibGVzDQogICAgIHRoZSByZXNw b25zZSBpbXBsb3Npb24gcHJvYmxlbSBhdCB0aGUgY2xpZW50Lg0KDQpTbyByZWRpcmVjdHMgYXJl IGF0IGxlYXN0IHR3aWNlIGFzIGVmZmljaWVudCBhcyBub3QgaGF2aW5nIHRoZW0sIGFuZCB0aGlz IGVmZmljaWVuY3kgaXMgaW1wb3J0YW50DQpmb3IgY29uc3RyYWluZWQgbm9kZXMvbmV0d29ya3Mu DQoNCkRhdmUNCg== From nobody Tue Sep 13 13:26: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 7B31F12B076 for ; Tue, 13 Sep 2016 13:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3QbnyMoJwCY for ; Tue, 13 Sep 2016 13:26:54 -0700 (PDT) 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 5D4B912B037 for ; Tue, 13 Sep 2016 13:26:54 -0700 (PDT) Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 147C91720BD; Tue, 13 Sep 2016 22:26:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Z0zPjWVEDvwI; Tue, 13 Sep 2016 22:26:51 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B31AA17209C; Tue, 13 Sep 2016 22:26:50 +0200 (CEST) Message-ID: <57D86108.8060101@tzi.org> Date: Tue, 13 Sep 2016 22:26:48 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Dave Thaler References: <147372053832.3711.14886788365598645137.idtracker@ietfa.amsl.com> <57D794D2.7060303@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 20:26:56 -0000 Hi Dave, I'm afraid I'm not as familiar with the OCF specs here, so having a fully fleshed out example would help me understand the problem better than speaking abstractly about "the resource", "multicast query", etc. I understood the problem statement as talking about the discovery process, not about the actual sensor/actuator resources. So a highly privacy sensitive device might just answer a multicast GET to /.well-known/core with ;ct=40 which means "I won't tell you anything about me except over some form of a secure channel (and I'm not telling what form of that)"; maybe some additional link relations can fill in the latter point a bit. If it is a bit more lenient, it might even answer a GET to /.well-known/core?rt=bar with a similar response, revealing that it does implement a bar. I'm not sure I understand how an HTTP-style redirect would help here except by making things more complicated, so a more detailed example would help. HTTP-style redirect is most useful where clients have long-term memories of links and servers need to update their resource structure during those long terms. In the CoRE world, we expect clients to be more agile on the discovery front, removing the need for redirects. For the remaining situations where redirects were popular in HTTP, returning RFC 7807-style error objects may be way more useful, because we then have the whole media type system to distinguish all the fine points that are so confusing about redirects. Grüße, Carsten From nobody Tue Sep 13 17:26: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 E297812B2CC; Tue, 13 Sep 2016 17:26:34 -0700 (PDT) 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 wwofauMhKFEV; Tue, 13 Sep 2016 17:26:32 -0700 (PDT) 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 9AD8712B2C3; Tue, 13 Sep 2016 17:26:32 -0700 (PDT) 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:Cc:References:To:Subject:Sender :Reply-To: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=nD3GWYfOO+3ofqlldvqjKDFic4RfAJFFdOEOn4ZdevY=; b=AbMUJv9JxeQtx1VY8fGj8zs4Nj vdwTu4MBpYXvCxtiL/T22aDw7k34TD9RCGLSUNIDU8CC0H91rCEmIO+ekpo+t8IxzPFOL+02DJZGI 6W9uPJhP3NvMqWMjMF0XGwpjoDCbSjW9a1O1w9ZJRYWVrtN+6voFeIV3DJV6hGg3e7cWwu7PTmo2I qTXh945RPyxVkB5x3HRdIBxpu+T6T6dlUttLQBYJOw+AXxL3+h4z97xc3W/ehPNsAR0usVri1xPjs SGd82T75vb2Z4xurO4L5p8EdDRTjY5HuCk0RfDOlJK/YAmNJBQqJ7kHhdxOO/ubREBpKQJJVdGu9Q 7hq3dZqw==; Received: from ppp118-209-40-197.lns20.mel4.internode.on.net ([118.209.40.197]:50488 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 1bjy20-00239s-So; Wed, 14 Sep 2016 10:26:28 +1000 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> <3A9C9924-D032-4BEE-9B78-DF94680A7C95@ericsson.com> <57879b61-d9fc-2cce-d56a-7bd9c78c2ff7@nteczone.com> From: Christian Groves Message-ID: <75943243-36cf-c06e-16e6-863f2dd0b5ae@nteczone.com> Date: Wed, 14 Sep 2016 10:26:25 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Cc: "draft-groves-core-dynlink@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-groves-core-dynlink?= 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 Sep 2016 00:26:35 -0000 Hello Jaime, One thing to note is that the LwM2M specification (see table 4/section 5.1.2) makes use of the observe attributes defined in this draft. With the core interfaces document split, the LWM2M draft would need to be updated to reference the dynlink draft. Regards, Christian On 5/09/2016 6:42 PM, Jaime Jiménez wrote: > Hi all, > > there has been no feedback apart from that of the authors of this draft. Therefore we will be extending the deadline for this draft and we will try to reach a conclusion by the end of this week. > > Ciao, > - - Jaime Jiménez > >> On 31 Aug 2016, at 03:15, Christian Groves wrote: >> >> No surprise as author I support the draft.. >> >> Regards, Christian >> >> >> On 26/08/2016 10:01 PM, Jaime Jiménez wrote: >>> Hi all, >>> >>> As people are on vacation, let’s extend the deadline few days more to allow people to comment. >>> >>> Ciao! >>> - - Jaime Jimenez >>> >>>> On 15 Aug 2016, at 18:05, Jaime Jiménez > wrote: >>>> >>>> Dear CoRE-WG, >>>> >>>> As we discussed at last IETF96, working group adoption has been requested for draft-groves-core-dynlink. This draft is the result of a document split and thus the initial status is that of adoption, nevertheless that has to be confirmed on the list. Please reply with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. >>>> >>>> Since there are several concurrent WGA calls, we will end the call on *August 26, 2016*. >>>> >>>> Thanks, >>>> Jaime and Carsten From nobody Wed Sep 14 00:21: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 2EFDD12B17E for ; Wed, 14 Sep 2016 00:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36fpi0Jv0DJf for ; Wed, 14 Sep 2016 00:21:14 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8612B15D for ; Wed, 14 Sep 2016 00:21:14 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 28BC119F409 for ; Wed, 14 Sep 2016 15:21:13 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.57]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 7863E19F3DC; Wed, 14 Sep 2016 15:21:12 +0800 (HKT) Message-ID: <5BC478FD5AC445798E221150D9C227C0@WeiGengyuPC> From: "weigengyu" To: "Jim Schaad" , "'Klaus Hartke'" References: <036801d1ed09$507ef080$f17cd180$@augustcellars.com> <047701d1eda6$4af5c5b0$e0e15110$@augustcellars.com> In-Reply-To: <047701d1eda6$4af5c5b0$e0e15110$@augustcellars.com> Date: Wed, 14 Sep 2016 15:21:15 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org, core@ietf.org Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 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 Sep 2016 07:21:18 -0000 Hi, Just one question. Is it required to refer to documentations on threats of HTTP proxies? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Jim Schaad Sent: Thursday, August 04, 2016 12:44 AM To: 'Klaus Hartke' Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org ; core@ietf.org Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 > -----Original Message----- > From: Klaus Hartke [mailto:hartke@tzi.org] > Sent: Wednesday, August 03, 2016 8:23 AM > To: Jim Schaad > Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org; core@ietf.org WG > > Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 > > Hi Jim, > > thanks a lot for your review. Comments inline below. > > Klaus > > > Jim Schaad wrote: > > > 2. Section 2.1.1 - Should "client receives a response" include > > > > * (Threat ?) The proxy returns a stale or outdated response based > > on data it previously obtained from the origin server or some fourth > > party. > > > > I'm thinking of both out of date caches and poisoned > > caches. > > Note that these are valid from a security point of view, but not 'fresh' > > This is a part of (Threat 1:) The proxy spoofs a response. > > In the mitigation section (2.1.1.1.) we define that a response is valid > from a > security point of view only if it is fresh. > > (We use the term "authentic" instead of "valid" though, because "valid" is > already used in the context of cache validation.) > > I've expanded the text with your suggestion: > > * (Threat 1:) The proxy spoofs a response. For example, the > proxy could return a stale or outdated response based on data > it previously obtained from the server or some fourth party, or > could craft an illicit response itself. > My problem with this is that I view a spoof as different. To me a spoof implies the attempt to create a new message that will pass muster as oppose to doing something like a replay. It would probably be better to use a different term. I'll try and remember to ponder on this. Jim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Sep 14 18:43: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 61B6512B04E for ; Wed, 14 Sep 2016 18:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 OYkfvvUWdu6m for ; Wed, 14 Sep 2016 18:43:30 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0099.outbound.protection.outlook.com [104.47.41.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0995812B111 for ; Wed, 14 Sep 2016 18:43:29 -0700 (PDT) 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=Gk86O6QbTdI6jvmvRsLhG4N/oGLHkPi6nH2NOqjNDk0=; b=AkPp0OMr3nzbR2pH+rRVz5FZdsDeBD+dvp03AN8QCgZFSA1WI7YNR+i34a/dT6IWqy5y/XWkfyX6Qmpp7AAPBF3UACQH26LVgszNmWAPpcMOQf9QEUJuDITgXaMo59j7UTKaG2Ang7hKysnZMHETlQThSFrz9qG5yPxnB4hDjY0= Received: from CY1PR03MB2265.namprd03.prod.outlook.com (10.166.207.17) by CY1PR03MB2266.namprd03.prod.outlook.com (10.166.207.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Thu, 15 Sep 2016 01:43:28 +0000 Received: from CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) by CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) with mapi id 15.01.0619.011; Thu, 15 Sep 2016 01:43:28 +0000 From: Dave Thaler To: Carsten Bormann Thread-Topic: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt Thread-Index: AQHSDUfaLE9COg7xkEiN3H6UVqvj36B2dT/AgAB3DwCAANAhoIAAI08AgAHozqA= Date: Thu, 15 Sep 2016 01:43:28 +0000 Message-ID: References: <147372053832.3711.14886788365598645137.idtracker@ietfa.amsl.com> <57D794D2.7060303@tzi.org> <57D86108.8060101@tzi.org> In-Reply-To: <57D86108.8060101@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=dthaler@microsoft.com; x-originating-ip: [131.107.147.32] x-ms-office365-filtering-correlation-id: 3746ff74-b325-4a2c-a963-08d3dd09b137 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2266; 6:QnoZwj1DcRgnnpl+befus9eiJSWuly5LOlNqro2Lyxb7XgNHuEIzgAjHWN1t39jYdL+Nj8PLnU/cx9Er20sRHWb5QExfxL304vVOKgjVOWgfxObRP7SuFdeRIn8APu118FypK+brOpr1cuXv+ExVlAIWCAyUBA6zVA3yYZB0KtlzR6q2K0CDgK+YQ3nIVwN+7dPDopfj91/xUdnwze/msuOKy7OcTqqnkl0c8muBF11J4FkjOgrBqr+4Tbg6nwBVM3RTajzPM070dSdPhWWxoJcdt5cPcmAan00PQ1sqKVDAQXLdD4MR1UFZtMouz1Ek9otAvGwSgavPwY+nOaGS3g==; 5:8Q8feEKji+TEmgN5Ky4AzRKPn1CX4CyLo0fdFa0jyLlBuKVMpPAzyHbebyI1HDamwmONohYoQuAcRwaQCF0JbUEMplnmXjfe1ViTqcRQ0deFBplG7q5HLr9qz80l23nvz6tgj/r3uo1AQrRpwtRsTw==; 24:OshMm7OPzvx9XasZ07UBcR6LW8RKCnLbf+Ke1471IM2HEVKOnCooLjlEgnnJ0JSBUDZ9YppV3S1ACLP4BLHmoRjySGpM+bnsoqrDkkuO6qo=; 7:B4jazsyhWn+VBXTCr86M5zqTbWsig5I8d31sfDlsPl7R9ftfPEsU6WkiLMX6o29hmXeEju4OV+HCvgTK5iZ1ENeVtlO9GmepSWTy9PIAo7M32fZd41LRcnijEk289HG4QN4RgGqCHgTvlCOdYJCCu9yWtoI5q8PzwZtuUpYVzle4UWD6iE7h7CkCfX+tlaAIBUx8PW4tuAXHZr8FIaIjWrZ/26e7lom80L1CoF7MF2FMxbpnnNnQa0shhhDTH+Y4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2266; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2266; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2266; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(13464003)(199003)(586003)(9686002)(2906002)(6116002)(3846002)(97736004)(86362001)(86612001)(3660700001)(4326007)(92566002)(19580405001)(5002640100001)(33656002)(10400500002)(11100500001)(5005710100001)(66066001)(3280700002)(189998001)(19580395003)(7696004)(10290500002)(8990500004)(230783001)(5660300001)(8936002)(2900100001)(81166006)(93886004)(99286002)(68736007)(87936001)(10090500001)(101416001)(106116001)(102836003)(2950100001)(105586002)(7736002)(81156014)(54356999)(76576001)(15650500001)(50986999)(8676002)(106356001)(74316002)(122556002)(305945005)(77096005)(7846002)(110136003)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2266; H:CY1PR03MB2265.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2016 01:43:28.4989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2266 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] FW: New Version Notification for draft-thaler-core-redirect-00.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: Thu, 15 Sep 2016 01:43:33 -0000 U2hvcnQgdmVyc2lvbjoNCg0KRXhpc3RpbmcgY2xpZW50cyBkbyAobXVsdGljYXN0KSBHRVQgL29p Yy9yZXMsIGFuZCB0aGUgcmVzcG9uc2UgY29udGFpbnMgcHJpdmFjeS1zZW5zaXRpdmUgaW5mb3Jt YXRpb24sIHBsdXMgc29tZSBsaW5rcw0KQW5kIGV4aXN0aW5nIHNlcnZlcnMgd2lsbCByZXNwb25k IHRvIG11bHRpY2FzdCBHRVQgL29pYy9yZXMgKGJ1dCBub3QgLy53ZWxsLWtub3duL2NvcmUpLg0K DQpSZWRpcmVjdHMgYWxsb3cgdGhlIGZvbGxvd2luZyBvcHRpbWl6ZWQgYmVoYXZpb3IuLi4NCk5l dyBjbGllbnRzIGRvIChtdWx0aWNhc3QpIEdFVCAvb2ljL3JlcyAob3IgL29pYy9yZXM/cnQ9YmFy KSwgYW5kIHRoZSByZXNwb25zZXMgd291bGQgYmU6DQphKSBsZWdhY3kgc2VydmVycywgYW5kIGFu eSBuZXcgc2VydmVycyB0aGF0IGFyZSBub3QgY29uZmlndXJlZCB0byBiZSBwcml2YWN5LXNlbnNp dGl2ZSwgcmVzcG9uZCB3aXRoIGFjdHVhbCBjb250ZW50LA0KICAgICAgdGh1cyBrZWVwaW5nIGxh dGVuY3kgYW5kIG1lc3NhZ2VzIHRvIGEgbWluaW11bQ0KYikgbmV3IHByaXZhY3ktc2Vuc2l0aXZl IHNlcnZlciB3b3VsZCBpbnN0ZWFkIHJlc3BvbmQgd2l0aCBhIHJlZGlyZWN0IHRvIGEgY29hcHM6 Ly88aXBhZGRyPjo8cG9ydD4vb2ljL3Jlcw0KICAgICAgQSBzdWJzZXF1ZW50IGNvYXBzIEdFVCAv b2ljL3JlcyB0byB0aGF0IGVuZHBvaW50IHJldHVybnMgYWN0dWFsIGRhdGEgKGp1c3QgYXMgdW5p Y2FzdCBjb2FwcyBhbHdheXMgZGlkIGJlZm9yZSkuDQoNClRodXMsIHRoZSBvdmVyaGVhZCBpcyBr ZXB0IHRvIGEgbWluaW11bS4NCg0KSXMgdGhhdCBjbGVhcj8NCg0KRGF2ZQ0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9A dHppLm9yZ10NCj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDEzLCAyMDE2IDE6MjcgUE0NCj4g VG86IERhdmUgVGhhbGVyIDxkdGhhbGVyQG1pY3Jvc29mdC5jb20+DQo+IENjOiBjb3JlQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtdGhhbGVyLWNvcmUtDQo+IHJlZGlyZWN0LTAwLnR4dA0KPiANCj4gSGkgRGF2ZSwN Cj4gDQo+IEknbSBhZnJhaWQgSSdtIG5vdCBhcyBmYW1pbGlhciB3aXRoIHRoZSBPQ0Ygc3BlY3Mg aGVyZSwgc28gaGF2aW5nIGEgZnVsbHkgZmxlc2hlZA0KPiBvdXQgZXhhbXBsZSB3b3VsZCBoZWxw IG1lIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gYmV0dGVyIHRoYW4gc3BlYWtpbmcNCj4gYWJzdHJh Y3RseSBhYm91dCAidGhlIHJlc291cmNlIiwgIm11bHRpY2FzdCBxdWVyeSIsIGV0Yy4NCj4gDQo+ IEkgdW5kZXJzdG9vZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYXMgdGFsa2luZyBhYm91dCB0aGUg ZGlzY292ZXJ5IHByb2Nlc3MsDQo+IG5vdCBhYm91dCB0aGUgYWN0dWFsIHNlbnNvci9hY3R1YXRv ciByZXNvdXJjZXMuDQo+IA0KPiBTbyBhIGhpZ2hseSBwcml2YWN5IHNlbnNpdGl2ZSBkZXZpY2Ug bWlnaHQganVzdCBhbnN3ZXIgYSBtdWx0aWNhc3QgR0VUIHRvDQo+IC8ud2VsbC1rbm93bi9jb3Jl IHdpdGgNCj4gDQo+IDxjb2FwczovLy4uLj47Y3Q9NDANCj4gDQo+IHdoaWNoIG1lYW5zICJJIHdv bid0IHRlbGwgeW91IGFueXRoaW5nIGFib3V0IG1lIGV4Y2VwdCBvdmVyIHNvbWUgZm9ybSBvZiBh DQo+IHNlY3VyZSBjaGFubmVsIChhbmQgSSdtIG5vdCB0ZWxsaW5nIHdoYXQgZm9ybSBvZiB0aGF0 KSI7IG1heWJlIHNvbWUNCj4gYWRkaXRpb25hbCBsaW5rIHJlbGF0aW9ucyBjYW4gZmlsbCBpbiB0 aGUgbGF0dGVyIHBvaW50IGEgYml0Lg0KPiANCj4gSWYgaXQgaXMgYSBiaXQgbW9yZSBsZW5pZW50 LCBpdCBtaWdodCBldmVuIGFuc3dlciBhIEdFVCB0byAvLndlbGwtDQo+IGtub3duL2NvcmU/cnQ9 YmFyIHdpdGggYSBzaW1pbGFyIHJlc3BvbnNlLCByZXZlYWxpbmcgdGhhdCBpdCBkb2VzIGltcGxl bWVudA0KPiBhIGJhci4NCj4gDQo+IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgaG93IGFuIEhU VFAtc3R5bGUgcmVkaXJlY3Qgd291bGQgaGVscCBoZXJlIGV4Y2VwdA0KPiBieSBtYWtpbmcgdGhp bmdzIG1vcmUgY29tcGxpY2F0ZWQsIHNvIGEgbW9yZSBkZXRhaWxlZCBleGFtcGxlIHdvdWxkIGhl bHAuDQo+IA0KPiBIVFRQLXN0eWxlIHJlZGlyZWN0IGlzIG1vc3QgdXNlZnVsIHdoZXJlIGNsaWVu dHMgaGF2ZSBsb25nLXRlcm0gbWVtb3JpZXMgb2YNCj4gbGlua3MgYW5kIHNlcnZlcnMgbmVlZCB0 byB1cGRhdGUgdGhlaXIgcmVzb3VyY2Ugc3RydWN0dXJlIGR1cmluZyB0aG9zZSBsb25nDQo+IHRl cm1zLiAgSW4gdGhlIENvUkUgd29ybGQsIHdlIGV4cGVjdCBjbGllbnRzIHRvIGJlIG1vcmUgYWdp bGUgb24gdGhlDQo+IGRpc2NvdmVyeSBmcm9udCwgcmVtb3ZpbmcgdGhlIG5lZWQgZm9yIHJlZGly ZWN0cy4gIEZvciB0aGUgcmVtYWluaW5nDQo+IHNpdHVhdGlvbnMgd2hlcmUgcmVkaXJlY3RzIHdl cmUgcG9wdWxhciBpbiBIVFRQLCByZXR1cm5pbmcgUkZDIDc4MDctc3R5bGUNCj4gZXJyb3Igb2Jq ZWN0cyBtYXkgYmUgd2F5IG1vcmUgdXNlZnVsLCBiZWNhdXNlIHdlIHRoZW4gaGF2ZSB0aGUgd2hv bGUNCj4gbWVkaWEgdHlwZSBzeXN0ZW0gdG8gZGlzdGluZ3Vpc2ggYWxsIHRoZSBmaW5lIHBvaW50 cyB0aGF0IGFyZSBzbyBjb25mdXNpbmcNCj4gYWJvdXQgcmVkaXJlY3RzLg0KPiANCj4gR3LDvMOf ZSwgQ2Fyc3Rlbg0K From nobody Fri Sep 16 06:28: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 5556812B31F for ; Fri, 16 Sep 2016 06:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 Q6JVhUeAVD2S for ; Fri, 16 Sep 2016 06:28:17 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 CEDA312B284 for ; Fri, 16 Sep 2016 06:25:05 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id u8GDP2PA028794 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 16 Sep 2016 15:25:03 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u8GDP2he000868 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Sep 2016 15:25:03 +0200 Received: from DENBGAT9ERGMSX.ww902.siemens.net (139.22.70.137) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 16 Sep 2016 15:25:02 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.119]) by DENBGAT9ERGMSX.ww902.siemens.net ([139.22.70.137]) with mapi id 14.03.0301.000; Fri, 16 Sep 2016 15:25:02 +0200 From: "Kovatsch, Matthias" To: "core@ietf.org" Thread-Topic: SIFI Workshop Deadline Extension: 26 Sep 2016 Thread-Index: AdIQHbofD1D/PCNpRIWbMYq3G0qe9A== Date: Fri, 16 Sep 2016 13:25:01 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01891896@DEFTHW99EL4MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.34] Content-Type: multipart/alternative; boundary="_000_4EBB3DDD0FBF694CA2A87838DF129B3C01891896DEFTHW99EL4MSXw_" MIME-Version: 1.0 Archived-At: Subject: [core] SIFI Workshop Deadline Extension: 26 Sep 2016 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 Sep 2016 13:28:23 -0000 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01891896DEFTHW99EL4MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear group Here is the obligatory deadline extension: Submit until 26 Sep 2016 via htt= ps://easychair.org/conferences/?conf=3Dwot2016 The workshop will be held in Stuttgart, Germany on 7 Nov 2016. We teamed up with the Seventh International Workshop on the Web of Things (= WoT 2016) to broaden the reach and to strengthen the first issue of the SIF= I Workshop. The papers will be submitted through the WoT 2016 EasyChair and= selected papers will be offered to present in the SIFI session to foster a= research community for semantic interoperability; there will also be a bre= akout session to discuss further development of the presented work. We hope= that teaming with WoT 2016 re-assures authors that prefer to submit to an = already established workshop series. More information: https://sifi-workshop.github.io/ Best wishes Matthias Kovatsch --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01891896DEFTHW99EL4MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear group=

 

Here is the obligatory deadl= ine extension: Submit until 26 Sep 2016 via https://easychair.org/conferenc= es/?conf=3Dwot2016

The workshop will be held in= Stuttgart, Germany on 7 Nov 2016.

 

We teamed up with the Sevent= h International Workshop on the Web of Things (WoT 2016) to broaden the rea= ch and to strengthen the first issue of the SIFI Workshop. The papers will = be submitted through the WoT 2016 EasyChair and selected papers will be offered to present in the SIFI session to fost= er a research community for semantic interoperability; there will also be a= breakout session to discuss further development of the presented work. We = hope that teaming with WoT 2016 re-assures authors that prefer to submit to an already established worksho= p series.

 

More information: https://si= fi-workshop.github.io/

 

Best wishes

Matthias Kovatsch

 

--_000_4EBB3DDD0FBF694CA2A87838DF129B3C01891896DEFTHW99EL4MSXw_-- From nobody Fri Sep 16 11:44:29 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 1C46912B05D; Fri, 16 Sep 2016 09:13:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Carsten Bormann" , "Hannes Tschofenig" , "Kepeng Li" , "Jaime Jimenez" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147404240507.25427.16876431560621664117.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2016 09:13:25 -0700 Archived-At: X-Mailman-Approved-At: Fri, 16 Sep 2016 11:44:28 -0700 Cc: Ben Campbell , Alexey Melnikov , jhnah@etri.re.kr, Alissa Cooper , Scott Mansfield , Kathleen Moriarty , Constrained RESTful Environments Discussion List , Authentication and Authorization for Constrained Environments Discussion List , itu-t-liaison@iab.org Subject: [core] New Liaison Statement, "LS on work items Big Data security in ITU-T SG 17" 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, 16 Sep 2016 16:13:25 -0000 Title: LS on work items Big Data security in ITU-T SG 17 Submission Date: 2016-09-16 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1492/ From: "Martin Euchner" To: Kepeng Li ,Hannes Tschofenig ,Carsten Bormann ,Jaime Jimenez Cc: Constrained RESTful Environments Discussion List ,Kepeng Li ,Alexey Melnikov ,Scott Mansfield ,Ben Campbell ,Stephen Farrell ,Kathleen Moriarty ,Jaime Jimenez ,Hannes Tschofenig ,Carsten Bormann ,Authentication and Authorization for Constrained Environments Discussion List ,Alissa Cooper ,itu-t-liaison@iab.org, Response Contacts: jhnah@etri.re.kr Technical Contacts: Purpose: For information Body: ITU-T Study Group 17, Security, is please to inform you of two items regarding big data security. The attachments are the baseline text for ongoing work on draft Recommendation of ITU-T X.websec-7, Reference monitor for online analytics services, and the template of new work item X.srfb, Security requirements and framework for Big Data analytics in mobile Internet services that was established at our September 2016 meeting. We are looking forward to further collaboration with you on those items. Attachments: 2 -X.websec-7: Draft Reccomendation IETU-T X.websec-7, Reference monitor for online analytics services; -New work item template for X.srfb, Security requirements and framework for Big Data analytics in mobile Internet services Attachments: X.websec-7: Draft Reccomendation IETU-T X.websec-7, Reference monitor for online analytics services https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-09-16-itu-t-sg-17-core-ace-ls-on-work-items-big-data-security-in-itu-t-sg-17-attachment-1.pdf New work item template for X.srfb, Security requirements and framework for Big Data analytics in mobile Internet services https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-09-16-itu-t-sg-17-core-ace-ls-on-work-items-big-data-security-in-itu-t-sg-17-attachment-2.pdf Liaison https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-09-16-itu-t-sg-17-core-ace-ls-on-work-items-big-data-security-in-itu-t-sg-17-attachment-3.pdf From nobody Sat Sep 17 14:37: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 DE604127077 for ; Sat, 17 Sep 2016 14:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-2.316, 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 H7iReGhCI3dS for ; Sat, 17 Sep 2016 14:37:49 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3908126D74 for ; Sat, 17 Sep 2016 14:37:48 -0700 (PDT) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 17 Sep 2016 14:51:00 -0700 From: Jim Schaad To: 'weigengyu' , 'Klaus Hartke' References: <036801d1ed09$507ef080$f17cd180$@augustcellars.com> <047701d1eda6$4af5c5b0$e0e15110$@augustcellars.com> <5BC478FD5AC445798E221150D9C227C0@WeiGengyuPC> In-Reply-To: <5BC478FD5AC445798E221150D9C227C0@WeiGengyuPC> Date: Sat, 17 Sep 2016 14:37:33 -0700 Message-ID: <02b001d2112b$b5b241f0$2116c5d0$@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: AQFVQec6mZkH2zubcUsWpGYFrv/2RAEXD4dJAfiG7VwB7PWwkaFP7uWQ Content-Language: en-us X-Originating-IP: [173.8.216.38] Archived-At: Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org, core@ietf.org Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 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, 17 Sep 2016 21:37:51 -0000 I am not sure that I follow why you believe that an HTTP proxy document = should be referenced. The problem space might be similar but there are = some very distinct differences around things like caching that are done = by components other than HTTP proxies. jim > -----Original Message----- > From: weigengyu [mailto:weigengyu@bupt.edu.cn] > Sent: Wednesday, September 14, 2016 12:21 AM > To: Jim Schaad ; 'Klaus Hartke' = > Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org; core@ietf.org > Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 >=20 > Hi, >=20 > Just one question. > Is it required to refer to documentations on threats of HTTP proxies? >=20 > Regards, >=20 > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > From: Jim Schaad > Sent: Thursday, August 04, 2016 12:44 AM > To: 'Klaus Hartke' > Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org ; core@ietf.org > Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 >=20 >=20 >=20 > > -----Original Message----- > > From: Klaus Hartke [mailto:hartke@tzi.org] > > Sent: Wednesday, August 03, 2016 8:23 AM > > To: Jim Schaad > > Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org; = core@ietf.org WG > > > > Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 > > > > Hi Jim, > > > > thanks a lot for your review. Comments inline below. > > > > Klaus > > > > > > Jim Schaad wrote: > > > > > 2. Section 2.1.1 - Should "client receives a response" include > > > > > > * (Threat ?) The proxy returns a stale or outdated response = based > > > on data it previously obtained from the origin server or some = fourth > > > party. > > > > > > I'm thinking of both out of date caches and = poisoned > > > caches. > > > Note that these are valid from a security point of view, but not = 'fresh' > > > > This is a part of (Threat 1:) The proxy spoofs a response. > > > > In the mitigation section (2.1.1.1.) we define that a response is = valid > > from a > > security point of view only if it is fresh. > > > > (We use the term "authentic" instead of "valid" though, because = "valid" is > > already used in the context of cache validation.) > > > > I've expanded the text with your suggestion: > > > > * (Threat 1:) The proxy spoofs a response. For example, the > > proxy could return a stale or outdated response based on = data > > it previously obtained from the server or some fourth = party, or > > could craft an illicit response itself. > > >=20 > My problem with this is that I view a spoof as different. To me a = spoof > implies the attempt to create a new message that will pass muster as = oppose > to doing something like a replay. It would probably be better to use = a > different term. I'll try and remember to ponder on this. >=20 > Jim >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Mon Sep 19 13:15:47 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 B852B12B531; Mon, 19 Sep 2016 13:15:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147431614575.31081.5328815254419358470.idtracker@ietfa.amsl.com> Date: Mon, 19 Sep 2016 13:15:45 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-core-http-mapping-14=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 20:15:46 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-core-http-mapping-14: 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: ---------------------------------------------------------------------- Well written doc! Thanks! From nobody Mon Sep 26 02:46: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 9E12712B0D8 for ; Mon, 26 Sep 2016 02:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNjqrXaKDYXt for ; Mon, 26 Sep 2016 02:46:38 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AE912B0D5 for ; Mon, 26 Sep 2016 02:46:37 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-61-57e8ee7ab334 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id B9.AF.03250.A7EE8E75; Mon, 26 Sep 2016 11:46:36 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.3]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0301.000; Mon, 26 Sep 2016 11:46:34 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: Slot Requests for IETF97 Thread-Index: AQHSF9rdqok4pWPJQUO6+/Fp2AG7Rw== Date: Mon, 26 Sep 2016 09:46:33 +0000 Message-ID: <8AF03A29-8D06-4C84-AE47-84DE651FCBE4@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/signed; boundary="Apple-Mail=_809130EE-DF02-4444-B179-45F52D45D5A5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7jW7NuxfhBtOmCVrse7ue2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGV8efmcvaHSsuNPr2sA40baLkZNDQsBE4saStYwgtpDAekaJ S9czuxi5gOxFjBKrjt5iAkmwCThLfHrWyA5iiwioSbROesUGYgsLKEpsOvWfDSY+Ye0vZghb T+LNxT2sIDaLgKrE8vu/wRbwCthL7Pj7mQXEZhQQk/h+ag3YfGYBcYlbT+YzQRwkIvHw4mk2 CFtU4uXjf6wQtpLE2sPbWUCOYxaYwihxZcc0qKGCEidnPmGZwCg4C8msWcjqZiGpgyhKktj6 /SczhK0tsWzhayhbU2J/93IWTHENic5vE1khbFOJ10c/MkLY1hIzfh1kg7AVJaZ0P2RfwMi9 ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwug5u+W2wg/Hlc8dDjAIcjEo8vAk3nocLsSaW FVfmHmJUAZrzaMPqC4xSLHn5ealKIrxZb16EC/GmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/ XEggPbEkNTs1tSC1CCbLxMEp1cA4r+nL4Qtzjuzg36Nd+2Tb84Llq2zXLJdfm/t1tQqDmsC5 e3nvVvdmimbxpEp9uduzfsFB3Xz7mwpnnHYcqShSMnWedOdh0IfTgU9Up/KwrNHRVzZfYuCn JcCfHrNXXG7Co7XZyyQ7J6zsW5Xs+7fYyjd8P4P6t9WnHS6/Fjkye86DvL0h35N6lViKMxIN tZiLihMBFeXkl7YCAAA= Archived-At: Subject: [core] Slot Requests for 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: Mon, 26 Sep 2016 09:46:40 -0000 --Apple-Mail=_809130EE-DF02-4444-B179-45F52D45D5A5 Content-Type: multipart/alternative; boundary="Apple-Mail=_30C799E8-5795-418B-8213-1174A3E81794" --Apple-Mail=_30C799E8-5795-418B-8213-1174A3E81794 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, we would like to start thinking about the CoRE Session at IETF 97. For = that reason it would be very good if those interested in having a = presentation slot start requesting it already. The format should be = similar to this: draft-something-xxx Abstract: A couple of lines about the document or topic. Objective: Present an idea, get adoption, ask for feedback/reviewers/... Time: Ciao! - - Jaime Jim=C3=A9nez --Apple-Mail=_30C799E8-5795-418B-8213-1174A3E81794 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

we = would like to start thinking about the CoRE Session at IETF 97. For that = reason it would be very good if those interested in having a = presentation slot start requesting it already. The format should be = similar to this:

draft-something-xxx

Abstract: A couple of lines about the = document or topic.
Objective: Present an idea, get = adoption, ask for feedback/reviewers/...
Time:

Ciao!
- - Jaime Jim=C3=A9nez

= --Apple-Mail=_30C799E8-5795-418B-8213-1174A3E81794-- --Apple-Mail=_809130EE-DF02-4444-B179-45F52D45D5A5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MjYwOTQ2MzNaMCMGCSqGSIb3DQEJBDEWBBTg abk83GH2SufE8GuATb1zK5XPQjBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQDB41qSqJgAVDXxyG3x31qEKy8oWkx5FLInMtE6O7lYnYvevB/2soFOksyyf2YER+jgSLSEVM+L tYSTi2cN2qUqaedTNsCnqBVT8KlR7FKQQ/xEoZ9BxQop6yyxYjwP77KHtenkX/ZmSNgu/P4ftmPW VlNoWR+TFcD8UjlrAknzoZQhlEAe6rur8nmTbh5U4SnExVtAQuUlNUgN/LLGAA1kDiKr+ymlLEe+ 1nBU3lOAWJVTN0I61ZR37fqJBMB+cqD317dcu7Y61JalOnwPNZFMgmtUUywjMYaHNUxNtKcsAl5q lyAQzmlsAXZNd60+tcMROa/Xz0tnQJ5dZFT0o9iuAAAAAAAA --Apple-Mail=_809130EE-DF02-4444-B179-45F52D45D5A5-- From nobody Mon Sep 26 11:02:52 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 A1452128874; Mon, 26 Sep 2016 11:02:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147491296765.5016.11067016540200615437.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2016 11:02:47 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) 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, 26 Sep 2016 18:02:47 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-core-http-mapping-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is one discuss point with 2 questions. The second part is what's discussable and the first should be easy to fix either with the text provided or something similar. 1. In Section 10.1, this is more of a security than a privacy consideration as this is "network reconnaissance". This is a typical pre-cursor to an attack one the the attacker has gathered more information on the network. From a privacy perspective, they can be used to gather detailed information about the resources hosted in the constrained network. How about: This can be used to gather detailed information about the resources hosted in the constrained network, as siting with network reconnaissance. then for the last sentence: If privacy is a concern, for example whenever the HTTP request transits through the public Internet, the request SHOULD be transported over a mutually authenticated and encrypted TLS connection. How about: If confidentiality of the network is a concern, for example whenever the HTTP request transits through the public Internet, the request SHOULD be transported over a mutually authenticated and encrypted TLS connection. The word privacy here is confusing, so it's better to state exactly the issue. More importantly, if you can do network reconnaissance, what's to stop the attacker from using this new method of connecting? Some mention of this threat should be explicitly stated, maybe section 10.1 is the best place to do that, expanding on the existing text with another sentence. 2. (Really part of #1, but a separate point) Could transforms of URIs result in successful attacks? I would think that would be the highest security consideration. Although RFC7230 includes similar considerations, the mapping aspect of this draft could open up new attack possibilities, especially if a media type mapping is used. If there is an attack possible in the IoT space that is not in the HTTP world (device specific, or related to size constraints and coding), an intrusion prevention system monitoring the HTTP traffic before it is transformed would not pick it up and the attack traffic would evade detection. I think this merits mention and some text in the draft. Please let me know if it is elsewhere and another pointer is all that is needed. Thank you. From nobody Mon Sep 26 15:55: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 176F412B369; Mon, 26 Sep 2016 15:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y73Hyzh3Trdf; Mon, 26 Sep 2016 15:55:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2663A12B361; Mon, 26 Sep 2016 15:55:42 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id CFC311BEC2943; Mon, 26 Sep 2016 22:55:33 +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 u8QMtbYQ018576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2016 22:55:38 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u8QMtbdH022312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2016 00:55:37 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 00:55:37 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) Thread-Index: AQHSGCA01JuubfVt5EazajnwZxbPiqCMUSkA Date: Mon, 26 Sep 2016 22:55:37 +0000 Message-ID: References: <147491296765.5016.11067016540200615437.idtracker@ietfa.amsl.com> In-Reply-To: <147491296765.5016.11067016540200615437.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.6.8.160830 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <44012DB74E3BB0468E134B1F64649F96@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) 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, 26 Sep 2016 22:55:44 -0000 Hi Kathleen, Thanks very much for your comments! Some initial thoughts inlined. On 26/09/2016 19:02, "Kathleen Moriarty" wrote: >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >This is one discuss point with 2 questions. The second part is what's >discussable and the first should be easy to fix either with the text >provided or something similar. > >1. In Section 10.1, this is more of a security than a privacy >consideration as this is "network reconnaissance". This is a typical >pre-cursor to an attack one the the attacker has gathered more >information on the network. > > From a privacy perspective, they can be > used to gather detailed information about the resources hosted in the > constrained network. > >How about: > This can be > used to gather detailed information about the resources hosted in the > constrained network, as siting with network reconnaissance. > >then for the last sentence: > If privacy is a concern, for > example whenever the HTTP request transits through the public > Internet, the request SHOULD be transported over a mutually > authenticated and encrypted TLS connection. > >How about: > If confidentiality of the network is a concern, for > example whenever the HTTP request transits through the public > Internet, the request SHOULD be transported over a mutually > authenticated and encrypted TLS connection. > >The word privacy here is confusing, so it's better to state exactly the >issue. I guess the privacy issue we want to highlight here is that a query to /.well-known/core might return, for example, the inventory of someone's home appliances and devices. This might still be interesting information for an attacker that is not necessarily searching for vulnerabilities in the protocol stack of the fridge. Could you please suggest a better term than "privacy" to describe the concern above? BTW, your point about network reconnaissance is great and I'd like to incorporate your suggestion in section 10.1. >More importantly, if you can do network reconnaissance, what's to stop >the attacker from using this new method of connecting? Some mention of >this threat should be explicitly stated, maybe section 10.1 is the best >place to do that, expanding on the existing text with another sentence. Sorry, I don't understand what you mean by "what's to stop the attacker from using this new method of connecting?". >2. (Really part of #1, but a separate point) Could transforms of URIs >result in successful attacks? I would think that would be the highest >security consideration. Although RFC7230 includes similar >considerations, the mapping aspect of this draft could open up new attack >possibilities, especially if a media type mapping is used. If there is >an attack possible in the IoT space that is not in the HTTP world (device >specific, or related to size constraints and coding), an intrusion >prevention system monitoring the HTTP traffic before it is transformed >would not pick it up and the attack traffic would evade detection. I >think this merits mention and some text in the draft. Please let me know >if it is elsewhere and another pointer is all that is needed. Re: URI mapping. I can't see an obvious (or less obvious) way this could be an issue per se -- assuming the HTTP parser and the CoAP encoder are both correct (as discussed in the security considerations of RFC 7230 and RFC 7252). Re: Media mapping. The funnel has a disproportionately big mouth and a minuscule stem, allowing very few degrees of freedom: I might be wrong but it seems to me that the attack surface is virtually zero there. Are you thinking of the optional "loose" mapping defined in section 6.3 instead? (If so, the last paragraph of section 6.1 has text suggesting stricter access control if that feature is enabled. Is that enough? Should it be moved to the security considerations?) It's late and I certainly lack a bit of imagination (I can only think of issues deriving from buggy implementations, nothing that is intrinsic to the protocols' interactions). Do you have anything precise in mind? Cheers, thanks, t. From nobody Mon Sep 26 18:02: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 3DF9712B3A4; Mon, 26 Sep 2016 18:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 k0rnYFe5mVVC; Mon, 26 Sep 2016 18:02:07 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 3C1FC12B04D; Mon, 26 Sep 2016 18:02:07 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id u68so5358097uau.1; Mon, 26 Sep 2016 18:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7QMZGZt+ztqduJ0o16NcjAJnlvvU8ryXlt2hljju1ZE=; b=0VpeLHNIP0QOfvbH5BNopeXQ/Gx4z+aHBptRCHD1Zd7qudouIDEBt6LSIDPHecdIEi OMEsiFirIkIHSqL/duSFoIERhWVI97m1Ofdk0M4/Q0Ckc2NiMPD2GHfi2HCxJHGTqkLQ F/qkobEx1BAScGlJEHAM3O0HXZXBuKSkbH8yob8epNcmDJWScUCrgmhqBeahbkADugzU kA30yo3miH0ASHQgGnXuRze/LTg/OZkr0Fo3myoR+4/MJLluGCeydj6GUTc5ZB+DCz3W pvfFAclHsx71pzaQn2Sj/EE+D4ZZHKkyxu1eN+1pv9NGysRuaQ5xNyadW1fgpFmue/jL exaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7QMZGZt+ztqduJ0o16NcjAJnlvvU8ryXlt2hljju1ZE=; b=CY7AS2RtzetvuxWptumoB8niHEhS7fqfKiKZgmnvTc9oz+ahkCtGiTWp2uKMbIphEJ Dem568z08mzQ3KU9BUob353MSQX7ydmZflTkHMEP2exG++H3eBXavFAXoCpJZlWBm6u4 yet4zUlvgpj/98+9CJAjlahmknQNSbXOSdNF498nWuAdi8plTLrmG1cd+ocU/vTVCdc9 3aEURIMlz1sKmG9m9Zci6Om2ZsLXgJLFLHdANJXTVElZ7TCkw6Phowxtv8TqmfvQoA4P d+fngUnryI92cyhVZqYeNNjvtb/hWtGUnjLhPRMugSaHUWgM/0EoYP+9STp2UfA9gxTV YOPg== X-Gm-Message-State: AA6/9RlE2l2DsHZhVAOJHyEsr2xElIj1CSq2/B9Av35KDSLwdqmeBD77BYXAyZM6hzaC2jd9zb+JCRyEuqerAA== X-Received: by 10.176.6.233 with SMTP id g96mr1042545uag.135.1474938126327; Mon, 26 Sep 2016 18:02:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Mon, 26 Sep 2016 18:02:05 -0700 (PDT) In-Reply-To: References: <147491296765.5016.11067016540200615437.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Mon, 26 Sep 2016 21:02:05 -0400 Message-ID: To: "Fossati, Thomas (Nokia - GB)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) 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 Sep 2016 01:02:09 -0000 Hi Thomas, Thanks for your quick response, inline. On Mon, Sep 26, 2016 at 6:55 PM, Fossati, Thomas (Nokia - GB) wrote: > Hi Kathleen, > > Thanks very much for your comments! Some initial thoughts inlined. > > On 26/09/2016 19:02, "Kathleen Moriarty" > wrote: >>---------------------------------------------------------------------- >>DISCUSS: >>---------------------------------------------------------------------- >> >>This is one discuss point with 2 questions. The second part is what's >>discussable and the first should be easy to fix either with the text >>provided or something similar. >> >>1. In Section 10.1, this is more of a security than a privacy >>consideration as this is "network reconnaissance". This is a typical >>pre-cursor to an attack one the the attacker has gathered more >>information on the network. >> >> From a privacy perspective, they can be >> used to gather detailed information about the resources hosted in the >> constrained network. >> >>How about: >> This can be >> used to gather detailed information about the resources hosted in the >> constrained network, as siting with network reconnaissance. >> >>then for the last sentence: >> If privacy is a concern, for >> example whenever the HTTP request transits through the public >> Internet, the request SHOULD be transported over a mutually >> authenticated and encrypted TLS connection. >> >>How about: >> If confidentiality of the network is a concern, for >> example whenever the HTTP request transits through the public >> Internet, the request SHOULD be transported over a mutually >> authenticated and encrypted TLS connection. >> >>The word privacy here is confusing, so it's better to state exactly the >>issue. > > I guess the privacy issue we want to highlight here is that a query to > /.well-known/core might return, for example, the inventory of someone's > home appliances and devices. This might still be interesting information > for an attacker that is not necessarily searching for vulnerabilities in > the protocol stack of the fridge. > > Could you please suggest a better term than "privacy" to describe the > concern above? Oh, that point wasn't clear in the draft and is certainly a privacy consideration. What I read from the text was a network recon threat, which was about confidentiality of the network services - their existence and not privacy related information that could be discovered. As such, covering both threats would be best, but I would suggest you expand the current text to explain this threat. > > BTW, your point about network reconnaissance is great and I'd like to > incorporate your suggestion in section 10.1. > > >>More importantly, if you can do network reconnaissance, what's to stop >>the attacker from using this new method of connecting? Some mention of >>this threat should be explicitly stated, maybe section 10.1 is the best >>place to do that, expanding on the existing text with another sentence. > > Sorry, I don't understand what you mean by "what's to stop the attacker > from using this new method of connecting?". By new method, I mean that you now have a proxy to translate HTTP to COAP. You would not have been able to make such connections before. Could anything happen at the proxy when the traffic is proxied? > >>2. (Really part of #1, but a separate point) Could transforms of URIs >>result in successful attacks? I would think that would be the highest >>security consideration. Although RFC7230 includes similar >>considerations, the mapping aspect of this draft could open up new attack >>possibilities, especially if a media type mapping is used. If there is >>an attack possible in the IoT space that is not in the HTTP world (device >>specific, or related to size constraints and coding), an intrusion >>prevention system monitoring the HTTP traffic before it is transformed >>would not pick it up and the attack traffic would evade detection. I >>think this merits mention and some text in the draft. Please let me know >>if it is elsewhere and another pointer is all that is needed. > > Re: URI mapping. I can't see an obvious (or less obvious) way this could > be an issue per se -- assuming the HTTP parser and the CoAP encoder are > both correct (as discussed in the security considerations of RFC 7230 and > RFC 7252). > But could anything happen in that translation? If there is an exploit possible through a malformed URI, that isn't bad on one side of the translation, but is on the other? The pointer to the HTTP drafts is good, but I am still wondering if anything could happen and if there is a reason why this should also be called out as a consideration. The discussion just points to the HTTP security considerations, are there some for COAP? > Re: Media mapping. The funnel has a disproportionately big mouth and a > minuscule stem, allowing very few degrees of freedom: I might be wrong but > it seems to me that the attack surface is virtually zero there. Are you > thinking of the optional "loose" mapping defined in section 6.3 instead? I'm just wondering, and could be wrong (hence wanting t discuss it since this isn't explained in the draft as a consideration. I would think there would be some considerations related to proxying this content between 2 protocols. > (If so, the last paragraph of section 6.1 has text suggesting stricter > access control if that feature is enabled. Is that enough? Should it be > moved to the security considerations?) I'm also asking. Could there be code problems on the COAP enabled devices that could be exploited with malformed URIs? Is this covered in a COAP security consideration section somewhere and a pointer should be added? Am I way off base? > > It's late and I certainly lack a bit of imagination (I can only think of > issues deriving from buggy implementations, nothing that is intrinsic to > the protocols' interactions). Do you have anything precise in mind? Hmm, the HTTP draft covers malformed URIs that would only be an issue with a buggy implementation because this attack type is so common, so I was referring to an issue like this for COAP and wondering if there should be some warning text. The IoT space is so large and there are bound to be issues. If you out-of-scoped such issues, but said this could also be a problem with COAP, that would cover my concern. It is late, thanks for the discussion. I'd just like to make sure we aren't missing a warning that could be helpful. Thanks. > > Cheers, thanks, > t. > > > > -- Best regards, Kathleen From nobody Tue Sep 27 02:13: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 C460212B09D; Tue, 27 Sep 2016 02:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSt6n7It-Ux8; Tue, 27 Sep 2016 02:13:21 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC24912B0A9; Tue, 27 Sep 2016 02:13:20 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2D2A9A6BED8F0; Tue, 27 Sep 2016 09:13:17 +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 u8R9DIOn027745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2016 09:13:18 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u8R9D4oO010463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2016 11:13:18 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 11:13:10 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Kathleen Moriarty , "Fossati, Thomas (Nokia - GB)" Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) Thread-Index: AQHSGCA01JuubfVt5EazajnwZxbPiqCMUSkAgAASloCAAJn1gA== Date: Tue, 27 Sep 2016 09:13:09 +0000 Message-ID: References: <147491296765.5016.11067016540200615437.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B0C8A0E25A70D4A941CF00344063B4D@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) 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 Sep 2016 09:13:24 -0000 On 27/09/2016 02:02, "Kathleen Moriarty" wrote: >Hi Thomas, > >Thanks for your quick response, inline. > >On Mon, Sep 26, 2016 at 6:55 PM, Fossati, Thomas (Nokia - GB) > wrote: >> Hi Kathleen, >> >> Thanks very much for your comments! Some initial thoughts inlined. >> >> On 26/09/2016 19:02, "Kathleen Moriarty" >> wrote: >>>---------------------------------------------------------------------- >>>DISCUSS: >>>---------------------------------------------------------------------- >>> >>>This is one discuss point with 2 questions. The second part is what's >>>discussable and the first should be easy to fix either with the text >>>provided or something similar. >>> >>>1. In Section 10.1, this is more of a security than a privacy >>>consideration as this is "network reconnaissance". This is a typical >>>pre-cursor to an attack one the the attacker has gathered more >>>information on the network. >>> >>> From a privacy perspective, they can be >>> used to gather detailed information about the resources hosted in the >>> constrained network. >>> >>>How about: >>> This can be >>> used to gather detailed information about the resources hosted in the >>> constrained network, as siting with network reconnaissance. >>> >>>then for the last sentence: >>> If privacy is a concern, for >>> example whenever the HTTP request transits through the public >>> Internet, the request SHOULD be transported over a mutually >>> authenticated and encrypted TLS connection. >>> >>>How about: >>> If confidentiality of the network is a concern, for >>> example whenever the HTTP request transits through the public >>> Internet, the request SHOULD be transported over a mutually >>> authenticated and encrypted TLS connection. >>> >>>The word privacy here is confusing, so it's better to state exactly the >>>issue. >> >> I guess the privacy issue we want to highlight here is that a query to >> /.well-known/core might return, for example, the inventory of someone's >> home appliances and devices. This might still be interesting >>information >> for an attacker that is not necessarily searching for vulnerabilities in >> the protocol stack of the fridge. >> >> Could you please suggest a better term than "privacy" to describe the >> concern above? > >Oh, that point wasn't clear in the draft and is certainly a privacy >consideration. What I read from the text was a network recon threat, >which was about confidentiality of the network services - their >existence and not privacy related information that could be >discovered. As such, covering both threats would be best, but I would >suggest you expand the current text to explain this threat. OK. I'll expand the privacy concern to make it more clear, and add the network reconnaissance threat that you suggested as well. >> BTW, your point about network reconnaissance is great and I'd like to >> incorporate your suggestion in section 10.1. >> >> >>>More importantly, if you can do network reconnaissance, what's to stop >>>the attacker from using this new method of connecting? Some mention of >>>this threat should be explicitly stated, maybe section 10.1 is the best >>>place to do that, expanding on the existing text with another sentence. >> >> Sorry, I don't understand what you mean by "what's to stop the attacker >> from using this new method of connecting?". > >By new method, I mean that you now have a proxy to translate HTTP to >COAP. You would not have been able to make such connections before. >Could anything happen at the proxy when the traffic is proxied? > >> >>>2. (Really part of #1, but a separate point) Could transforms of URIs >>>result in successful attacks? I would think that would be the highest >>>security consideration. Although RFC7230 includes similar >>>considerations, the mapping aspect of this draft could open up new >>>attack >>>possibilities, especially if a media type mapping is used. If there is >>>an attack possible in the IoT space that is not in the HTTP world >>>(device >>>specific, or related to size constraints and coding), an intrusion >>>prevention system monitoring the HTTP traffic before it is transformed >>>would not pick it up and the attack traffic would evade detection. I >>>think this merits mention and some text in the draft. Please let me >>>know >>>if it is elsewhere and another pointer is all that is needed. >> >> Re: URI mapping. I can't see an obvious (or less obvious) way this >>could >> be an issue per se -- assuming the HTTP parser and the CoAP encoder are >> both correct (as discussed in the security considerations of RFC 7230 >>and >> RFC 7252). >> > >But could anything happen in that translation? If there is an exploit >possible through a malformed URI, that isn't bad on one side of the >translation, but is on the other? The pointer to the HTTP drafts is >good, but I am still wondering if anything could happen and if there >is a reason why this should also be called out as a consideration. The >discussion just points to the HTTP security considerations, are there >some for COAP? I think it's worth pointing out (at the very beginning of section 10) that the correctness of the request parsing, and in particular the URI translation process, is essential to the security of the HC proxy. We could refer to the relevant parts of CoAP and HTTP that already highlight this criticality (the request parsing caveats in section 9.3, 9.4, 9.5 and 9.6 of RFC7230 [1] and the bits related to URI parsing in [2]). The point to raise here, I think, is that the implementation quality of the HC proxy -- i.e. careful implementation and/or selection of the third party libraries, sane configuration defaults - is essential to the security of potentially *lots* of things on the constrained side. [1] https://tools.ietf.org/html/rfc7230#section-9 [2] https://tools.ietf.org/html/rfc7252#section-11.1 >> Re: Media mapping. The funnel has a disproportionately big mouth and a >> minuscule stem, allowing very few degrees of freedom: I might be wrong >>but >> it seems to me that the attack surface is virtually zero there. Are you >> thinking of the optional "loose" mapping defined in section 6.3 instead? > >I'm just wondering, and could be wrong (hence wanting t discuss it >since this isn't explained in the draft as a consideration. I would >think there would be some considerations related to proxying this >content between 2 protocols. > >> (If so, the last paragraph of section 6.1 has text suggesting stricter >> access control if that feature is enabled. Is that enough? Should it >>be >> moved to the security considerations?) > >I'm also asking. Could there be code problems on the COAP enabled >devices that could be exploited with malformed URIs? Is this covered >in a COAP security consideration section somewhere and a pointer >should be added? Am I way off base? No, you are certainly not off base, the threat is real. And the risk of the HC proxy becoming an integral part of the threat (rather than part of the solution) is factual given where it sits in the network. This needs to be clearly spelled out, probably as an argument that reinforces the need for the highest quality of implementation (see above). >> It's late and I certainly lack a bit of imagination (I can only think of >> issues deriving from buggy implementations, nothing that is intrinsic to >> the protocols' interactions). Do you have anything precise in mind? > >Hmm, the HTTP draft covers malformed URIs that would only be an issue >with a buggy implementation because this attack type is so common, so >I was referring to an issue like this for COAP and wondering if there >should be some warning text. The IoT space is so large and there are >bound to be issues. If you out-of-scoped such issues, but said this >could also be a problem with COAP, that would cover my concern. I agree. As per the warning text, I think this would be covered by the proposed text above re: QoImpl? >I'd just like to make sure we >aren't missing a warning that could be helpful. Sure, your comments are super helpful. Thanks again! (If you are OK with the rationale I'll go on and prepare a diff for you to look at.) Cheers, t From nobody Tue Sep 27 06:51:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079CC12B1C9; Tue, 27 Sep 2016 06:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sjtjOAxVPA76; Tue, 27 Sep 2016 06:51:03 -0700 (PDT) Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6B112B1CD; Tue, 27 Sep 2016 06:51:03 -0700 (PDT) Received: by mail-ua0-f179.google.com with SMTP id n13so11090643uaa.3; Tue, 27 Sep 2016 06:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UJ6pyo35IDlKr5yV9AE0EXvHhJDZNVSZGPNcsHTO/e4=; b=Q6kq7/nHdN8SP9tarea0lPzMG7b4Cxqq5DC0NmS7gQ/W92h7r7Ke7j1fiEl/FZ2mW5 zEZNGA7FB1jmiD5p7r/hPiYqgLsR/lKToclb7pXRlMMtkOEpbv/FJDIWxZKYqc0V00Q6 2yOEjeIeykySz65pV5B62c59e9ycw1SBfRJl1Ckj1//2WrjXU4hc+3mjvq7+Sf/dtQff /LLvnats1m/Ee9ik3UoaH8J5o5yW0BBeCiVqPCI+7F1kVfhxbDiDdt3rEU5kkfj/+ZkN WQ9YPaxYMXDZwty85cEkT4wq3Nao2t8g6Iah2sx5uSnVv5Utz1GfHcMAVTrnmI21GMuj KAQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UJ6pyo35IDlKr5yV9AE0EXvHhJDZNVSZGPNcsHTO/e4=; b=T8tXUcCquNjRrKe74zIeRULzYTBAdS/74yllxUmfAQDvhdAWKTlcgOwgNzkJmG1Qd/ sxhjqx2Syb0+R7keUoU5AAlhszcAypf4broKvx60daeXTR1ZciYLiNHlJigl7CH9ouBx 0QrIHr8HmkjTY5/j8gdqs9pcWrNF87Cx1RW+xnw47gzcU63FQ/0UNpd86B6owvwMROi2 lwBSSnlNfth2jEenvXpAtJMev/utWKDGTFf8TivR/gAuzcJZgOT2S8w13Ys5y/SrFM85 T80PGoSzT/bXav3eVAiCgTVB8AZ+XTJBV7XNWREylNvM/VXes0PLvbJaljunXOWjKkFz AgOQ== X-Gm-Message-State: AA6/9RkKZ3BwRAEHw0GKAydnr4ZLleJZhOHfTx8DUeFz7JDnzlGGi06dTYoZXo+FhgdCx1wLmFkUHIVU8stFHw== X-Received: by 10.176.83.222 with SMTP id l30mr2279636uaa.37.1474984202633; Tue, 27 Sep 2016 06:50:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Tue, 27 Sep 2016 06:50:01 -0700 (PDT) In-Reply-To: References: <147491296765.5016.11067016540200615437.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 27 Sep 2016 09:50:01 -0400 Message-ID: To: "Fossati, Thomas (Nokia - GB)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) 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 Sep 2016 13:51:07 -0000 Hi Thomas, On Tue, Sep 27, 2016 at 5:13 AM, Fossati, Thomas (Nokia - GB) wrote: > On 27/09/2016 02:02, "Kathleen Moriarty" > wrote: >>Hi Thomas, >> >>Thanks for your quick response, inline. >> >>On Mon, Sep 26, 2016 at 6:55 PM, Fossati, Thomas (Nokia - GB) >> wrote: >>> Hi Kathleen, >>> >>> Thanks very much for your comments! Some initial thoughts inlined. >>> >>> On 26/09/2016 19:02, "Kathleen Moriarty" >>> wrote: >>>>---------------------------------------------------------------------- >>>>DISCUSS: >>>>---------------------------------------------------------------------- >>>> >>>>This is one discuss point with 2 questions. The second part is what's >>>>discussable and the first should be easy to fix either with the text >>>>provided or something similar. >>>> >>>>1. In Section 10.1, this is more of a security than a privacy >>>>consideration as this is "network reconnaissance". This is a typical >>>>pre-cursor to an attack one the the attacker has gathered more >>>>information on the network. >>>> >>>> From a privacy perspective, they can be >>>> used to gather detailed information about the resources hosted in the >>>> constrained network. >>>> >>>>How about: >>>> This can be >>>> used to gather detailed information about the resources hosted in the >>>> constrained network, as siting with network reconnaissance. >>>> >>>>then for the last sentence: >>>> If privacy is a concern, for >>>> example whenever the HTTP request transits through the public >>>> Internet, the request SHOULD be transported over a mutually >>>> authenticated and encrypted TLS connection. >>>> >>>>How about: >>>> If confidentiality of the network is a concern, for >>>> example whenever the HTTP request transits through the public >>>> Internet, the request SHOULD be transported over a mutually >>>> authenticated and encrypted TLS connection. >>>> >>>>The word privacy here is confusing, so it's better to state exactly the >>>>issue. >>> >>> I guess the privacy issue we want to highlight here is that a query to >>> /.well-known/core might return, for example, the inventory of someone's >>> home appliances and devices. This might still be interesting >>>information >>> for an attacker that is not necessarily searching for vulnerabilities in >>> the protocol stack of the fridge. >>> >>> Could you please suggest a better term than "privacy" to describe the >>> concern above? >> >>Oh, that point wasn't clear in the draft and is certainly a privacy >>consideration. What I read from the text was a network recon threat, >>which was about confidentiality of the network services - their >>existence and not privacy related information that could be >>discovered. As such, covering both threats would be best, but I would >>suggest you expand the current text to explain this threat. > > OK. I'll expand the privacy concern to make it more clear, and add the > network reconnaissance threat that you suggested as well. > >>> BTW, your point about network reconnaissance is great and I'd like to >>> incorporate your suggestion in section 10.1. >>> >>> >>>>More importantly, if you can do network reconnaissance, what's to stop >>>>the attacker from using this new method of connecting? Some mention of >>>>this threat should be explicitly stated, maybe section 10.1 is the best >>>>place to do that, expanding on the existing text with another sentence. >>> >>> Sorry, I don't understand what you mean by "what's to stop the attacker >>> from using this new method of connecting?". >> >>By new method, I mean that you now have a proxy to translate HTTP to >>COAP. You would not have been able to make such connections before. >>Could anything happen at the proxy when the traffic is proxied? >> >>> >>>>2. (Really part of #1, but a separate point) Could transforms of URIs >>>>result in successful attacks? I would think that would be the highest >>>>security consideration. Although RFC7230 includes similar >>>>considerations, the mapping aspect of this draft could open up new >>>>attack >>>>possibilities, especially if a media type mapping is used. If there is >>>>an attack possible in the IoT space that is not in the HTTP world >>>>(device >>>>specific, or related to size constraints and coding), an intrusion >>>>prevention system monitoring the HTTP traffic before it is transformed >>>>would not pick it up and the attack traffic would evade detection. I >>>>think this merits mention and some text in the draft. Please let me >>>>know >>>>if it is elsewhere and another pointer is all that is needed. >>> >>> Re: URI mapping. I can't see an obvious (or less obvious) way this >>>could >>> be an issue per se -- assuming the HTTP parser and the CoAP encoder are >>> both correct (as discussed in the security considerations of RFC 7230 >>>and >>> RFC 7252). >>> >> >>But could anything happen in that translation? If there is an exploit >>possible through a malformed URI, that isn't bad on one side of the >>translation, but is on the other? The pointer to the HTTP drafts is >>good, but I am still wondering if anything could happen and if there >>is a reason why this should also be called out as a consideration. The >>discussion just points to the HTTP security considerations, are there >>some for COAP? > > I think it's worth pointing out (at the very beginning of section 10) that > the correctness of the request parsing, and in particular the URI > translation process, is essential to the security of the HC proxy. We > could refer to the relevant parts of CoAP and HTTP that already highlight > this criticality (the request parsing caveats in section 9.3, 9.4, 9.5 and > 9.6 of RFC7230 [1] and the bits related to URI parsing in [2]). The point > to raise here, I think, is that the implementation quality of the HC proxy > -- i.e. careful implementation and/or selection of the third party > libraries, sane configuration defaults - is essential to the security of > potentially *lots* of things on the constrained side. > > [1] https://tools.ietf.org/html/rfc7230#section-9 > [2] https://tools.ietf.org/html/rfc7252#section-11.1 > >>> Re: Media mapping. The funnel has a disproportionately big mouth and a >>> minuscule stem, allowing very few degrees of freedom: I might be wrong >>>but >>> it seems to me that the attack surface is virtually zero there. Are you >>> thinking of the optional "loose" mapping defined in section 6.3 instead? >> >>I'm just wondering, and could be wrong (hence wanting t discuss it >>since this isn't explained in the draft as a consideration. I would >>think there would be some considerations related to proxying this >>content between 2 protocols. >> >>> (If so, the last paragraph of section 6.1 has text suggesting stricter >>> access control if that feature is enabled. Is that enough? Should it >>>be >>> moved to the security considerations?) >> >>I'm also asking. Could there be code problems on the COAP enabled >>devices that could be exploited with malformed URIs? Is this covered >>in a COAP security consideration section somewhere and a pointer >>should be added? Am I way off base? > > No, you are certainly not off base, the threat is real. And the risk of > the HC proxy becoming an integral part of the threat (rather than part of > the solution) is factual given where it sits in the network. This needs > to be clearly spelled out, probably as an argument that reinforces the > need for the highest quality of implementation (see above). > >>> It's late and I certainly lack a bit of imagination (I can only think of >>> issues deriving from buggy implementations, nothing that is intrinsic to >>> the protocols' interactions). Do you have anything precise in mind? >> >>Hmm, the HTTP draft covers malformed URIs that would only be an issue >>with a buggy implementation because this attack type is so common, so >>I was referring to an issue like this for COAP and wondering if there >>should be some warning text. The IoT space is so large and there are >>bound to be issues. If you out-of-scoped such issues, but said this >>could also be a problem with COAP, that would cover my concern. > > I agree. As per the warning text, I think this would be covered by the > proposed text above re: QoImpl? > >>I'd just like to make sure we >>aren't missing a warning that could be helpful. > > Sure, your comments are super helpful. Thanks again! > > (If you are OK with the rationale I'll go on and prepare a diff for you to > look at.) Thank you, that would be great. I like the approach you are suggesting and appreciate you responding quickly with a good solution. > > Cheers, t > -- Best regards, Kathleen From nobody Tue Sep 27 07:56: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 8D66312B205; Tue, 27 Sep 2016 07:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_HTML_ATTACH=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 SqixqKyRj6Rz; Tue, 27 Sep 2016 07:56:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89A412B212; Tue, 27 Sep 2016 07:55:59 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9F9D85E80BAF0; Tue, 27 Sep 2016 14:55:54 +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 u8REtvBC017159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2016 14:55:57 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u8REtu01007723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2016 16:55:56 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 16:55:56 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Kathleen Moriarty , "Fossati, Thomas (Nokia - GB)" Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) Thread-Index: AQHSGCA01JuubfVt5EazajnwZxbPiqCMUSkAgAASloCAAJn1gIAAPJqAgAAjJwA= Date: Tue, 27 Sep 2016 14:55:56 +0000 Message-ID: References: <147491296765.5016.11067016540200615437.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-originating-ip: [135.239.27.40] Content-Type: multipart/mixed; boundary="_002_D41046A471468thomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) 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 Sep 2016 14:56:04 -0000 --_002_D41046A471468thomasfossatialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Kathleen, I have attached the diff. Let us know if it's OK. Cheers, thanks! On 27/09/2016 14:50, "Kathleen Moriarty" wrote: >Hi Thomas, > >On Tue, Sep 27, 2016 at 5:13 AM, Fossati, Thomas (Nokia - GB) > wrote: >> On 27/09/2016 02:02, "Kathleen Moriarty" >> wrote: >>>Hi Thomas, >>> >>>Thanks for your quick response, inline. >>> >>>On Mon, Sep 26, 2016 at 6:55 PM, Fossati, Thomas (Nokia - GB) >>> wrote: >>>> Hi Kathleen, >>>> >>>> Thanks very much for your comments! Some initial thoughts inlined. >>>> >>>> On 26/09/2016 19:02, "Kathleen Moriarty" >>>> wrote: >>>>>---------------------------------------------------------------------- >>>>>DISCUSS: >>>>>---------------------------------------------------------------------- >>>>> >>>>>This is one discuss point with 2 questions. The second part is what's >>>>>discussable and the first should be easy to fix either with the text >>>>>provided or something similar. >>>>> >>>>>1. In Section 10.1, this is more of a security than a privacy >>>>>consideration as this is "network reconnaissance". This is a typical >>>>>pre-cursor to an attack one the the attacker has gathered more >>>>>information on the network. >>>>> >>>>> From a privacy perspective, they can be >>>>> used to gather detailed information about the resources hosted in >>>>>the >>>>> constrained network. >>>>> >>>>>How about: >>>>> This can be >>>>> used to gather detailed information about the resources hosted in >>>>>the >>>>> constrained network, as siting with network reconnaissance. >>>>> >>>>>then for the last sentence: >>>>> If privacy is a concern, for >>>>> example whenever the HTTP request transits through the public >>>>> Internet, the request SHOULD be transported over a mutually >>>>> authenticated and encrypted TLS connection. >>>>> >>>>>How about: >>>>> If confidentiality of the network is a concern, for >>>>> example whenever the HTTP request transits through the public >>>>> Internet, the request SHOULD be transported over a mutually >>>>> authenticated and encrypted TLS connection. >>>>> >>>>>The word privacy here is confusing, so it's better to state exactly >>>>>the >>>>>issue. >>>> >>>> I guess the privacy issue we want to highlight here is that a query to >>>> /.well-known/core might return, for example, the inventory of >>>>someone's >>>> home appliances and devices. This might still be interesting >>>>information >>>> for an attacker that is not necessarily searching for vulnerabilities >>>>in >>>> the protocol stack of the fridge. >>>> >>>> Could you please suggest a better term than "privacy" to describe the >>>> concern above? >>> >>>Oh, that point wasn't clear in the draft and is certainly a privacy >>>consideration. What I read from the text was a network recon threat, >>>which was about confidentiality of the network services - their >>>existence and not privacy related information that could be >>>discovered. As such, covering both threats would be best, but I would >>>suggest you expand the current text to explain this threat. >> >> OK. I'll expand the privacy concern to make it more clear, and add the >> network reconnaissance threat that you suggested as well. >> >>>> BTW, your point about network reconnaissance is great and I'd like to >>>> incorporate your suggestion in section 10.1. >>>> >>>> >>>>>More importantly, if you can do network reconnaissance, what's to stop >>>>>the attacker from using this new method of connecting? Some mention >>>>>of >>>>>this threat should be explicitly stated, maybe section 10.1 is the >>>>>best >>>>>place to do that, expanding on the existing text with another >>>>>sentence. >>>> >>>> Sorry, I don't understand what you mean by "what's to stop the >>>>attacker >>>> from using this new method of connecting?". >>> >>>By new method, I mean that you now have a proxy to translate HTTP to >>>COAP. You would not have been able to make such connections before. >>>Could anything happen at the proxy when the traffic is proxied? >>> >>>> >>>>>2. (Really part of #1, but a separate point) Could transforms of URIs >>>>>result in successful attacks? I would think that would be the highest >>>>>security consideration. Although RFC7230 includes similar >>>>>considerations, the mapping aspect of this draft could open up new >>>>>attack >>>>>possibilities, especially if a media type mapping is used. If there >>>>>is >>>>>an attack possible in the IoT space that is not in the HTTP world >>>>>(device >>>>>specific, or related to size constraints and coding), an intrusion >>>>>prevention system monitoring the HTTP traffic before it is transformed >>>>>would not pick it up and the attack traffic would evade detection. I >>>>>think this merits mention and some text in the draft. Please let me >>>>>know >>>>>if it is elsewhere and another pointer is all that is needed. >>>> >>>> Re: URI mapping. I can't see an obvious (or less obvious) way this >>>>could >>>> be an issue per se -- assuming the HTTP parser and the CoAP encoder >>>>are >>>> both correct (as discussed in the security considerations of RFC 7230 >>>>and >>>> RFC 7252). >>>> >>> >>>But could anything happen in that translation? If there is an exploit >>>possible through a malformed URI, that isn't bad on one side of the >>>translation, but is on the other? The pointer to the HTTP drafts is >>>good, but I am still wondering if anything could happen and if there >>>is a reason why this should also be called out as a consideration. The >>>discussion just points to the HTTP security considerations, are there >>>some for COAP? >> >> I think it's worth pointing out (at the very beginning of section 10) >>that >> the correctness of the request parsing, and in particular the URI >> translation process, is essential to the security of the HC proxy. We >> could refer to the relevant parts of CoAP and HTTP that already >>highlight >> this criticality (the request parsing caveats in section 9.3, 9.4, 9.5 >>and >> 9.6 of RFC7230 [1] and the bits related to URI parsing in [2]). The >>point >> to raise here, I think, is that the implementation quality of the HC >>proxy >> -- i.e. careful implementation and/or selection of the third party >> libraries, sane configuration defaults - is essential to the security of >> potentially *lots* of things on the constrained side. >> >> [1] https://tools.ietf.org/html/rfc7230#section-9 >> [2] https://tools.ietf.org/html/rfc7252#section-11.1 >> >>>> Re: Media mapping. The funnel has a disproportionately big mouth and >>>>a >>>> minuscule stem, allowing very few degrees of freedom: I might be wrong >>>>but >>>> it seems to me that the attack surface is virtually zero there. Are >>>>you >>>> thinking of the optional "loose" mapping defined in section 6.3 >>>>instead? >>> >>>I'm just wondering, and could be wrong (hence wanting t discuss it >>>since this isn't explained in the draft as a consideration. I would >>>think there would be some considerations related to proxying this >>>content between 2 protocols. >>> >>>> (If so, the last paragraph of section 6.1 has text suggesting stricter >>>> access control if that feature is enabled. Is that enough? Should it >>>>be >>>> moved to the security considerations?) >>> >>>I'm also asking. Could there be code problems on the COAP enabled >>>devices that could be exploited with malformed URIs? Is this covered >>>in a COAP security consideration section somewhere and a pointer >>>should be added? Am I way off base? >> >> No, you are certainly not off base, the threat is real. And the risk of >> the HC proxy becoming an integral part of the threat (rather than part >>of >> the solution) is factual given where it sits in the network. This needs >> to be clearly spelled out, probably as an argument that reinforces the >> need for the highest quality of implementation (see above). >> >>>> It's late and I certainly lack a bit of imagination (I can only think >>>>of >>>> issues deriving from buggy implementations, nothing that is intrinsic >>>>to >>>> the protocols' interactions). Do you have anything precise in mind? >>> >>>Hmm, the HTTP draft covers malformed URIs that would only be an issue >>>with a buggy implementation because this attack type is so common, so >>>I was referring to an issue like this for COAP and wondering if there >>>should be some warning text. The IoT space is so large and there are >>>bound to be issues. If you out-of-scoped such issues, but said this >>>could also be a problem with COAP, that would cover my concern. >> >> I agree. As per the warning text, I think this would be covered by the >> proposed text above re: QoImpl? >> >>>I'd just like to make sure we >>>aren't missing a warning that could be helpful. >> >> Sure, your comments are super helpful. Thanks again! >> >> (If you are OK with the rationale I'll go on and prepare a diff for you >>to >> look at.) > >Thank you, that would be great. I like the approach you are >suggesting and appreciate you responding quickly with a good solution. > >> >> Cheers, t >> > > > >--=20 > >Best regards, >Kathleen > --_002_D41046A471468thomasfossatialcatellucentcom_ Content-Type: text/html; name="draft-ietf-core-http-mapping-15-from-4.diff.html" Content-Description: draft-ietf-core-http-mapping-15-from-4.diff.html Content-Disposition: attachment; filename="draft-ietf-core-http-mapping-15-from-4.diff.html"; size=48230; creation-date="Tue, 27 Sep 2016 14:55:56 GMT"; modification-date="Tue, 27 Sep 2016 14:55:56 GMT" Content-ID: <6E36F3E3769B7B458316BB4947384946@exchange.lucent.com> Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQyOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogRGFyd2luIGJvbmdvIDE0LjUuMCBEYXJ3aW4gS2VybmVs IFZlcnNpb24gMTQuNS4wOiBUaHUgSnVuIDE2IDE5OjU4OjIxIFBEVCAyMDE2OyByb290OnhudS0y NzgyLjUwLjR+MS9SRUxFQVNFX1g4Nl82NCB4ODZfNjQgLS0+IAo8IS0tIFVzaW5nIGF3azogL3Vz ci9sb2NhbC9iaW4vZ2F3azogR05VIEF3ayA0LjEuMSwgQVBJOiAxLjEgLS0+IAo8IS0tIFVzaW5n IGRpZmY6IC91c3IvYmluL2RpZmY6IGRpZmYgKEdOVSBkaWZmdXRpbHMpIDIuOC4xIC0tPiAKPCEt LSBVc2luZyB3ZGlmZjogL3Vzci9sb2NhbC9iaW4vd2RpZmY6IHdkaWZmIChHTlUgd2RpZmYpIDEu Mi4yIC0tPiAKPGh0bWw+IAo8aGVhZD4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSIgLz4gCiAgPG1ldGEgaHR0 cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyIgLz4gCiAgPHRp dGxlPkRpZmY6IGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMTQudHh0IC0gZHJhZnQtaWV0 Zi1jb3JlLWh0dHAtbWFwcGluZy0xNS50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0idGV4dC9j c3MiPiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1dG87IH0g CiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1zcGFjZTogcHJlOyBmb250LWZh bWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXNpemU6IDAuODZlbTt9 IAogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNtYWxsICB7IGZvbnQt c2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RUVFOyB9IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAgICAuZGlm ZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0g CiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjQUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6 ICNGRkI7IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5s aW5lYnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNvbG9yOiBy ZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246 IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9y OiAjQUFBOyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREREOyB9IAog ICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5sYmxvY2sg LmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29udCB7IGJh Y2tncm91bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEFE OyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91bmQtY29sb3I6 ICNFRUU7IHBhZGRpbmc6IDJweCAwOyB9IAogIDwvc3R5bGU+IAo8L2hlYWQ+IAo8Ym9keSA+IAog IDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0 ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRmLWNvcmUtaHR0 cC1tYXBwaW5nLTE0LnR4dCZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRm LWNvcmUtaHR0cC1tYXBwaW5nLTE1LnR4dCZuYnNwOzwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29SRSBXb3JraW5nIEdyb3VwICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBDYXN0ZWxsYW5pPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29SRSBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBDYXN0ZWxsYW5pPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2ZXJzaXR5IG9mIFBhZG92YTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBVbml2ZXJzaXR5IG9mIFBhZG92YTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6 IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBMb3JldG88 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0 aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBMb3JldG88L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDAxIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczogTWFyY2ggPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+MTI8L3NwYW4+LCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBFcmljc3NvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5F eHBpcmVzOiBNYXJjaCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4zMTwvc3Bhbj4sIDIwMTcgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIFJhaG1hbjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIFJhaG1hbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSW50ZXJEaWdpdGFsIENvbW11bmljYXRpb25zLCBM TEM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSW50ZXJEaWdpdGFsIENvbW11bmljYXRpb25zLCBMTEM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULiBG b3NzYXRpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULiBGb3NzYXRpPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOb2tpYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb2tp YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEUuIERpams8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUu IERpams8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBQaGlsaXBzIExpZ2h0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsaXBz IExpZ2h0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPiBTZXB0ZW1iZXIgODwvc3Bhbj4sIDIwMTY8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+U2VwdGVtYmVyIDI3PC9zcGFuPiwg MjAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgIEd1aWRlbGluZXMgZm9y IEhUVFAtdG8tQ29BUCBNYXBwaW5nIEltcGxlbWVudGF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICBHdWlkZWxpbmVzIGZvciBIVFRQLXRvLUNvQVAgTWFwcGlu ZyBJbXBsZW1lbnRhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAzIiAvPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTE8 c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMTxz cGFuIGNsYXNzPSJpbnNlcnQiPjU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5B YnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHJlZmVyZW5jZSBp bmZvcm1hdGlvbiBmb3IgaW1wbGVtZW50aW5nIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHJlZmVyZW5jZSBpbmZvcm1hdGlvbiBmb3Ig aW1wbGVtZW50aW5nIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgY3Jvc3MtcHJvdG9jb2wgbmV0d29yayBwcm94eSB0aGF0IHBlcmZvcm1z IHRyYW5zbGF0aW9uIGZyb20gdGhlIEhUVFA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBjcm9zcy1wcm90b2NvbCBuZXR3b3JrIHByb3h5IHRoYXQgcGVyZm9ybXMgdHJhbnNsYXRp b24gZnJvbSB0aGUgSFRUUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBwcm90b2NvbCB0byBDb0FQIChDb25zdHJhaW5lZCBBcHBsaWNhdGlv biBQcm90b2NvbCkuICBUaGlzIHdpbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBwcm90b2NvbCB0byBDb0FQIChDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCkuICBU aGlzIHdpbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgZW5hYmxlIGEgSFRUUCBjbGllbnQgdG8gYWNjZXNzIHJlc291cmNlcyBvbiBhIENv QVAgc2VydmVyIHRocm91Z2ggdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ZW5hYmxlIGEgSFRUUCBjbGllbnQgdG8gYWNjZXNzIHJlc291cmNlcyBvbiBhIENvQVAgc2VydmVy IHRocm91Z2ggdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHByb3h5LiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSFRUUCBy ZXF1ZXN0IGlzIG1hcHBlZCB0byBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg cHJveHkuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYSBIVFRQIHJlcXVlc3QgaXMgbWFw cGVkIHRvIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgQ29BUCByZXF1ZXN0LCBhbmQgdGhlbiBob3cgYSBDb0FQIHJlc3BvbnNlIGlzIG1h cHBlZCBiYWNrIHRvIGEgSFRUUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENv QVAgcmVxdWVzdCwgYW5kIHRoZW4gaG93IGEgQ29BUCByZXNwb25zZSBpcyBtYXBwZWQgYmFjayB0 byBhIEhUVFA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgcmVzcG9uc2UuICBUaGlzIGluY2x1ZGVzIGd1aWRlbGluZXMgZm9yIFVSSSBtYXBw aW5nLCBtZWRpYSB0eXBlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVzcG9u c2UuICBUaGlzIGluY2x1ZGVzIGd1aWRlbGluZXMgZm9yIFVSSSBtYXBwaW5nLCBtZWRpYSB0eXBl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwyIiAvPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5lIDQ2PC9l bT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMiIgLz48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMSwgbGluZSA0NjwvZW0+PC90aD48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRh c2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1 cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRHJhZnRzIGlzIGF0IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr IGluIHByb2dyZXNzLiI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDQiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1hcmNo IDxzcGFuIGNsYXNzPSJkZWxldGUiPjEyPC9zcGFuPiwgMjAxNy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXJj aCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4zMTwvc3Bhbj4sIDIwMTcuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJp Z2h0IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29weXJpZ2h0IChjKSAyMDE2IElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVu dHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRo ZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXki ID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hh bmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMywgbGluZSA5PC9lbT48L3RoPjx0aD4gPC90aD48dGg+ PGEgbmFtZT0icGFydC1yMyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48 ZW0+IHBhZ2UgMywgbGluZSA5PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDgu MS4gIENhY2hpbmcgYW5kIENvbmdlc3Rpb24gQ29udHJvbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMjM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDguMS4gIENhY2hp bmcgYW5kIENvbmdlc3Rpb24gQ29udHJvbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICA4LjIuICBDYWNoZSBSZWZyZXNoIHZpYSBPYnNlcnZlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDIzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA4LjIuICBD YWNoZSBSZWZyZXNoIHZpYSBPYnNlcnZlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDIzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgOC4zLiAgVXNlIG9mIENvQVAgQmxvY2t3aXNlIFRyYW5zZmVyICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAyNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgOC4z LiAgVXNlIG9mIENvQVAgQmxvY2t3aXNlIFRyYW5zZmVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAyNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgIDguNC4gIENvQVAgTXVsdGljYXN0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg IDguNC4gIENvQVAgTXVsdGljYXN0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICA4LjUuICBUaW1lb3V0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICA4LjUuICBUaW1lb3V0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDI1PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA5LiAgSUFOQSBD b25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MjU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA5LiAgSUFOQSBDb25zaWRlcmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA5LjEu ICBOZXcgJ2NvcmUuaGMnIFJlc291cmNlIFR5cGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDI1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA5LjEuICBOZXcgJ2Nv cmUuaGMnIFJlc291cmNlIFR5cGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg OS4yLiAgTmV3ICdjb2FwLXBheWxvYWQnIEludGVybmV0IE1lZGlhIFR5cGUgIC4gLiAuIC4gLiAu IC4gLiAuICAyNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgOS4yLiAgTmV3 ICdjb2FwLXBheWxvYWQnIEludGVybmV0IE1lZGlhIFR5cGUgIC4gLiAuIC4gLiAuIC4gLiAuICAy NjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAxMC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMjc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxMC4gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMjc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAx MC4xLiAgTXVsdGljYXN0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDI8c3BhbiBjbGFzcz0iZGVsZXRlIj43PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgIDEwLjEuICBNdWx0aWNhc3QgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgMTAuMi4gIFRyYWZmaWMgT3ZlcmZsb3cgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAyODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMTAuMi4g IFRyYWZmaWMgT3ZlcmZsb3cgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAyODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDEw LjMuICBIYW5kbGluZyBTZWN1cmVkIEV4Y2hhbmdlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMjxzcGFuIGNsYXNzPSJkZWxldGUiPjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgICAgMTAuMy4gIEhhbmRsaW5nIFNlY3VyZWQgRXhjaGFuZ2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAxMC40LiAgVVJJIE1hcHBpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDI5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAxMC40LiAg VVJJIE1hcHBpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDI5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDExLiBB Y2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4yOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgMTEuIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjMwPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAx Mi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMzA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxMi4gUmVmZXJl bmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MzA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDMwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAxMi4x LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMwPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgMTIuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAzMTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg MTIuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMzI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMzI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDM2PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLiAgSW50cm9k dWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4gIEludHJvZHVjdGlvbjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29BUCAoQ29uc3RyYWluZWQgQXBwbGljYXRp b24gUHJvdG9jb2wpIFtSRkM3MjUyXSBoYXMgYmVlbiBkZXNpZ25lZDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIENvQVAgKENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29s KSBbUkZDNzI1Ml0gaGFzIGJlZW4gZGVzaWduZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2l0aCB0aGUgdHdvZm9sZCBhaW0gdG8gYmUg YW4gYXBwbGljYXRpb24gcHJvdG9jb2wgc3BlY2lhbGl6ZWQgZm9yPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgd2l0aCB0aGUgdHdvZm9sZCBhaW0gdG8gYmUgYW4gYXBwbGljYXRp b24gcHJvdG9jb2wgc3BlY2lhbGl6ZWQgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3Rk Pjx0aD48YSBuYW1lPSJwYXJ0LWw0IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxlbT4gcGFnZSAyNywgbGluZSA0MDwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9 InBhcnQtcjQiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdl IDI3LCBsaW5lIDQwPC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNlY3VyaXR5IGNvbmNlcm5zIHJhaXNlZCBpbiBTZWN0 aW9uIDkuMiBvZiBbUkZDNzIzMF0gYWxzbyBhcHBseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoZSBzZWN1cml0eSBjb25jZXJucyByYWlzZWQgaW4gU2VjdGlvbiA5LjIgb2Yg W1JGQzcyMzBdIGFsc28gYXBwbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgdG8gdGhlIEhDIHByb3h5IHNjZW5hcmlvLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHRoZSBIQyBwcm94eSBzY2VuYXJpby48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEgSEMgcHJveHkgZGVwbG95ZWQgYXQgdGhlIGJvdW5k YXJ5IG9mIGEgY29uc3RyYWluZWQgbmV0d29yayBpcyBhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIEEgSEMgcHJveHkgZGVwbG95ZWQgYXQgdGhlIGJvdW5kYXJ5IG9mIGEgY29u c3RyYWluZWQgbmV0d29yayBpcyBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBlYXN5IHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlIGZvciBy ZWR1Y2luZyBhdmFpbGFiaWxpdHkuICBBcyBzdWNoLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGVhc3kgc2luZ2xlIHBvaW50IG9mIGZhaWx1cmUgZm9yIHJlZHVjaW5nIGF2YWls YWJpbGl0eS4gIEFzIHN1Y2gsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpYWwgY2FyZSBzaG91bGQgYmUgdGFrZW4gaW4gZGVzaWdu aW5nLCBkZXZlbG9waW5nIGFuZCBvcGVyYXRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBzcGVjaWFsIGNhcmUgc2hvdWxkIGJlIHRha2VuIGluIGRlc2lnbmluZywgZGV2ZWxv cGluZyBhbmQgb3BlcmF0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGl0LCBrZWVwaW5nIGluIG1pbmQgdGhhdCwgaW4gbW9zdCBjYXNl cywgaXQgaGFzIGZld2VyIGxpbWl0YXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgaXQsIGtlZXBpbmcgaW4gbWluZCB0aGF0LCBpbiBtb3N0IGNhc2VzLCBpdCBoYXMgZmV3 ZXIgbGltaXRhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgdGhhbiB0aGUgY29uc3RyYWluZWQgZGV2aWNlcyBpdCBpcyBzZXJ2aW5n LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoYW4gdGhlIGNvbnN0cmFpbmVk IGRldmljZXMgaXQgaXMgc2VydmluZy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAwOCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGUgY29ycmVjdG5l c3Mgb2YgdGhlIHJlcXVlc3QgcGFyc2luZyBpbiBnZW5lcmFsLCBhbmQgb2YgdGhlIFVSSTwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgdHJhbnNsYXRpb24gcHJvY2VzcyBpbiBwYXJ0aWN1bGFyLCBpcyBlc3NlbnRpYWwgdG8gdGhl IHNlY3VyaXR5IG9mPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICB0aGUgSEMgcHJveHkgZnVuY3Rpb24uICBUaGlzIGlzIGVzcGVj aWFsbHkgdHJ1ZSB3aGVuIHRoZSBpbnRlcm5hbDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbmV0d29yayBob3N0cyBkZXZpY2Vz IHdpdGggZ2VudWluZWx5IGxpbWl0ZWQgY2FwYWJpbGl0aWVzLiAgVGhlPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBxdWFsaXR5 IG9mIGltcGxlbWVudGF0aW9uIGFuZCBvcGVyYXRpb24gLS0gaS5lLiwgY2FyZWZ1bDwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg aW1wbGVtZW50YXRpb24gYW5kL29yIHNlbGVjdGlvbiBvZiB0aGUgdGhpcmQgcGFydHkgbGlicmFy aWVzLCBzYW5lPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBjb25maWd1cmF0aW9uIGRlZmF1bHRzLCBhbiBleHBlZGl0ZSB3YXkg dG8gdXBncmFkZSBhIHJ1bm5pbmc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGluc3RhbmNlLCBldGMuIC0gaXMgdGhlcmVmb3Jl IGFuIGVzc2VudGlhbCBhdHRyaWJ1dGUgb2YgdGhlIEhDIHByb3h5Ljwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgRm9yIHRoaXMg cHVycG9zZSwgc2VlIGFsc28gU2VjdGlvbnMgOS4zLCA5LjQsIDkuNSBhbmQgOS42IG9mPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBbUkZDNzIzMF0gZm9yIHdlbGwga25vd24gaXNzdWVzIHJlbGF0ZWQgdG8gSFRUUCByZXF1ZXN0 IHBhcnNpbmcsIGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgc2VjdGlvbiAxMS4xIG9mIFtSRkM3MjUyXSBmb3IgYW4gb3Zl cnZpZXcgb2YgQ29BUCBzcGVjaWZpYyBjb25jZXJuczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgcmVsYXRlZCB0byBVUkkgcHJv Y2Vzc2luZyAtLSBpbiBwYXJ0aWN1bGFyIHRoZSBwb3RlbnRpYWwgZmFsbC1vdXQgb248L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IGFjY2VzcyBjb250cm9sIGxvZ2ljcy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGZvbGxvd2luZyBzdWIgcGFyYWdyYXBocyBjYXRl Z29yaXplIGFuZCBkaXNjdXNzIGEgc2V0IG9mIHNwZWNpZmljPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhlIGZvbGxvd2luZyBzdWIgcGFyYWdyYXBocyBjYXRlZ29yaXplIGFu ZCBkaXNjdXNzIGEgc2V0IG9mIHNwZWNpZmljPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlY3VyaXR5IGlzc3VlcyByZWxhdGVkIHRvIHRo ZSB0cmFuc2xhdGlvbiwgY2FjaGluZyBhbmQgZm9yd2FyZGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHNlY3VyaXR5IGlzc3VlcyByZWxhdGVkIHRvIHRoZSB0cmFuc2xhdGlv biwgY2FjaGluZyBhbmQgZm9yd2FyZGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmdW5jdGlvbmFsaXR5IGV4cG9zZWQgYnkgYSBIQyBw cm94eS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmdW5jdGlvbmFsaXR5IGV4 cG9zZWQgYnkgYSBIQyBwcm94eS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEwLjEuICBN dWx0aWNhc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMC4xLiAgTXVsdGljYXN0 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDkiIC8+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBNdWx0aWNhc3QgcmVxdWVzdHMgaW1wb3NlIGEgbm9uPHNw YW4gY2xhc3M9ImRlbGV0ZSI+IDwvc3Bhbj50cml2aWFsIGNvc3Qgb24gdGhlIGNvbnN0cmFpbmVk PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIE11bHRpY2FzdCByZXF1ZXN0cyBp bXBvc2UgYSBub248c3BhbiBjbGFzcz0iaW5zZXJ0Ij4tPC9zcGFuPnRyaXZpYWwgY29zdCBvbiB0 aGUgY29uc3RyYWluZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbmV0d29yayBhbmQgZW5kcG9pbnRzLCBhbmQgbWlnaHQgYmUgZXhwbG9p dGVkIGFzIGEgRG9TIGF0dGFjayB2ZWN0b3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBuZXR3b3JrIGFuZCBlbmRwb2ludHMsIGFuZCBtaWdodCBiZSBleHBsb2l0ZWQgYXMgYSBE b1MgYXR0YWNrIHZlY3RvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAoc2VlIGFsc28gU2VjdGlvbiAxMC4yKS4gIEZyb20gYSBwcml2YWN5 IHBlcnNwZWN0aXZlLCB0aGV5IGNhbiBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIChzZWUgYWxzbyBTZWN0aW9uIDEwLjIpLiAgRnJvbSBhIHByaXZhY3kgcGVyc3BlY3RpdmUs IHRoZXkgY2FuIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHVzZWQgdG8gZ2F0aGVyIGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0IHRo ZSByZXNvdXJjZXMgaG9zdGVkIGluIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHVzZWQgdG8gZ2F0aGVyIGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZXNvdXJj ZXMgaG9zdGVkIGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTAiIC8+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBjb25zdHJhaW5lZCBuZXR3b3JrLiAgRm9yIHRoZXNlIHJlYXNvbnMsIGl0IGlzIFJF Q09NTUVOREVEIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgY29uc3Ry YWluZWQgbmV0d29yay4gIEZvciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5leGFtcGxlLCBhbiBvdXRz aWRlciB0aGF0IGlzIGFibGUgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmVxdWVzdHMgdG8gbXVsdGljYXN0IHJlc291 cmNlcyBhcmUgYWNjZXNzIGNvbnRyb2xsZWQgd2l0aCBhIDxzcGFuIGNsYXNzPSJkZWxldGUiPmRl ZmF1bHQtPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICBzdWNjZXNzZnVsbHkgcXVlcnkgdGhlIC8ud2VsbC1rbm93bi9jb3JlIGNv dWxkIG9idGFpbiBhIGNvbXByZWhlbnNpdmU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg ZGVueTwvc3Bhbj4gcG9saWN5LiAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgcmVxdWVzdG9y IG9mIGEgbXVsdGljYXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIGxpc3Qgb2YgdGhlIHRhcmdldCdzIGhvbWUgYXBwbGlhbmNlcyBhbmQg ZGV2aWNlcy4gIEZyb20gYSBzZWN1cml0eTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByZXNvdXJjZSA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5pczwvc3Bhbj4gc3Ryb25nbHkgYXV0aGVudGljYXRlZC4gIElmIHByaXZhY3kgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+aXMgYSBjb25jZXJuLDwvc3Bhbj4gZm9yPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHBlcnNwZWN0aXZlLCB0 aGV5IGNvdWxkIGJlIHVzZWQgdG8gY2Fycnkgb3V0IGEgbmV0d29yayByZWNvbm5haXNzYW5jZTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBleGFtcGxlIHdoZW5ldmVyIHRoZSBIVFRQIHJlcXVlc3QgdHJhbnNpdHMgdGhyb3Vn aCB0aGUgcHVibGljPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIGF0dGFjayB0byBnYXRoZXIgaW5mb3JtYXRpb24gYWJvdXQgcG9zc2libGUg dnVsbmVyYWJpbGl0aWVzIHRoYXQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgSW50ZXJuZXQsIHRoZSByZXF1ZXN0IFNIT1VM RCBiZSB0cmFuc3BvcnRlZCBvdmVyIGEgbXV0dWFsbHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgY291bGQgYmUgZXhwbG9pdGVkIGF0IGEg bGF0ZXIgcG9pbnQgaW4gdGltZS4gIEZvcjwvc3Bhbj4gdGhlc2UgcmVhc29ucywgaXQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhdXRo ZW50aWNhdGVkIGFuZCBlbmNyeXB0ZWQgVExTIGNvbm5lY3Rpb24uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIGlzIFJFQ09NTUVOREVEIHRoYXQgcmVxdWVzdHMgdG8gbXVsdGlj YXN0IHJlc291cmNlcyBhcmUgYWNjZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIGNvbnRyb2xsZWQgd2l0aCBhIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRlZmF1bHQtZGVueTwv c3Bhbj4gcG9saWN5LiAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgcmVxdWVzdG9yIG9mIGEgbXVsdGljYXN0IHJlc291cmNlIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmJlPC9zcGFuPiBzdHJvbmdseSBhdXRoZW50aWNhdGVkLiAgSWY8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcHJpdmFjeSA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5hbmQgLyBvciBzZWN1cml0eSBhcmUgZmlyc3QgY2xhc3MgcmVxdWlyZW1lbnRzLDwv c3Bhbj4gZm9yIGV4YW1wbGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgd2hl bmV2ZXIgdGhlIEhUVFAgcmVxdWVzdCB0cmFuc2l0cyB0aHJvdWdoIHRoZSBwdWJsaWMgSW50ZXJu ZXQsIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICByZXF1ZXN0IFNIT1VM RCBiZSB0cmFuc3BvcnRlZCBvdmVyIGEgbXV0dWFsbHkgYXV0aGVudGljYXRlZCBhbmQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZW5jcnlwdGVkIFRMUyBjb25uZWN0aW9uLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MTAuMi4gIFRyYWZmaWMgT3ZlcmZsb3c8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMC4yLiAgVHJhZmZpYyBPdmVyZmxvdzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRHVlIHRvIHRoZSB0eXBpY2FsbHkgY29uc3RyYWluZWQg bmF0dXJlIG9mIENvQVAgbm9kZXMsIHBhcnRpY3VsYXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBEdWUgdG8gdGhlIHR5cGljYWxseSBjb25zdHJhaW5lZCBuYXR1cmUgb2YgQ29B UCBub2RlcywgcGFydGljdWxhcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBhdHRlbnRpb24gc2hvdWxkIGJlIGdpdmVuIHRvIHRoZSBpbXBs ZW1lbnRhdGlvbiBvZiB0cmFmZmljIHJlZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGF0dGVudGlvbiBzaG91bGQgYmUgZ2l2ZW4gdG8gdGhlIGltcGxlbWVudGF0aW9u IG9mIHRyYWZmaWMgcmVkdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1lY2hhbmlzbXMgKHNlZSBTZWN0aW9uIDguMSksIGJlY2F1 c2UgaW5lZmZpY2llbnQgcHJveHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBt ZWNoYW5pc21zIChzZWUgU2VjdGlvbiA4LjEpLCBiZWNhdXNlIGluZWZmaWNpZW50IHByb3h5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlt cGxlbWVudGF0aW9ucyBjYW4gYmUgdGFyZ2V0ZWQgYnkgdW5jb25zdHJhaW5lZCBJbnRlcm5ldCBh dHRhY2tlcnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW1wbGVtZW50YXRp b25zIGNhbiBiZSB0YXJnZXRlZCBieSB1bmNvbnN0cmFpbmVkIEludGVybmV0IGF0dGFja2Vycy48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg QmFuZHdpZHRoIG9yIGNvbXBsZXhpdHkgaW52b2x2ZWQgaW4gc3VjaCBhdHRhY2tzIGlzIHZlcnkg bG93LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJhbmR3aWR0aCBvciBjb21w bGV4aXR5IGludm9sdmVkIGluIHN1Y2ggYXR0YWNrcyBpcyB2ZXJ5IGxvdy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIEFuIGFtcGxpZmljYXRpb24gYXR0YWNrIHRvIHRoZSBjb25zdHJh aW5lZCBuZXR3b3JrIG1heSBiZSB0cmlnZ2VyZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBBbiBhbXBsaWZpY2F0aW9uIGF0dGFjayB0byB0aGUgY29uc3RyYWluZWQgbmV0d29y ayBtYXkgYmUgdHJpZ2dlcmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBu YW1lPSJwYXJ0LWw1IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4g cGFnZSAyOSwgbGluZSA0NjwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjUi IC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDMwLCBsaW5l IDIwPC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMS4gIEFja25vd2xlZGdtZW50czwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjExLiAgQWNrbm93bGVkZ21lbnRzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBbiBpbml0aWFsIHZlcnNpb24gb2YgVGFibGUgMiBp biBTZWN0aW9uIDcgaGFzIGJlZW4gcHJvdmlkZWQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBBbiBpbml0aWFsIHZlcnNpb24gb2YgVGFibGUgMiBpbiBTZWN0aW9uIDcgaGFz IGJlZW4gcHJvdmlkZWQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgcmV2aXNpb24gLTA1IG9mIHRoZSBDb1JFIENvQVAgSS1ELiAgU3Bl Y2lhbCB0aGFua3MgdG8gUGV0ZXIgdmFuIGRlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHJldmlzaW9uIC0wNSBvZiB0aGUgQ29SRSBDb0FQIEktRC4gIFNwZWNpYWwgdGhhbmtz IHRvIFBldGVyIHZhbiBkZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgU3RvayBmb3IgY291bnRsZXNzIGNvbW1lbnRzIGFuZCBkaXNjdXNz aW9ucyBvbiB0aGlzIGRvY3VtZW50LCB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgU3RvayBmb3IgY291bnRsZXNzIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9ucyBvbiB0aGlz IGRvY3VtZW50LCB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGNvbnRyaWJ1dGVkIHRvIGl0cyBjdXJyZW50IHN0cnVjdHVyZSBhbmQg dGV4dC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb250cmlidXRlZCB0byBp dHMgY3VycmVudCBzdHJ1Y3R1cmUgYW5kIHRleHQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGFua3MgdG8gQWJoaWphbiBCaGF0dGFjaGFyeXlhLCBBbGV4ZXkgTWVsbmlrb3YsIEJy aWFuIEZyYW5rLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoYW5rcyB0byBB YmhpamFuIEJoYXR0YWNoYXJ5eWEsIEFsZXhleSBNZWxuaWtvdiwgQnJpYW4gRnJhbmssPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENhcnN0 ZW4gQm9ybWFubiwgQ2hyaXN0aWFuIEFtc3Vlc3MsIENocmlzdGlhbiBHcm92ZXMsIEN1bGxlbjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENhcnN0ZW4gQm9ybWFubiwgQ2hyaXN0 aWFuIEFtc3Vlc3MsIENocmlzdGlhbiBHcm92ZXMsIEN1bGxlbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBKZW5uaW5ncywgRG9yb3RoeSBH ZWxsZXJ0LCBGcmFuY2VzY28gQ29yYXp6YSwgRnJhbmNpcyBEdXBvbnQsIEhhbm5lczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEplbm5pbmdzLCBEb3JvdGh5IEdlbGxlcnQsIEZy YW5jZXNjbyBDb3JhenphLCBGcmFuY2lzIER1cG9udCwgSGFubmVzPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAxMSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRzY2hvZmVuaWcsIEphaW1lIEppbWVuZXos IEtlcGVuZyBMaSwgS2VycnkgTHlubiwgS2xhdXMgSGFydGtlLCBMaW55aTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUc2Nob2ZlbmlnLCBKYWltZSBKaW1lbmV6LCA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5LYXRobGVlbiBNb3JpYXJ0eSw8L3NwYW4+IEtlcGVuZyBMaSwgS2Vycnkg THlubiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBUaWFuLCBNaWNoZWxlIFJvc3NpLCBNaWNoZWxlIFpvcnppLCBOaWNvbGEgQnVpLCBQ ZXRlciBTYWludC1BbmRyZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgS2xh dXMgSGFydGtlLCBMaW55aSBUaWFuLCBNaWNoZWxlIFJvc3NpLCBNaWNoZWxlIFpvcnppLCBOaWNv bGEgQnVpLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIFNlYW4gTGVvbmFyZCwgWmFjaCBTaGVsYnkgZm9yIGhlbHBmdWwgY29tbWVudHMg YW5kIGRpc2N1c3Npb25zIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg UGV0ZXIgU2FpbnQtQW5kcmUsIFNlYW4gTGVvbmFyZCwgWmFjaCBTaGVsYnkgZm9yIGhlbHBmdWwg Y29tbWVudHMgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgaGF2ZSBzaGFwZWQgdGhlIGRvY3VtZW50LjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBkaXNjdXNzaW9ucyB0aGF0IGhhdmUgc2hhcGVkIHRoZSBkb2N1 bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSByZXNlYXJjaCBsZWFkaW5n IHRvIHRoZXNlIHJlc3VsdHMgaGFzIHJlY2VpdmVkIGZ1bmRpbmcgZnJvbSB0aGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgcmVzZWFyY2ggbGVhZGluZyB0byB0aGVzZSBy ZXN1bHRzIGhhcyByZWNlaXZlZCBmdW5kaW5nIGZyb20gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEV1cm9wZWFuIENvbW11bml0eSdz IFNldmVudGggRnJhbWV3b3JrIFByb2dyYW1tZSBbRlA3LzIwMDctMjAxM108L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFdXJvcGVhbiBDb21tdW5pdHkncyBTZXZlbnRoIEZyYW1l d29yayBQcm9ncmFtbWUgW0ZQNy8yMDA3LTIwMTNdPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVuZGVyIGdyYW50IGFncmVlbWVudCBuLjI1 MTU1Ny48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1bmRlciBncmFudCBhZ3Jl ZW1lbnQgbi4yNTE1NTcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMi4gIFJlZmVyZW5j ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMi4gIFJlZmVyZW5jZXM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEyLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEyLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3 b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFt ZT0icGFydC1sNiIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBh Z2UgMzIsIGxpbmUgMzA8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI2IiAv PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAzMiwgbGluZSA1 MTwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1czQy5SRUMtaHRtbDUtMjAxNDEw MjhdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1czQy5SRUMtaHRtbDUtMjAx NDEwMjhdPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICAgICAgICAgSGlja3NvbiwgSS4sIEJlcmpvbiwgUi4sIEZhdWxrbmVyLCBTLiwg TGVpdGhlYWQsIFQuLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgSGlja3NvbiwgSS4sIEJlcmpvbiwgUi4sIEZhdWxrbmVyLCBTLiwgTGVpdGhlYWQsIFQuLDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIE5hdmFyYSwgRS4sIE8nQ29ubm9yLCBFLiwgYW5kIFMuIFBmZWlmZmVyLCAiSFRN TDUiLCBXM0M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIE5h dmFyYSwgRS4sIE8nQ29ubm9yLCBFLiwgYW5kIFMuIFBmZWlmZmVyLCAiSFRNTDUiLCBXM0M8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICBSZWNvbW1lbmRhdGlvbiBSRUMtaHRtbDUtMjAxNDEwMjgsIDIwMTQsPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBSZWNvbW1lbmRhdGlvbiBSRUMt aHRtbDUtMjAxNDEwMjgsIDIwMTQsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0O2h0dHA6Ly93d3cudzMub3JnL1RS LzIwMTQvUkVDLWh0bWw1LTIwMTQxMDI4Jmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICZsdDtodHRwOi8vd3d3LnczLm9yZy9UUi8yMDE0L1JFQy1odG1s NS0yMDE0MTAyOCZndDsuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BcHBlbmRpeCBBLiAg Q2hhbmdlIExvZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFwcGVuZGl4IEEuICBD aGFuZ2UgTG9nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbTm90ZSB0byBSRkMgRWRp dG9yOiBQbGVhc2UgcmVtb3ZlIHRoaXMgc2VjdGlvbiBiZWZvcmUgcHVibGljYXRpb24uXTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtOb3RlIHRvIFJGQyBFZGl0b3I6IFBsZWFz ZSByZW1vdmUgdGhpcyBzZWN0aW9uIGJlZm9yZSBwdWJsaWNhdGlvbi5dPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTIiIC8+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imlu c2VydCI+Q2hhbmdlcyBmcm9tIGlldGYtMTQgdG8gaWV0Zi0xNTo8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbyAgS2F0 aGxlZW4gTW9yaWFydHkncyBESVNDVVNTIChJRVNHIHJldmlldyk8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2hhbmdlcyBmcm9tIGlldGYt MTMgdG8gaWV0Zi0xNDo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDaGFuZ2Vz IGZyb20gaWV0Zi0xMyB0byBpZXRmLTE0OjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg byAgQWRkcmVzc2VkIEdlbi1BUlQgYW5kIEFEIHJldmlldyBjb21tZW50cy48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBBZGRyZXNzZWQgR2VuLUFSVCBhbmQgQUQgcmV2aWV3 IGNvbW1lbnRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2hhbmdlcyBmcm9tIGll dGYtMTIgdG8gaWV0Zi0xMyAoQ2hyaXN0aWFuIEFtc3Vlc3MnIGNvbW1lbnRzKTo8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDaGFuZ2VzIGZyb20gaWV0Zi0xMiB0byBpZXRmLTEz IChDaHJpc3RpYW4gQW1zdWVzcycgY29tbWVudHMpOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgbyAgTW9yZSBtaXNzaW5nIHNsYXNoZXMgaW4gVVJJIG1hcHBpbmcgdGVtcGxhdGUgZXhh bXBsZXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgTW9yZSBtaXNzaW5n IHNsYXNoZXMgaW4gVVJJIG1hcHBpbmcgdGVtcGxhdGUgZXhhbXBsZXMuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBDaGFuZ2VzIGZyb20gaWV0Zi0xMSB0byBpZXRmLTEyICgybmQgV0dM Qyk6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ2hhbmdlcyBmcm9tIGlldGYt MTEgdG8gaWV0Zi0xMiAoMm5kIFdHTEMpOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgoKICAgICA8dHI+ PHRkPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0aCBjb2xzcGFu PSI1IiBhbGlnbj0iY2VudGVyIj48YSBuYW1lPSJlbmQiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAx MiBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvYT48L3RoPjwvdHI+CiAgICAgPHRyIGNsYXNzPSJzdGF0 cyI+PHRkPjwvdGQ+PHRoPjxpPjE5IGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0 aD48aT4gPC9pPjwvdGg+PHRoPjxpPjQzIGxpbmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+PC90aD48 dGQ+PC90ZD48L3RyPgogICAgIDx0cj48dGQgY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciIgY2xh c3M9InNtYWxsIj48YnIvPlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEu NDIuIFRoZSBsYXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8v d3d3LnRvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIiA+aHR0cDovL3Rvb2xzLmlldGYub3Jn L3Rvb2xzL3JmY2RpZmYvPC9hPiA8L3RkPjwvdHI+CiAgIDwvdGFibGU+CiAgIDwvYm9keT4KICAg PC9odG1sPgo= --_002_D41046A471468thomasfossatialcatellucentcom_-- From nobody Tue Sep 27 10:18:18 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 0818C12B2E9; Tue, 27 Sep 2016 10:18:18 -0700 (PDT) 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.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147499669802.4576.11301612130873686304.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 10:18:18 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Tue, 27 Sep 2016 17:18:18 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-http-mapping-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't get why you don't at least RECOMMEND that HTTP requests need to be authenticated? And I don't get why you don't REQUIRE HC implementations support some form(s) of strong-ish user authentication. We are seeing fairly major botnets being built from the kinds of device that might use CoAP and (with careless implementations all around) this could provide a nice way to expose those to the Internet. Isn't a good bit more caution needed in what we describe here? Note: I'm not saying HTTP authentication, nor specifically TLS client auth. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 Tue Sep 27 11:59: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 B517312B242; Tue, 27 Sep 2016 11:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urExgOuS9QvI; Tue, 27 Sep 2016 11:59:38 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD0C126579; Tue, 27 Sep 2016 11:59:37 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id z126so22618985vkd.0; Tue, 27 Sep 2016 11:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T5U9ThD2kG9iZAV3/RLoHjNx5vX79eRGhPzcSiN/aBU=; b=rH/2kK/TweAFxbavQRphMLFid2xF/iTaEwlQkRXKFbuVu7curXqDH6+LC7PBnCvlFc Tf9OMhnJ2qo4WiWaHjjSY8ly7/0YKJLjgeZxIDCd//QV2czCGnNaMrEoVVdvPX7gLb2T SfAJXRbNBocwtT5S3AGTzrHMn9+66lVlpELYNubb2VmqiXv3V7Ud+ZpYfDzKKwlkUPKg 0NsiCejATRVOtNmLJsMsvfXRyKuhS3aQX9iiOv9UjBJJQ2vLXH+q7AwFwDEhfx9YMYBF aDP5q8RzCBtX8ko91QpvaS7lhXA1aQM2WIWc7IrK7ns9UdMcu20WKxDgdr+cvoEeLBc9 wKRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T5U9ThD2kG9iZAV3/RLoHjNx5vX79eRGhPzcSiN/aBU=; b=mJQOgf+EbjbU67NPYtxfcyHZEDRq5c8nNkQjymr6LyeZT6unZqmgWYyswqNhGfi4EZ YkBOLbRmITQoKbQWQdA2zv0XS8UEVAsSK6ukxPMDHHgLlah7A5vbkG1cI8pL/HIO2YXs BZMggQrmYTq3+B+/WZ/rUBGgeY3QHd52OV8xexRcoUh4CwberGbQBMQOEv5cVhjkve6/ plgYhOuwUyuxlfidmgCU2GIl3wxS+SABFAz4G6rB64KTd97gtMCBVjSpvznU58jtl83v W1PowEEDgHVWCS4IZa9T97KbOUqxpvSA4WpsgAB4cFS/vRegTyHDLbt5fhf2o6gWQqz/ cxnA== X-Gm-Message-State: AA6/9RmxSiIDpFjt8UNrypmh9RpDHjqeCTe/SwhtCLsmsAdNIkmoVlU+DcyS73gQzamd+TiYohD+Tw9fjHN9kw== X-Received: by 10.31.151.78 with SMTP id z75mr14772709vkd.41.1475002777052; Tue, 27 Sep 2016 11:59:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Tue, 27 Sep 2016 11:59:36 -0700 (PDT) In-Reply-To: References: <147491296765.5016.11067016540200615437.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 27 Sep 2016 14:59:36 -0400 Message-ID: To: "Fossati, Thomas (Nokia - GB)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS) 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 Sep 2016 18:59:41 -0000 Hi Thomas, Thank you for sending along the diff, the text looks great and I hope others find it helpful. I'll clear my discuss now since htis is in your pending draft. Thanks, Kathleen On Tue, Sep 27, 2016 at 10:55 AM, Fossati, Thomas (Nokia - GB) wrote: > Hi Kathleen, > > I have attached the diff. Let us know if it's OK. > > Cheers, thanks! > > On 27/09/2016 14:50, "Kathleen Moriarty" > wrote: >>Hi Thomas, >> >>On Tue, Sep 27, 2016 at 5:13 AM, Fossati, Thomas (Nokia - GB) >> wrote: >>> On 27/09/2016 02:02, "Kathleen Moriarty" >>> wrote: >>>>Hi Thomas, >>>> >>>>Thanks for your quick response, inline. >>>> >>>>On Mon, Sep 26, 2016 at 6:55 PM, Fossati, Thomas (Nokia - GB) >>>> wrote: >>>>> Hi Kathleen, >>>>> >>>>> Thanks very much for your comments! Some initial thoughts inlined. >>>>> >>>>> On 26/09/2016 19:02, "Kathleen Moriarty" >>>>> wrote: >>>>>>---------------------------------------------------------------------- >>>>>>DISCUSS: >>>>>>---------------------------------------------------------------------- >>>>>> >>>>>>This is one discuss point with 2 questions. The second part is what's >>>>>>discussable and the first should be easy to fix either with the text >>>>>>provided or something similar. >>>>>> >>>>>>1. In Section 10.1, this is more of a security than a privacy >>>>>>consideration as this is "network reconnaissance". This is a typical >>>>>>pre-cursor to an attack one the the attacker has gathered more >>>>>>information on the network. >>>>>> >>>>>> From a privacy perspective, they can be >>>>>> used to gather detailed information about the resources hosted in >>>>>>the >>>>>> constrained network. >>>>>> >>>>>>How about: >>>>>> This can be >>>>>> used to gather detailed information about the resources hosted in >>>>>>the >>>>>> constrained network, as siting with network reconnaissance. >>>>>> >>>>>>then for the last sentence: >>>>>> If privacy is a concern, for >>>>>> example whenever the HTTP request transits through the public >>>>>> Internet, the request SHOULD be transported over a mutually >>>>>> authenticated and encrypted TLS connection. >>>>>> >>>>>>How about: >>>>>> If confidentiality of the network is a concern, for >>>>>> example whenever the HTTP request transits through the public >>>>>> Internet, the request SHOULD be transported over a mutually >>>>>> authenticated and encrypted TLS connection. >>>>>> >>>>>>The word privacy here is confusing, so it's better to state exactly >>>>>>the >>>>>>issue. >>>>> >>>>> I guess the privacy issue we want to highlight here is that a query to >>>>> /.well-known/core might return, for example, the inventory of >>>>>someone's >>>>> home appliances and devices. This might still be interesting >>>>>information >>>>> for an attacker that is not necessarily searching for vulnerabilities >>>>>in >>>>> the protocol stack of the fridge. >>>>> >>>>> Could you please suggest a better term than "privacy" to describe the >>>>> concern above? >>>> >>>>Oh, that point wasn't clear in the draft and is certainly a privacy >>>>consideration. What I read from the text was a network recon threat, >>>>which was about confidentiality of the network services - their >>>>existence and not privacy related information that could be >>>>discovered. As such, covering both threats would be best, but I would >>>>suggest you expand the current text to explain this threat. >>> >>> OK. I'll expand the privacy concern to make it more clear, and add the >>> network reconnaissance threat that you suggested as well. >>> >>>>> BTW, your point about network reconnaissance is great and I'd like to >>>>> incorporate your suggestion in section 10.1. >>>>> >>>>> >>>>>>More importantly, if you can do network reconnaissance, what's to stop >>>>>>the attacker from using this new method of connecting? Some mention >>>>>>of >>>>>>this threat should be explicitly stated, maybe section 10.1 is the >>>>>>best >>>>>>place to do that, expanding on the existing text with another >>>>>>sentence. >>>>> >>>>> Sorry, I don't understand what you mean by "what's to stop the >>>>>attacker >>>>> from using this new method of connecting?". >>>> >>>>By new method, I mean that you now have a proxy to translate HTTP to >>>>COAP. You would not have been able to make such connections before. >>>>Could anything happen at the proxy when the traffic is proxied? >>>> >>>>> >>>>>>2. (Really part of #1, but a separate point) Could transforms of URIs >>>>>>result in successful attacks? I would think that would be the highest >>>>>>security consideration. Although RFC7230 includes similar >>>>>>considerations, the mapping aspect of this draft could open up new >>>>>>attack >>>>>>possibilities, especially if a media type mapping is used. If there >>>>>>is >>>>>>an attack possible in the IoT space that is not in the HTTP world >>>>>>(device >>>>>>specific, or related to size constraints and coding), an intrusion >>>>>>prevention system monitoring the HTTP traffic before it is transformed >>>>>>would not pick it up and the attack traffic would evade detection. I >>>>>>think this merits mention and some text in the draft. Please let me >>>>>>know >>>>>>if it is elsewhere and another pointer is all that is needed. >>>>> >>>>> Re: URI mapping. I can't see an obvious (or less obvious) way this >>>>>could >>>>> be an issue per se -- assuming the HTTP parser and the CoAP encoder >>>>>are >>>>> both correct (as discussed in the security considerations of RFC 7230 >>>>>and >>>>> RFC 7252). >>>>> >>>> >>>>But could anything happen in that translation? If there is an exploit >>>>possible through a malformed URI, that isn't bad on one side of the >>>>translation, but is on the other? The pointer to the HTTP drafts is >>>>good, but I am still wondering if anything could happen and if there >>>>is a reason why this should also be called out as a consideration. The >>>>discussion just points to the HTTP security considerations, are there >>>>some for COAP? >>> >>> I think it's worth pointing out (at the very beginning of section 10) >>>that >>> the correctness of the request parsing, and in particular the URI >>> translation process, is essential to the security of the HC proxy. We >>> could refer to the relevant parts of CoAP and HTTP that already >>>highlight >>> this criticality (the request parsing caveats in section 9.3, 9.4, 9.5 >>>and >>> 9.6 of RFC7230 [1] and the bits related to URI parsing in [2]). The >>>point >>> to raise here, I think, is that the implementation quality of the HC >>>proxy >>> -- i.e. careful implementation and/or selection of the third party >>> libraries, sane configuration defaults - is essential to the security of >>> potentially *lots* of things on the constrained side. >>> >>> [1] https://tools.ietf.org/html/rfc7230#section-9 >>> [2] https://tools.ietf.org/html/rfc7252#section-11.1 >>> >>>>> Re: Media mapping. The funnel has a disproportionately big mouth and >>>>>a >>>>> minuscule stem, allowing very few degrees of freedom: I might be wrong >>>>>but >>>>> it seems to me that the attack surface is virtually zero there. Are >>>>>you >>>>> thinking of the optional "loose" mapping defined in section 6.3 >>>>>instead? >>>> >>>>I'm just wondering, and could be wrong (hence wanting t discuss it >>>>since this isn't explained in the draft as a consideration. I would >>>>think there would be some considerations related to proxying this >>>>content between 2 protocols. >>>> >>>>> (If so, the last paragraph of section 6.1 has text suggesting stricter >>>>> access control if that feature is enabled. Is that enough? Should it >>>>>be >>>>> moved to the security considerations?) >>>> >>>>I'm also asking. Could there be code problems on the COAP enabled >>>>devices that could be exploited with malformed URIs? Is this covered >>>>in a COAP security consideration section somewhere and a pointer >>>>should be added? Am I way off base? >>> >>> No, you are certainly not off base, the threat is real. And the risk of >>> the HC proxy becoming an integral part of the threat (rather than part >>>of >>> the solution) is factual given where it sits in the network. This needs >>> to be clearly spelled out, probably as an argument that reinforces the >>> need for the highest quality of implementation (see above). >>> >>>>> It's late and I certainly lack a bit of imagination (I can only think >>>>>of >>>>> issues deriving from buggy implementations, nothing that is intrinsic >>>>>to >>>>> the protocols' interactions). Do you have anything precise in mind? >>>> >>>>Hmm, the HTTP draft covers malformed URIs that would only be an issue >>>>with a buggy implementation because this attack type is so common, so >>>>I was referring to an issue like this for COAP and wondering if there >>>>should be some warning text. The IoT space is so large and there are >>>>bound to be issues. If you out-of-scoped such issues, but said this >>>>could also be a problem with COAP, that would cover my concern. >>> >>> I agree. As per the warning text, I think this would be covered by the >>> proposed text above re: QoImpl? >>> >>>>I'd just like to make sure we >>>>aren't missing a warning that could be helpful. >>> >>> Sure, your comments are super helpful. Thanks again! >>> >>> (If you are OK with the rationale I'll go on and prepare a diff for you >>>to >>> look at.) >> >>Thank you, that would be great. I like the approach you are >>suggesting and appreciate you responding quickly with a good solution. >> >>> >>> Cheers, t >>> >> >> >> >>-- >> >>Best regards, >>Kathleen >> > > -- Best regards, Kathleen From nobody Tue Sep 27 12:04:01 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 92F6212B006; Tue, 27 Sep 2016 12:04:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147500304059.4465.16259540802263273171.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 12:04:00 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Kathleen Moriarty's No Objection on draft-ietf-core-http-mapping-14: (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: Tue, 27 Sep 2016 19:04:00 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-core-http-mapping-14: 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: ---------------------------------------------------------------------- Thank you for addressing my discuss points with the proposed text. I'll follow along with Stephen's discuss as he picked up on some other important points. From nobody Tue Sep 27 15:29:41 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 D56F912B35A; Tue, 27 Sep 2016 15:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 15:29:39 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Tue, 27 Sep 2016 22:29:40 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-http-mapping-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is going to be a Yes position after we talk, of course ... Someone can tell me to relax, but I found this text When found in a Hosting HTTP URI, the scheme (i.e., "coap" or "coaps"), the scheme component delimiter (":"), and the double slash ("//") preceding the authority MAY be omitted. In such case, a local default - not defined by this document - applies. So, http://p.example.com/hc/s.coap.example.com/foo could either represent the target coap://s.coap.example.com/foo or coaps://s.coap.example.com/foo depending on application specific presets. worrisome - is it saying that if you leave off the scheme, you don't know whether the resulting mapped URI is coap:// or coaps://? If so, how critical is it that this isn't deterministic? Can the HTTP client tell whether the result used coaps://? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text from the Abstract, This document covers the Reverse, Forward and Interception cross-protocol proxy cases. are Reverse, Forward, and Interception proxys so well understood that the average reader would know what you're talking about? Do I understand that they're defined directly in this document, not referencing some other draft? Further in the document, I see this text, Note that the guidelines apply to all forms of an HC proxy (i.e., Reverse, Forward, Intercepting) unless explicitly otherwise noted. which makes me wonder if you need to mention the various forms of HC proxy in the Abstract at all ... This text, Note that a Reverse Proxy appears to an HTTP client as an origin server while a Forward Proxy does not. So, when communicating with a Reverse Proxy a client may be unaware it is communicating with a proxy at all. would be clearer if it followed the definition of Reverse Proxy. In the current document, Reverse Proxy is defined, then Interception Proxy is defined, and then this note refers back to the Reverse Proxy definition. Confusingly, aren't clients unaware they're communicating with an Interception Proxy, as well? It's easy for me to read this text, See Figure 1 for an example deployment scenario. Here a HC proxy is located at the boundary of the Constrained Network domain, to avoid sending any HTTP traffic into the Constrained Network and to avoid any (unsecured) CoAP multicast traffic outside the Constrained Network. as saying that secured CoAP multicast traffic might be sent outside the Constrained Network. Is that what you meant? In this text, The HC proxy is furthermore configured to only pass through GET requests in order to protect the constrained network. did you mean "GET requests and their corresponding responses"? In this text, The default URI mapping function SHOULD be implemented and activated by default in a HC proxy, unless there are valid reasons, e.g., application specific, to use a different mapping function. I found myself wondering if you could point to a valid use of a different mapping function. That would have been helpful to me. In this text, However, it should be noted that in certain cases, transcoding can lose information in a non-obvious manner. For example, encoding an XML document using schema-informed EXI encoding leads to a loss of information when the destination does not know the exact schema version used by the encoder, which means that whenever the HC proxy transcodes an application/XML to application/EXI in-band metadata could be lost. Therefore, the implementer should always carefully verify such lossy payload transformations before triggering the transcoding. I didn't understand how you "verify" payload transformations. Is that a well-understood term of art for the community? From nobody Tue Sep 27 16:16: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 4BB2212B514; Tue, 27 Sep 2016 16:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vujDWvxVcjyl; Tue, 27 Sep 2016 16:16:16 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF5512B4BB; Tue, 27 Sep 2016 16:16:16 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A16636F1737A8; Tue, 27 Sep 2016 23:16:10 +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 u8RNGETu002961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2016 23:16:14 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u8RNGDYM005637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Sep 2016 01:16:13 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 28 Sep 2016 01:16:13 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGOMmqJGZdwxHo0KUnSXzA8AjWqCN57iA Date: Tue, 27 Sep 2016 23:16:13 +0000 Message-ID: References: <147499669802.4576.11301612130873686304.idtracker@ietfa.amsl.com> In-Reply-To: <147499669802.4576.11301612130873686304.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.6.8.160830 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <269A25975057DF4E86954FA5509EA2E5@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Tue, 27 Sep 2016 23:16:19 -0000 Hi Stephen, I'm only going through the COMMENTS section for now since that looks easier than the DISCUSS :-) On 27/09/2016 18:18, "Stephen Farrell" wrote: >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > > > >I don't get why you don't at least RECOMMEND that HTTP >requests need to be authenticated? And I don't get why you >don't REQUIRE HC implementations support some form(s) of >strong-ish user authentication. We are seeing fairly major >botnets being built from the kinds of device that might use >CoAP and (with careless implementations all around) this >could provide a nice way to expose those to the Internet. >Isn't a good bit more caution needed in what we describe >here? Note: I'm not saying HTTP authentication, nor >specifically TLS client auth. > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >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. I understand this concern in principle, but from a practical standpoint I'm not super convinced that the surface it introduces is large enough to deserve mentioning. Currently, CoAP defines 8 different content formats. So, worst case, the amplification would be x7 on the first request, then caching should kick in (since 4.06, like all 4.xx, is cacheable) and the HC proxy would then absorb any equivalent request (until max-age expires). (The reasoning above should be fine provided the HC proxy default-denies forwarding HTTP requests with "application/coap-payload" -- as you suggest below.) >- 6.1: What "other forms of access control" do you mean? I guess you mean "other" is weirdly placed in that sentence? It should probably just say: "some form of access control". >- 6.2: This looks like it allows too large an attack surface >and maybe you ought default to denying I guess you are referring to the last para: "A HTTP client may use the media type "application/coap-payload" [...]"? If so, nice catch! OLD: A HTTP client may use the media type "application/coap-payload" as a means to send a specific content format to a CoAP server via a HC Proxy if the client has determined that the HC Proxy does not directly support the type mapping it needs. This case may happen when dealing for example with newly registered, yet to be registered, or experimental CoAP content formats. NEW: A HTTP client may use the media type "application/coap-payload" as a means to send a specific content format to a CoAP server via a HC Proxy if the client has determined that the HC Proxy does not directly support the type mapping it needs. This case may happen when dealing for example with newly registered, yet to be registered, or experimental CoAP content formats. However, unless explicitly configured to allow pass-through unknown content formats, the HC proxy SHOULD NOT forward requests carrying a Content-Type or Accept header with an "application/coap-payload", and return an appropriate client error (4xx) instead. >- 6.5: Transcoding bugs galore! Given the history of bugs in >transcoding libraries shouldn't you recommend some caution >here? It looks like a sensible advice, but I'm not sure what to write exactly. This might be covered by the "quality of implementation" argument in the diff I sent previously to address Kathleen's DISCUSS? >And are there forms of zipbomb that might cause >problems? Yes, probably worth pointing out that a JSON->CBOR transcoder might inflate [1]. [1] https://tools.ietf.org/html/rfc7049#section-4.2 >- 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. Sorry, I don't understand why you think that that wouldn't define an unambiguous decision criterion? In practice, you start Observing a given resource and track: - the frequency of the updates on the CoAP side, and - the inter-arrival time of the requests targeting that same resource on the HTTP side. After a while the formula allows you to decide whether the resource is popular enough -- and so you should keep on observing it -- or if it's better to unsubscribe and go back to Etag revalidation. >- 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." ? I think the sentence just below that should provide an example (firewall): "Assuming that CoAP nodes are isolated behind a firewall as in the HC proxy deployment shown in Figure 1, the HC proxy may be configured to translate the incoming HTTPS request using plain CoAP (NoSec mode)." Cheers and thanks! t From nobody Tue Sep 27 16:17:44 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 4AF1212B4BB; Tue, 27 Sep 2016 16:17:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147501826330.11764.12263508980828867466.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 16:17:43 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Suresh Krishnan's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Tue, 27 Sep 2016 23:17:43 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-core-http-mapping-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this well written draft. I do have a concern about some missing behavior. When an IPv6 literal is used the percent encoded square brackets need to be reverted to their non-percent-encoded form on the HTTP server in order to be compliant with RFC7252 that uses IP-literal from RFC3986 for the host component. This is not specified anywhere in the document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just thinking out loud here (Maybe I am being paranoid). There does not seem to be any kind of limitations on the IPv6 address part of the coap URI. What stops someone from sticking in a multicast address into the coap URI (such as the FF0X::FD All CoAP Nodes address) to use the proxy as DoS attack amplifier? From nobody Tue Sep 27 16:50:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F67812B244; Tue, 27 Sep 2016 16:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXfcYyEMjgOq; Tue, 27 Sep 2016 16:50:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F129912B097; Tue, 27 Sep 2016 16:50:10 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 549A41B1A9BA6; Tue, 27 Sep 2016 23:50:04 +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 u8RNo8Im016664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2016 23:50:08 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u8RNo7W1012032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Sep 2016 01:50:07 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Wed, 28 Sep 2016 01:50:07 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Suresh Krishnan , The IESG Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGRVcSSseiJAtCk6xsZWEbKik7qCN8M4A Date: Tue, 27 Sep 2016 23:50:06 +0000 Message-ID: References: <147501826330.11764.12263508980828867466.idtracker@ietfa.amsl.com> In-Reply-To: <147501826330.11764.12263508980828867466.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.6.8.160830 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Suresh Krishnan's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Tue, 27 Sep 2016 23:50:14 -0000 Hi Suresh, On 28/09/2016 00:17, "Suresh Krishnan" wrote: >Suresh Krishnan has entered the following ballot position for >draft-ietf-core-http-mapping-14: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Thanks for this well written draft. I do have a concern about some >missing behavior. When an IPv6 literal is used the percent encoded square >brackets need to be reverted to their non-percent-encoded form on the >HTTP server in order to be compliant with RFC7252 that uses IP-literal >from RFC3986 for the host component. This is not specified anywhere in >the document. Thanks! Would a note in section 5.3.2 work for you? OLD: When the authority of the Target CoAP URI is given as an IPv6address, then the surrounding square brackets must be percent-encoded in the Hosting HTTP URI, in order to comply with the syntax defined in Section 3.3. of [RFC3986] for a URI path segment. E.g.: coap://[2001:db8::1]/light?on becomes http://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. Everything else can be safely copied verbatim from the Target CoAP URI to the Hosting HTTP URI. NEW: When the authority of the Target CoAP URI is given as an IPv6address, then the surrounding square brackets must be percent-encoded in the Hosting HTTP URI, in order to comply with the syntax defined in Section 3.3. of [RFC3986] for a URI path segment. E.g.: coap://[2001:db8::1]/light?on becomes http://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. Note that the percent-encoded square brackets shall be reverted to their non-percent-encoded form when the HC proxy unpacks the Target CoAP URI. Everything else can be safely copied verbatim from the Target CoAP URI to the Hosting HTTP URI. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Just thinking out loud here (Maybe I am being paranoid). There does not >seem to be any kind of limitations on the IPv6 address part of the coap >URI. What stops someone from sticking in a multicast address into the >coap URI (such as the FF0X::FD All CoAP Nodes address) to use the proxy >as DoS attack amplifier? It makes no difference how the host is specified in the CoAP URI (as an IP-literal, IPv4 or "registered name"). It still has to be resolved to an IP address, and as soon as it's resolved the HC proxy can test if IN6_IS_ADDR_MULTICAST or IN_MULTICAST. If it is, then the security consideration in section 10.1 apply: "It is RECOMMENDED that the requestor of a multicast resource is strongly authenticated." Does that address your concern? Cheers, t From nobody Tue Sep 27 17:56: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 2864212B38E; Tue, 27 Sep 2016 17:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEpmYbGL5vCC; Tue, 27 Sep 2016 17:56:21 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 BDF6512B47D; Tue, 27 Sep 2016 17:56:20 -0700 (PDT) X-AuditID: c6180641-2580a98000000a0b-e4-57eac0cf10aa Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id AA.E6.02571.FC0CAE75; Tue, 27 Sep 2016 20:56:15 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 20:56:17 -0400 From: Suresh Krishnan To: "Fossati, Thomas (Nokia - GB)" , The IESG Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGRnjKLa1sBmkwE6bzILsm2co+Q== Date: Wed, 28 Sep 2016 00:56:16 +0000 Message-ID: References: <147501826330.11764.12263508980828867466.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPt+75A6/CDZ5MsLDYtvECm8W+t+uZ Lb78vsBoMePPRGaLls+f2BxYPZYs+cnkcffWJaYApigum5TUnMyy1CJ9uwSujDv/CwvOKVQs 2niKrYHxg1QXIyeHhICJxLy3M5m6GLk4hAQ2MEp8657ADuEsB3K+n2EFqWIDqtqw8zMTiC0i ECmx7tkfZpAiZoEXjBIrfvwFSwgLpEv83naUDaIoQ6L91RQWCFtPYt7NX2BxFgFViW3b34DF eQV8JX6dv8cIsa2ZUWL1/N1g2xgFxCS+n1oDNpRZQFzi1pP5TBC3Ckgs2XOeGcIWlXj5+B8r hK0k8fH3fHaIej2JG1OnsEHY2hLLFr5mhlgmKHFy5hOWCYwis5CMnYWkZRaSlllIWhYwsqxi 5CgtLsjJTTcy3MQIjItjEmyOOxj39noeYhTgYFTi4VVwfhUuxJpYVlyZe4hRgoNZSYS3Vfh1 uBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe6yH3w4UE0hNLUrNTUwtSi2CyTBycUg2MwU2nNk8I uFrxMmGuLNfK+uW7+rccFHphNNGhPIVl/nEhd9EdV5Y1pEl9D/eY5JZtm+XXPPs6b9ikL3uO 8xfJuUl89Pkes0pfk7Ew7XLXV4uvXW6Hr9X7V8zStRcpMmtx2/jtNL9C3dYjM4otnigxM8Xf jVYXPljQ+u5Md3iE2Rz/g0XbaiuUWIozEg21mIuKEwEHcf4khwIAAA== Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Suresh Krishnan's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Wed, 28 Sep 2016 00:56:23 -0000 Hi Thomas,=0A= Your suggested text works for me. I will clear as soon as the new versio= n =0A= hits.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 09/27/2016 07:50 PM, Fossati, Thomas (Nokia - GB) wrote:=0A= > Hi Suresh,=0A= >=0A= > On 28/09/2016 00:17, "Suresh Krishnan" =0A= > wrote:=0A= >> Suresh Krishnan has entered the following ballot position for=0A= >> draft-ietf-core-http-mapping-14: Discuss=0A= >>=0A= >> When responding, please keep the subject line intact and reply to all=0A= >> email addresses included in the To and CC lines. (Feel free to cut this= =0A= >> introductory paragraph, however.)=0A= >>=0A= >>=0A= >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l=0A= >> for more information about IESG DISCUSS and COMMENT positions.=0A= >>=0A= >>=0A= >> The document, along with other ballot positions, can be found here:=0A= >> https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/=0A= >>=0A= >>=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> DISCUSS:=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >> Thanks for this well written draft. I do have a concern about some=0A= >> missing behavior. When an IPv6 literal is used the percent encoded squar= e=0A= >> brackets need to be reverted to their non-percent-encoded form on the=0A= >> HTTP server in order to be compliant with RFC7252 that uses IP-literal= =0A= >>from RFC3986 for the host component. This is not specified anywhere in=0A= >> the document.=0A= >=0A= > Thanks! Would a note in section 5.3.2 work for you?=0A= >=0A= > OLD:=0A= >=0A= > When the authority of the Target CoAP URI is given as an IPv6address,=0A= > then the surrounding square brackets must be percent-encoded in the=0A= > Hosting HTTP URI, in order to comply with the syntax defined in=0A= > Section 3.3. of [RFC3986] for a URI path segment. E.g.:=0A= > coap://[2001:db8::1]/light?on becomes=0A= > http://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on.=0A= >=0A= >=0A= > Everything else can be safely copied verbatim from the Target CoAP=0A= > URI to the Hosting HTTP URI.=0A= >=0A= > NEW:=0A= >=0A= >=0A= > When the authority of the Target CoAP URI is given as an IPv6address,=0A= > then the surrounding square brackets must be percent-encoded in the=0A= > Hosting HTTP URI, in order to comply with the syntax defined in=0A= > Section 3.3. of [RFC3986] for a URI path segment. E.g.:=0A= > coap://[2001:db8::1]/light?on becomes=0A= > http://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on.=0A= >=0A= > Note that the percent-encoded square brackets shall be reverted to=0A= > their non-percent-encoded form when the HC proxy unpacks the Target=0A= > CoAP URI.=0A= >=0A= >=0A= > Everything else can be safely copied verbatim from the Target CoAP=0A= > URI to the Hosting HTTP URI.=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >> ----------------------------------------------------------------------= =0A= >> COMMENT:=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >> Just thinking out loud here (Maybe I am being paranoid). There does not= =0A= >> seem to be any kind of limitations on the IPv6 address part of the coap= =0A= >> URI. What stops someone from sticking in a multicast address into the=0A= >> coap URI (such as the FF0X::FD All CoAP Nodes address) to use the proxy= =0A= >> as DoS attack amplifier?=0A= >=0A= > It makes no difference how the host is specified in the CoAP URI (as an= =0A= > IP-literal, IPv4 or "registered name"). It still has to be resolved to a= n=0A= > IP address, and as soon as it's resolved the HC proxy can test if=0A= > IN6_IS_ADDR_MULTICAST or IN_MULTICAST. If it is, then the security=0A= > consideration in section 10.1 apply: "It is RECOMMENDED that the requesto= r=0A= > of a multicast resource is strongly authenticated."=0A= >=0A= > Does that address your concern?=0A= >=0A= > Cheers, t=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= =0A= From nobody Wed Sep 28 01:19:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0212B28A; Wed, 28 Sep 2016 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22flTNgTZxng; Wed, 28 Sep 2016 01:19:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42D712B369; Wed, 28 Sep 2016 01:19:15 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EE9B031101F6; Wed, 28 Sep 2016 08:19:11 +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 u8S8JDr0001270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2016 08:19:13 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 u8S8J5Fa026427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Sep 2016 10:19:12 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Wed, 28 Sep 2016 10:19:07 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Suresh Krishnan , "Fossati, Thomas (Nokia - GB)" , The IESG Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGRVcSSseiJAtCk6xsZWEbKik7qCOfvyA Date: Wed, 28 Sep 2016 08:19:07 +0000 Message-ID: References: <147501826330.11764.12263508980828867466.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Suresh Krishnan's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Wed, 28 Sep 2016 08:19:18 -0000 Hi Suresh, On 28/09/2016 01:56, "Suresh Krishnan" wrote: >Hi Thomas, > Your suggested text works for me. I will clear as soon as the new >version=20 >hits. OK, thanks. Your new text is in my working copy together with Kathleen's. I want to process all IESG reviews before pushing a new version though. Cheers, t >Regards >Suresh > >On 09/27/2016 07:50 PM, Fossati, Thomas (Nokia - GB) wrote: >> Hi Suresh, >> >> On 28/09/2016 00:17, "Suresh Krishnan" >> wrote: >>> Suresh Krishnan has entered the following ballot position for >>> draft-ietf-core-http-mapping-14: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>>https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Thanks for this well written draft. I do have a concern about some >>> missing behavior. When an IPv6 literal is used the percent encoded >>>square >>> brackets need to be reverted to their non-percent-encoded form on the >>> HTTP server in order to be compliant with RFC7252 that uses IP-literal >>>from RFC3986 for the host component. This is not specified anywhere in >>> the document. >> >> Thanks! Would a note in section 5.3.2 work for you? >> >> OLD: >> >> When the authority of the Target CoAP URI is given as an IPv6address, >> then the surrounding square brackets must be percent-encoded in the >> Hosting HTTP URI, in order to comply with the syntax defined in >> Section 3.3. of [RFC3986] for a URI path segment. E.g.: >> coap://[2001:db8::1]/light?on becomes >> http://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. >> >> >> Everything else can be safely copied verbatim from the Target CoAP >> URI to the Hosting HTTP URI. >> >> NEW: >> >> >> When the authority of the Target CoAP URI is given as an IPv6address, >> then the surrounding square brackets must be percent-encoded in the >> Hosting HTTP URI, in order to comply with the syntax defined in >> Section 3.3. of [RFC3986] for a URI path segment. E.g.: >> coap://[2001:db8::1]/light?on becomes >> http://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. >> >> Note that the percent-encoded square brackets shall be reverted to >> their non-percent-encoded form when the HC proxy unpacks the Target >> CoAP URI. >> >> >> Everything else can be safely copied verbatim from the Target CoAP >> URI to the Hosting HTTP URI. >> >> >> >> >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Just thinking out loud here (Maybe I am being paranoid). There does not >>> seem to be any kind of limitations on the IPv6 address part of the coap >>> URI. What stops someone from sticking in a multicast address into the >>> coap URI (such as the FF0X::FD All CoAP Nodes address) to use the proxy >>> as DoS attack amplifier? >> >> It makes no difference how the host is specified in the CoAP URI (as an >> IP-literal, IPv4 or "registered name"). It still has to be resolved to >>an >> IP address, and as soon as it's resolved the HC proxy can test if >> IN6_IS_ADDR_MULTICAST or IN_MULTICAST. If it is, then the security >> consideration in section 10.1 apply: "It is RECOMMENDED that the >>requestor >> of a multicast resource is strongly authenticated." >> >> Does that address your concern? >> >> Cheers, t From nobody Wed Sep 28 02:01: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 76BA712B576; Wed, 28 Sep 2016 02:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UsH4zAa0ZJi; Wed, 28 Sep 2016 02:01:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0770212B571; Wed, 28 Sep 2016 02:01:02 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 1262EF43D98AF; Wed, 28 Sep 2016 09:00:47 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8S90maA001639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2016 09:00:48 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 u8S90FAs004021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Sep 2016 11:00:45 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Wed, 28 Sep 2016 11:00:16 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGOMmqJGZdwxHo0KUnSXzA8AjWqCOiuIA Date: Wed, 28 Sep 2016 09:00:16 +0000 Message-ID: References: <147499669802.4576.11301612130873686304.idtracker@ietfa.amsl.com> In-Reply-To: <147499669802.4576.11301612130873686304.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.6.8.160830 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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: Wed, 28 Sep 2016 09:01:07 -0000 Hi Stephen, On 27/09/2016 18:18, "Stephen Farrell" wrote: >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >I don't get why you don't at least RECOMMEND that HTTP requests need to >be authenticated? We haven't done it because it is not generally applicable. Two examples: - Reverse HC proxy that bridges a legacy HTTP controller to CoAP actuators; - Transparent HC proxy boxes tout court. The idea being that we would state which specific cases need user auth in the security/privacy consideration section and do the RECOMMENDation there. (If you think there's anything missing, please suggest and we will add.) >And I don't get why you don't REQUIRE HC implementations support some >form(s) of strong-ish user authentication. The main issue I see with that is that saying "MUST use some form of user auth" without specifying which exact form of user auth we want the box to implement is equivalent to say nothing in terms of interop -- except we are using more words ;-) The other thing is the transparent HC box that just can't do that. The way I see this is that there exist (lots of) use cases where either the box implements strong user auth (and by that I mean mutual auth TLS) or it is just not fit for the purpose. Therefore a box vendor has an incentive to ship boxes that do strong user auth, but if it doesn't because its market segment doesn't need that, then fair enough. >We are seeing fairly major botnets being built from the kinds of device >that might use CoAP and (with careless implementations all around) this >could provide a nice way to expose those to the Internet. Isn't a good >bit more caution needed in what we describe here? This is very interesting. Could you suggest text to add to the security considerations that cover this topic (or pointers to literature)? Cheers & thanks a lot for the discussion so far. t From nobody Thu Sep 29 00:04: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 2B35512B05D; Thu, 29 Sep 2016 00:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, 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 1tyYeAU4nHoI; Thu, 29 Sep 2016 00:04:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 0BEF712B018; Thu, 29 Sep 2016 00:04:09 -0700 (PDT) Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MFPyK-1bjwwN0ukm-00EP7t; Thu, 29 Sep 2016 09:04:07 +0200 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG" References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55dafe15-0fa8-9510-db78-0ab1e4f6ef29@gmx.net> Date: Thu, 29 Sep 2016 09:04:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iEtpjS0v0DX2uIxpM5NcKcGEnE3pagJJr" X-Provags-ID: V03:K0:GJd+7DBNlAgLLV8UF3x/T6IRIAZEAiWZJLJ6CIkwNE5agaO0Vc8 LKd9HZOXcNpW82oT0nXkrpcwYNRL/6/f+j7FdLgW8P+h9IqGM7+JwKnQx9I5JsxKsCKSWJk fOR4AdhxTbLMtrXWAdUF4wg5RidkEjWI9A18lzUVafVViIJdIEgWM+6kcZ4aXjQeoWwvt3d ggnsGkhnmitq0e3wMUCcw== X-UI-Out-Filterresults: notjunk:1;V01:K0:pYZvSGCXPkI=:eDx77hUBqjUKarw0o0XFWC PSRBAiXKSkB4ZU+oZotEYef2Wm/WAT43EOUmqmjFG+UBmyg406ZETbeV0CyjbMMW0iHAu78Sv pkyXfMH4lZZKas5KLhx6JdNghg6IGiWpW0F3wQVbR6hImnp+wtl3LJq48oYwKiwqbXGD1TPjc 2okU3nXRzpNjEjxwxpPP0Syml/BRO7cZjJ0ZeUbO3Xot6N40mfsKufNFbSWDT/FtZVH9K8pj4 1XrIwIntmuX+jTZ7tRyHVgcOk3CfCzCiI8nYCM3Pnwezha9WVMvvT7iny6qel3zL2HoNLmRAu j9eoupyNA3+CMlLVJizjMa45V31uOxFbLqtJOoNE+Zh49rK7kD9HUAUL4NIsPp7aKXXNXdVcD wSponcEk5ILn9dMQnGIiNcoSV+B9mc8azLkw+rBvse7LjGZ+pfOHGc3rqBRDj+zArzbqpFDQt sgmCuYMXVAWWpapi4FvlKSxuNc0k9xgq0NcaIAUyQ7ZocugX2OF6f+LlIGQGvdJTatmcjXllL HimMMxFznFpAT1QGoR9R3QUrWOWE8tp0U7bl3AjMDsDrmJjRseU1kl+Qllt1kY2SvoD7pPRj7 BBBjnu4yINPXEWwrsXMzVAImqEpNUbZn/RUKMnJoSyjUlgmNjtuaJGxi04Szgu0dPJ+vjzaIN ZEtWXMOH7IBSw5Zwh/rCIxnmTtkBRQARbodWRkWdr9g9lbsTgbedezAAR8Vmo20E5bt83CDd7 4iXBb5slFZBOflKMmVWPRBH75anwhkixBljp49zvkQEVaPW4q1I91k5GYmw= Archived-At: Cc: "draft-groves-core-dynlink@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-groves-core-dynlink?= 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 Sep 2016 07:04:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iEtpjS0v0DX2uIxpM5NcKcGEnE3pagJJr Content-Type: multipart/mixed; boundary="1eLjR4M4sk3QUHBH0orVvdg9gnrFjtprS"; protected-headers="v1" From: Hannes Tschofenig To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG" Cc: "draft-groves-core-dynlink@ietf.org" Message-ID: <55dafe15-0fa8-9510-db78-0ab1e4f6ef29@gmx.net> Subject: =?UTF-8?Q?Re:_[core]_=f0=9f=94=94_Working_Group_Adoption_call_for_d?= =?UTF-8?Q?raft-groves-core-dynlink?= References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> In-Reply-To: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> --1eLjR4M4sk3QUHBH0orVvdg9gnrFjtprS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jaime, I missed this call for adoption. I am in favor of having the document adopted for 2 reasons: 1) First, the content of this draft was contained in the draft-ietf-core-interfaces-05. For this reason I am actually wondering why we do a call for adoption in the first place since we are only doing a document management action here (separating the content into two documents). 2) Second, as Christian already mentioned the functionality is part of the LWM2M version 1.0 specification and we would prefer to have a corresponding IETF document. Ciao Hannes On 08/15/2016 05:05 PM, Jaime Jim=E9nez wrote: > Dear CoRE-WG, >=20 > As we discussed at last IETF96, working group adoption has been > requested for draft-groves-core-dynlink. This draft is the result of a > document split and thus the initial status is that of adoption, > nevertheless that has to be confirmed on the list. Please reply with > your comments, including although not limited to whether or not you > support adoption. Non-authors are especially encouraged to comment. >=20 > Since there are several concurrent WGA calls, we will end the call > on *August 26, 2016*. >=20 > Thanks, > Jaime and Carsten >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --1eLjR4M4sk3QUHBH0orVvdg9gnrFjtprS-- --iEtpjS0v0DX2uIxpM5NcKcGEnE3pagJJr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX7LzlAAoJEGhJURNOOiAthgQH/085YkASTADhtj4kJPsMRdGc uUvQSONICaVY3RRQvSDgaPVhyvwhPfV7CHb2VI3u+VpeHnSsV4YrgoNn+g5nZn6k 0cCSYVxeu7+nG5OEpQIh5KOZhPutmQkMZ/E12X8Y2rsDB1rvJI22kI6AZF4Zx6TE hQKWrp+HxrieX5L0t+fh9NpIxbJv87xNRtKmwMsL2lO1Isy2HMB981atB8Tv/WW5 gWP6ibTNzD+3OzyKMnmyNqyPQGyYOGDPTfGMkapkgkYpEigewbSOyOOXh/n+VWRx e2nYkjSI1DdW7oVkMyfaO/a9XpKA7G9DXXPanu1a1iAUplt53qhfxc4vH2sX7Po= =mwaj -----END PGP SIGNATURE----- --iEtpjS0v0DX2uIxpM5NcKcGEnE3pagJJr-- From nobody Thu Sep 29 00:10: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 0E07A12B074; Thu, 29 Sep 2016 00:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, 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 jVCdb_eDieHe; Thu, 29 Sep 2016 00:10:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 D34F312B05D; Thu, 29 Sep 2016 00:10:21 -0700 (PDT) Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MPppG-1buRA10dta-0051jQ; Thu, 29 Sep 2016 09:10:19 +0200 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG" References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> <55dafe15-0fa8-9510-db78-0ab1e4f6ef29@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 29 Sep 2016 09:10:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <55dafe15-0fa8-9510-db78-0ab1e4f6ef29@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PAXBMF1NiGNW1fm4nR42BsKsHoqCw5XKx" X-Provags-ID: V03:K0:5DYN3KqetZBrL0YR5rFIi2LfElAJs0XC7DBHvRhul8qN7EbQFg5 VPAkWY1yvfeUQmWuQlYzxKqylnZYxkI9U1bL7sa2Ku/hAssZ6Gr2+ehXBP8Jq06nQb/sKuP Faut1eUPKlgIO3KTP8Ab7GQrWT4imcKWZXNl4mdt7MxeLF9yhf5JMVK811b6UrWMzaqubkE bhtBxAlHziDaD8kOekEyQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:kA2mLkLKDHg=:/fv2YNS23EFzVOP5N/86Ef tZNpMCcH5c/s1enrLbVWcKfb8SkG8UU+x7eROT2N6J1aANvdDl65Ve5AfqZu2YAMCHKWXg6/Z QpBwXjXyq7qYA1PdyrbWkLy3GuNJz1Yzd2d5NpAiPc0Blfb43FmvXxjOju45UDVqLp1nmgVlZ pFo67ot/kOJKNAINm2+lwG8rLA0TamK8lAK+wAInFcmwO4J4KJBxV3PE8UxnEaqwVuPjuJ6IF XYGDFEhr4oCyulD6NRfcoAwI5Jvn7368ffC3oEyH0we7dSSSAC8ubELmoALOdh3QY3dgAwKDg eJ+ERtBMYiejOrYJqdjTOFPXilxavO0n+5j0XGAJiYyr9R2xNimo7fVxTvDl+i9ZFIcFBKY8S oqt7pSGNlZjPsPjoOHCrAl0aFOSIwX4+W2GAkHfkZQRlsF1mAEUVWHoyf/+A0X2FDeWlIlkDg iZmWhtDeYDtqC1bVfuJo8D/J2Zl2K4OOgZjVZA9umHLQVcRcECR83JGSfE21xdppYq4pKq9pQ YIgiEB/T5/95huNPFsO4x868tHMEIvj9PnFWmy5SoXUcVjUWP+Mc7ndv98eaRkVKmaTVldAf/ zkj8mjxCwXeQ7enXX9DVCs1zNf+1KCHuOhr6mxfdSp/mPn5f6aGby48V1t5ZrPdc8YgkI3WBh piF02zeQQ2KJxAIqSp1KEw9CMrLvkV+bxswBXpHB2Ij6qG/2YeoTpR/Ofhz/YOOuVeHCkGVBL wRRCL26sVdRFW87IOvK33aKHLv9RA3xwwKZ9yZEw/Qy2ddtqv6gFTBG1un8= Archived-At: Cc: "draft-groves-core-dynlink@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-groves-core-dynlink?= 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 Sep 2016 07:10:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PAXBMF1NiGNW1fm4nR42BsKsHoqCw5XKx Content-Type: multipart/mixed; boundary="j28KBWmomuMdeBkL14tx6b1tjHfjvxcP7"; protected-headers="v1" From: Hannes Tschofenig To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG" Cc: "draft-groves-core-dynlink@ietf.org" Message-ID: Subject: =?UTF-8?Q?Re:_[core]_=f0=9f=94=94_Working_Group_Adoption_call_for_d?= =?UTF-8?Q?raft-groves-core-dynlink?= References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> <55dafe15-0fa8-9510-db78-0ab1e4f6ef29@gmx.net> In-Reply-To: <55dafe15-0fa8-9510-db78-0ab1e4f6ef29@gmx.net> --j28KBWmomuMdeBkL14tx6b1tjHfjvxcP7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One other note about the usefulness of the functionality of this document= =2E draft-groves-core-dynlink defines attributes for use with observe, namely= - Minimum Period - Maximum Period - Change Step - Greater Than - Less Than These are obviously important for making CoAP observe usable in IoT scenarios since otherwise you will unnecessarily generate a lot of traffi= c. Since I find this functionality essential for CoAP observe I prefer to have these attributes documented in an RFC. Ciao Hannes On 09/29/2016 09:04 AM, Hannes Tschofenig wrote: > Hi Jaime, >=20 > I missed this call for adoption. I am in favor of having the document > adopted for 2 reasons: >=20 > 1) First, the content of this draft was contained in the > draft-ietf-core-interfaces-05. For this reason I am actually wondering > why we do a call for adoption in the first place since we are only doin= g > a document management action here (separating the content into two > documents). >=20 > 2) Second, as Christian already mentioned the functionality is part of > the LWM2M version 1.0 specification and we would prefer to have a > corresponding IETF document. >=20 > Ciao > Hannes >=20 >=20 > On 08/15/2016 05:05 PM, Jaime Jim=E9nez wrote: >> Dear CoRE-WG, >> >> As we discussed at last IETF96, working group adoption has been >> requested for draft-groves-core-dynlink. This draft is the result of a= >> document split and thus the initial status is that of adoption, >> nevertheless that has to be confirmed on the list. Please reply with >> your comments, including although not limited to whether or not you >> support adoption. Non-authors are especially encouraged to comment. >> >> Since there are several concurrent WGA calls, we will end the call >> on *August 26, 2016*. >> >> Thanks, >> Jaime and Carsten >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >=20 --j28KBWmomuMdeBkL14tx6b1tjHfjvxcP7-- --PAXBMF1NiGNW1fm4nR42BsKsHoqCw5XKx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX7L5aAAoJEGhJURNOOiAt62kH/RrAhFussj0ge5yg7QDMX9yX SGresPJxWvH0FeH8THYVDfXtWVItXiKkwmZNvm5xuUFTfyzB3GkEoxlkGWQmXLrr ApjhMJz35AL3P7pwlnBB6pfsKrmpN4Kx0Vaw3sY6yXg62PCSX2Rc3QY8FbmVowx8 KUgjHIXFu/doQjFNC4xBvqNicaNg0GEaUG/xxX0fZ7EfcjQCbuRsRKSMjsdA7d8C Dvp3758t5U7OFiklY2U3x4lz5nr9XS//xVLAqmSaZxesQ13hTrdxAB5ynwLoQz9k JWA5JD2iXCoT6S9e1KpG5zm6x53IkhHyclw4s+5+2Jee6FV+h7atMVJrzdkh+7Q= =yKS+ -----END PGP SIGNATURE----- --PAXBMF1NiGNW1fm4nR42BsKsHoqCw5XKx-- From nobody Thu Sep 29 04:32:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13E12B425 for ; Thu, 29 Sep 2016 04:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Wkwfk4A-aeik for ; Thu, 29 Sep 2016 04:32:31 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 5A93D12B110 for ; Thu, 29 Sep 2016 04:32:31 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 5A16D53946065 for ; Thu, 29 Sep 2016 11:32:28 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u8TBWTPo018861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Sep 2016 11:32:30 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u8TBWTKs021952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Sep 2016 11:32:29 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Thu, 29 Sep 2016 07:32:29 -0400 From: "Carey, Timothy (Nokia - US)" To: "core@ietf.org WG" Thread-Topic: draft-groves-core-dynlink adoption Thread-Index: AdIaRSf6gR7eQhJOSw+uid95dC53/g== Date: Thu, 29 Sep 2016 11:32:28 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A78491E@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A78491EUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [core] draft-groves-core-dynlink adoption 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 Sep 2016 11:32:33 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A78491EUS70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nokia is +1 for adoption BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A78491EUS70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nokia is +1 for adoption

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A78491EUS70UWXCHMBA0_-- From nobody Thu Sep 29 07:02: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 437DC12B14F; Thu, 29 Sep 2016 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzuGkFoDtCpI; Thu, 29 Sep 2016 07:02:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E6D12B544; Thu, 29 Sep 2016 07:02:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A2B5BE4D; Thu, 29 Sep 2016 15:02:45 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUP1C03tuVNu; Thu, 29 Sep 2016 15:02:45 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DC2EBBE47; Thu, 29 Sep 2016 15:02:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475157765; bh=NbylOF0LQKauzc4BgdeD2hquL/PF3eolZnSZDpJaFqI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=PGCDU9aAjwJIwexZ1lnBp6vxiV0UehXOZ4cZgx5n1BRFVCME2H0LnVudcpE6FpiGx dZnfCPL2Z0+LELS29xhU9IPKR50vrNSqfKxN90xR8OvHKsEzDtRmEgzB63mXzxp1pP wkNn7fhOQCSm2O5C4VbdlkbThh58EEoOcUNJlGKs= To: "Fossati, Thomas (Nokia - GB)" , The IESG References: <147499669802.4576.11301612130873686304.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 29 Sep 2016 15:02:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040500010902020103060706" Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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, 29 Sep 2016 14:02:55 -0000 This is a cryptographically signed message in MIME format. --------------ms040500010902020103060706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thomas, On 28/09/16 10:00, Fossati, Thomas (Nokia - GB) wrote: > Hi Stephen, >=20 > On 27/09/2016 18:18, "Stephen Farrell" wrot= e: >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> I don't get why you don't at least RECOMMEND that HTTP requests need t= o >> be authenticated? >=20 > We haven't done it because it is not generally applicable. =20 I guess I'm surprised by that. I would have thought that the most applicable case was a proxy to a sensor that may be dealing with privacy sensitive data or to an actuator that is very likely to be security sensitive. (Which is why I'd argue for a "SHOULD be authenticated" for example.) > Two examples: > - Reverse HC proxy that bridges a legacy HTTP controller to CoAP actuat= ors; > - Transparent HC proxy boxes tout court. How about 47000 counter examples? [1] :-) [1] https://blog.sucuri.net/2016/09/iot-home-router-botnet-leveraged-in-large= -ddos-attack.html >=20 > The idea being that we would state which specific cases need user auth = in > the security/privacy consideration section and do the RECOMMENDation > there. (If you think there's anything missing, please suggest and we= > will add.) But why not reverse the logic and say "MUST be authenticated unless..." Seems a lot safer to me tbh. >=20 >> And I don't get why you don't REQUIRE HC implementations support some >> form(s) of strong-ish user authentication. >=20 > The main issue I see with that is that saying "MUST use some form of us= er > auth" without specifying which exact form of user auth we want the box = to > implement is equivalent to say nothing in terms of interop -- except we= > are using more words ;-) That's an issue yes. But I figure we could word around that as mostly it'll be a shared secret over a server-auth TLS and with cookies thereafter. That's a little sad but quite doable. (Well, modulo getting a cert for the http server where there are deployment but not interop problems.) > The other thing is the transparent HC box that just can't do that. >=20 > The way I see this is that there exist (lots of) use cases where either= > the box implements strong user auth (and by that I mean mutual auth TLS= ) > or it is just not fit for the purpose. Therefore a box vendor has an > incentive to ship boxes that do strong user auth, but if it doesn't > because its market segment doesn't need that, then fair enough. See [1]. I think we have to factor in the lowish quality of lots of implementations in this space. >=20 >> We are seeing fairly major botnets being built from the kinds of devic= e >> that might use CoAP and (with careless implementations all around) thi= s >> could provide a nice way to expose those to the Internet. Isn't a goo= d >> bit more caution needed in what we describe here? >=20 > This is very interesting. Could you suggest text to add to the securit= y > considerations that cover this topic (or pointers to literature)? Sure. Haven't time right now but happy to help with text and references. S. >=20 >=20 > Cheers & thanks a lot for the discussion so far. > t >=20 --------------ms040500010902020103060706 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 CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5Mjkx NDAyNDVaMC8GCSqGSIb3DQEJBDEiBCA0Jiu8GNXiY/IaTKgRjq5W8sJ3jQW3UHi1Q+2TZRQ1 aTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCILtW9buKIWeDOI+5kMfUagrdOUw6/M302GRyU4XGNxtFKjLI3Xust Qlcf3zfmsq6cATTFhqvjuMt5MS9eQ2UDjcCVD1nuwqTgLSEDuxAsPCv38kUzAI5xOSCuwwlT 58qanU1UGnoRhieBuEmzN2q4VV238i9jnZACbqOCdl6i+Bi9LrdEPcPM4O1KFifvXuyaFMXT o8+ReUpad4qhFHXTJYD3f4V5ntomSvtkbYA+lwziit206XzYViGmAI/Vjs4hIKAjFVBPfvrO bHII9BMBp/gdfw/ZRd+lBY5ETedqaHsVpEwAHGsYAPup93GXZ7mHxy92C216Tv72T7/PBj7p AAAAAAAA --------------ms040500010902020103060706-- From nobody Thu Sep 29 08:47: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 DEBD312B19B; Thu, 29 Sep 2016 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghHt3mgEcQEm; Thu, 29 Sep 2016 08:47:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD73312B18C; Thu, 29 Sep 2016 08:47:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 65122BE4D; Thu, 29 Sep 2016 16:47:17 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62deoC9py-ML; Thu, 29 Sep 2016 16:47:17 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A66E9BE3E; Thu, 29 Sep 2016 16:47:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475164037; bh=deteqVYKgBoTeJONx5u9nne1Km0NEJ9eL1iLS+dbZ5k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=h/oZ0VrMhYW1r6iCpjLAvQT2Ja9jZ9o7yfkGwA16kKpemCDETaQKoARU3ZJSMJFnE LK6QWgGdGiTNLalAGB9c1m0JJuaQCE/T7PDM9frlqI3drmlMn620W7sPgYDAigf2VH bUtP/9sj4UtVJG6c9UiztRdSgOn9+dYTfXtFhtI0= To: "Fossati, Thomas (Nokia - GB)" , The IESG References: <147499669802.4576.11301612130873686304.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 29 Sep 2016 16:47:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050503040202020404070506" Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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, 29 Sep 2016 15:47:23 -0000 This is a cryptographically signed message in MIME format. --------------ms050503040202020404070506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/09/16 00:16, Fossati, Thomas (Nokia - GB) wrote: > Hi Stephen, >=20 > I'm only going through the COMMENTS section for now since that looks > easier than the DISCUSS :-) >=20 > On 27/09/2016 18:18, "Stephen Farrell" wrot= e: >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> >> I don't get why you don't at least RECOMMEND that HTTP >> requests need to be authenticated? And I don't get why you >> don't REQUIRE HC implementations support some form(s) of >> strong-ish user authentication. We are seeing fairly major >> botnets being built from the kinds of device that might use >> CoAP and (with careless implementations all around) this >> could provide a nice way to expose those to the Internet. >> Isn't a good bit more caution needed in what we describe >> here? Note: I'm not saying HTTP authentication, nor >> specifically TLS client auth. >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> 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. >=20 > I understand this concern in principle, but from a practical standpoint= > I'm not super convinced that the surface it introduces is large enough = to > deserve mentioning. Currently, CoAP defines 8 different content format= s. > So, worst case, the amplification would be x7 on the first request, the= n > caching should kick in (since 4.06, like all 4.xx, is cacheable) and th= e > HC proxy would then absorb any equivalent request (until max-age expire= s). > (The reasoning above should be fine provided the HC proxy default-denie= s > forwarding HTTP requests with "application/coap-payload" -- as you sugg= est > below.) Fair enough I guess. >=20 >> - 6.1: What "other forms of access control" do you mean? >=20 > I guess you mean "other" is weirdly placed in that sentence? It should= > probably just say: "some form of access control". >=20 >> - 6.2: This looks like it allows too large an attack surface >> and maybe you ought default to denying >=20 > I guess you are referring to the last para: "A HTTP client may use the > media type "application/coap-payload" [...]"? If so, nice catch! >=20 > OLD: >=20 > A HTTP client may use the media type "application/coap-payload" as a > means to send a specific content format to a CoAP server via a HC > Proxy if the client has determined that the HC Proxy does not > directly support the type mapping it needs. This case may happen > when dealing for example with newly registered, yet to be registered= , > or experimental CoAP content formats. >=20 >=20 > NEW: >=20 > A HTTP client may use the media type "application/coap-payload" as a > means to send a specific content format to a CoAP server via a HC > Proxy if the client has determined that the HC Proxy does not > directly support the type mapping it needs. This case may happen > when dealing for example with newly registered, yet to be registered= , > or experimental CoAP content formats. However, unless explicitly > configured to allow pass-through unknown content formats, the HC > proxy SHOULD NOT forward requests carrying a Content-Type or Accept > header with an "application/coap-payload", and return an appropriate= > client error (4xx) instead. >=20 >=20 >> - 6.5: Transcoding bugs galore! Given the history of bugs in >> transcoding libraries shouldn't you recommend some caution >> here? >=20 > It looks like a sensible advice, but I'm not sure what to write exactly= =2E > This might be covered by the "quality of implementation" argument in th= e > diff I sent previously to address Kathleen's DISCUSS? >=20 >> And are there forms of zipbomb that might cause >> problems? >=20 > Yes, probably worth pointing out that a JSON->CBOR transcoder might > inflate [1]. >=20 > [1] https://tools.ietf.org/html/rfc7049#section-4.2 All the above are fine. >=20 >> - 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. >=20 > Sorry, I don't understand why you think that that wouldn't define an > unambiguous decision criterion? > In practice, you start Observing a given resource and track: > - the frequency of the updates on the CoAP side, and > - the inter-arrival time of the requests targeting that same resource o= n > the HTTP side. > After a while the formula allows you to decide whether the resource is > popular enough -- and so you should keep on observing it -- or if it's > better to unsubscribe and go back to Etag revalidation. The above would define it well, but (iirc) the text didn't actually say that clearly (where that =3D=3D a decision). Maybe take another look and see if some of the text you wrote above might help? Cheers, S. >=20 >> - 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." ? >=20 > I think the sentence just below that should provide an example (firewal= l): >=20 > "Assuming that CoAP nodes are isolated behind a firewall as in the HC > proxy deployment shown in Figure 1, the HC proxy may be configured to > translate the incoming HTTPS request using plain CoAP (NoSec mode)." >=20 >=20 > Cheers and thanks! > t >=20 --------------ms050503040202020404070506 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 CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5Mjkx NTQ3MTdaMC8GCSqGSIb3DQEJBDEiBCBo8dl+itrV+M8wj3hBdOVJLYET1acgbXHk4hDBEZbq UTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAYBcR7Sy3oyl4P4ZaMAUgP8STjJHxX21FIQgXek0vEO0HWo/nx/eTH T9MeiWHbolu/rgDjB1RMQWyZjB7zKRh22Qa7pFLIN0WF1GS/ztapIvP5yc9Z0e7HGz4ODOd1 39UyVA8uqxJxfeCJeWwmr7l8IcflVIQIZPGpfpxgBrBBgk4CVSUDTjS0xjVpgsGbW6lWXdEM SZE2oBivd+tkPjIL2ZxRHF7gf7rfOF4CK2GWFeI3LxmRpRj/OnnWxkmac1xC/rrB0vOF/XCm Ldq4Y4mWboh4mLXmGlC64KmEm0Q7jvehLEARg8hlmoa/MOU5kyKG9hO5uCmCBcSMoXgf2OFz AAAAAAAA --------------ms050503040202020404070506-- From nobody Thu Sep 29 16:57:57 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 E4F7312B13B; Thu, 29 Sep 2016 16:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=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 DjqAEZ_JbnV4; Thu, 29 Sep 2016 16:57:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FD012B09C; Thu, 29 Sep 2016 16:51:54 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 29F7A58BE73A9; Thu, 29 Sep 2016 23:51:48 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8TNpqss017182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2016 23:51:52 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u8TNpqmL019831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Sep 2016 01:51:52 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Fri, 30 Sep 2016 01:51:52 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Spencer Dawkins , The IESG Thread-Topic: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGQ6m8SAo/UHADkCUO8OCqQpJJ6CRFfwA Date: Thu, 29 Sep 2016 23:51:51 +0000 Message-ID: References: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> In-Reply-To: <147501537986.11800.1149988617235818479.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.6.8.160830 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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, 29 Sep 2016 23:57:56 -0000 Hi Spencer, Thanks very much for your review and sorry for my late reply. On 27/09/2016 23:29, "core on behalf of Spencer Dawkins" wrote: >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >This is going to be a Yes position after we talk, of course ... > >Someone can tell me to relax, but I found this text > > When found in a Hosting HTTP URI, the scheme (i.e., "coap" or > "coaps"), the scheme component delimiter (":"), and the double slash > ("//") preceding the authority MAY be omitted. In such case, a local > default - not defined by this document - applies. > > So, http://p.example.com/hc/s.coap.example.com/foo could either > represent the target coap://s.coap.example.com/foo or > coaps://s.coap.example.com/foo depending on application specific > presets. > =20 >worrisome - is it saying that if you leave off the scheme, you don't know >whether the resulting mapped URI is coap:// or coaps://? That's right -- for the "simple form". However, the choice to omit the scheme is either taken unilaterally by the client (and therefore it is going to get what it deserves, most probably a 4xx error straight from the proxy), or it's agreed upon between the HC proxy and the client out of band. The latter is the way one vendor implemented it, and what the text documents. (The OOB agreement could be such that coaps URIs are anchored to hc-proxy.example.com/secure whereas coap URIs are sent to hc-proxy.example.com/plain-text.) >If so, how critical is it that this isn't deterministic? For the reasons given above, it doesn't look that dodgy to me. >Can the HTTP client tell whether the result used coaps://? No, if it's using the simple form and there is no OOB agreement. So, I guess the question is: do you think it'd be better to spell this out explicitly? If so, we could say that a Target CoAP URI without the scheme is not allowed unless there is an OOB agreement between client and HC proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). Or do you have something different in mind? >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >In this text from the Abstract, > > This document > covers the Reverse, Forward and Interception cross-protocol proxy > cases. > =20 >are Reverse, Forward, and Interception proxys so well understood that the >average reader would know what you're talking about? I'd hope so, but case [s]?he isn't, in section 2 we provide succinct definitions for each of the proxy types plus references to RFC 7230, 7252 and 3040. >Do I understand that they're defined directly in this document, not >referencing some other draft? See above. >Further in the document, I see this text, > > Note that the guidelines apply to all forms of an HC proxy (i.e., > Reverse, Forward, Intercepting) unless explicitly otherwise noted. > =20 >which makes me wonder if you need to mention the various forms of HC >proxy in the Abstract at all ... Sorry, I don't understand the issue :-( >This text, > > Note that a Reverse Proxy appears to an HTTP client as an origin > server while a Forward Proxy does not. So, when communicating with a > Reverse Proxy a client may be unaware it is communicating with a > proxy at all. > =20 >would be clearer if it followed the definition of Reverse Proxy. Yes, it's probably better as you suggest. Will move the block. >Confusingly, aren't clients unaware they're communicating with an >Interception Proxy, as well? mmm, clients aren't "communicating" with an Interception Proxy, it's just a middle-box. >It's easy for me to read this text, > > See Figure 1 for an example deployment scenario. Here a HC proxy is > located at the boundary of the Constrained Network domain, to avoid > sending any HTTP traffic into the Constrained Network and to avoid > any (unsecured) CoAP multicast traffic outside the Constrained > Network. =20 > =20 >as saying that secured CoAP multicast traffic might be sent outside the >Constrained Network. Is that what you meant? No, it's not what we meant. We'll remove "(unsecured)". >In this text, > > The HC proxy is furthermore > configured to only pass through GET requests in order to protect the > constrained network. > =20 >did you mean "GET requests and their corresponding responses"? Yes, yes. I'm not sure adding that explicitly makes it clearer though. >In this text, > > The default URI mapping function SHOULD be implemented and activated > by default in a HC proxy, unless there are valid reasons, e.g., > application specific, to use a different mapping function. > =20 >I found myself wondering if you could point to a valid use of a different >mapping function. That would have been helpful to me. I guess a non-default mapping would be handy if the proxy needs more freedom when setting up its URI namespace. >In this text, > > However, it should be noted that in certain cases, transcoding can > lose information in a non-obvious manner. For example, encoding an > XML document using schema-informed EXI encoding leads to a loss of > information when the destination does not know the exact schema > version used by the encoder, which means that whenever the HC proxy > transcodes an application/XML to application/EXI in-band metadata > could be lost. Therefore, the implementer should always carefully > verify such lossy payload transformations before triggering the > transcoding. > =20 >I didn't understand how you "verify" payload transformations. Is that a >well-understood term of art for the community? I'm leaving it for later as I need to check it with my co-authors. Thanks again, cheers, t From nobody Fri Sep 30 02:50: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 CCE0E12B08D; Fri, 30 Sep 2016 02:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5OeY9bBQnnX; Fri, 30 Sep 2016 02:50:07 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B348A12B02B; Fri, 30 Sep 2016 02:50:07 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 6AF7D5708A538; Fri, 30 Sep 2016 09:50:03 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8U9o4ft001024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2016 09:50:05 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u8U9o1ag024299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Sep 2016 11:50:04 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Fri, 30 Sep 2016 11:50:02 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Stephen Farrell , "Fossati, Thomas (Nokia - GB)" , The IESG Thread-Topic: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGOMmqJGZdwxHo0KUnSXzA8AjWqCN57iAgAKWfYCAAT9EgA== Date: Fri, 30 Sep 2016 09:50:01 +0000 Message-ID: References: <147499669802.4576.11301612130873686304.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <65FC2160C2CF3A4D9E4A184F04A3F322@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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, 30 Sep 2016 09:50:11 -0000 Hi Stephen, On 29/09/2016 16:47, "core on behalf of Stephen Farrell" wrote: >>>- 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. >>=20 >> I understand this concern in principle, but from a practical standpoint >> I'm not super convinced that the surface it introduces is large enough >>to >> deserve mentioning. Currently, CoAP defines 8 different content >>formats. >> So, worst case, the amplification would be x7 on the first request, then >> caching should kick in (since 4.06, like all 4.xx, is cacheable) and the >> HC proxy would then absorb any equivalent request (until max-age >>expires). >> (The reasoning above should be fine provided the HC proxy default-denies >> forwarding HTTP requests with "application/coap-payload" -- as you >>suggest >> below.) > >Fair enough I guess. > >>=20 >>> - 6.1: What "other forms of access control" do you mean? >>=20 >> I guess you mean "other" is weirdly placed in that sentence? It should >> probably just say: "some form of access control". >>=20 >>> - 6.2: This looks like it allows too large an attack surface >>> and maybe you ought default to denying >>=20 >> I guess you are referring to the last para: "A HTTP client may use the >> media type "application/coap-payload" [...]"? If so, nice catch! >>=20 >> OLD: >>=20 >> A HTTP client may use the media type "application/coap-payload" as a >> means to send a specific content format to a CoAP server via a HC >> Proxy if the client has determined that the HC Proxy does not >> directly support the type mapping it needs. This case may happen >> when dealing for example with newly registered, yet to be registered, >> or experimental CoAP content formats. >>=20 >>=20 >> NEW: >>=20 >> A HTTP client may use the media type "application/coap-payload" as a >> means to send a specific content format to a CoAP server via a HC >> Proxy if the client has determined that the HC Proxy does not >> directly support the type mapping it needs. This case may happen >> when dealing for example with newly registered, yet to be registered, >> or experimental CoAP content formats. However, unless explicitly >> configured to allow pass-through unknown content formats, the HC >> proxy SHOULD NOT forward requests carrying a Content-Type or Accept >> header with an "application/coap-payload", and return an appropriate >> client error (4xx) instead. >>=20 >>=20 >>> - 6.5: Transcoding bugs galore! Given the history of bugs in >>> transcoding libraries shouldn't you recommend some caution >>> here? >>=20 >> It looks like a sensible advice, but I'm not sure what to write exactly. >> This might be covered by the "quality of implementation" argument in the >> diff I sent previously to address Kathleen's DISCUSS? >>=20 >>> And are there forms of zipbomb that might cause >>> problems? >>=20 >> Yes, probably worth pointing out that a JSON->CBOR transcoder might >> inflate [1]. >>=20 >> [1] https://tools.ietf.org/html/rfc7049#section-4.2 > >All the above are fine. OK >>=20 >>> - 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. >>=20 >> Sorry, I don't understand why you think that that wouldn't define an >> unambiguous decision criterion? >> In practice, you start Observing a given resource and track: >> - the frequency of the updates on the CoAP side, and >> - the inter-arrival time of the requests targeting that same resource on >> the HTTP side. >> After a while the formula allows you to decide whether the resource is >> popular enough -- and so you should keep on observing it -- or if it's >> better to unsubscribe and go back to Etag revalidation. > >The above would define it well, but (iirc) the text didn't >actually say that clearly (where that =3D=3D a decision). Maybe >take another look and see if some of the text you wrote >above might help? OK All these edits are now in my working copy. Cheers, thanks, t From nobody Fri Sep 30 08:07: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 B131512B165; Fri, 30 Sep 2016 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8398gt0-CWm; Fri, 30 Sep 2016 08:07:31 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7703D12B145; Fri, 30 Sep 2016 08:07:31 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id i129so70527624ywb.0; Fri, 30 Sep 2016 08:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WcG8irkvp26gxJ9+MHuyaTs5w0gVkWbw/Q9ep+875/A=; b=ihH/Hk3B0BXPyRnk8xzj0hoxOUrF4YErKoVt71f5RgUP3IBSrZ7UFJ2A0GFBho6k7Z N82OwMrQ/EsNoS5wf0vTHheWaBUYGBozMhZyCyu62jpU29ok0sus3uVrcxZ0mgVpkcPg YUCiQJMwaqHBrO0LGjGfMgOrSOAoUCq9ubw9RrpW7tbg7z8UYA/B6tJFi87VfuqJDvEL R4++Le6/0rNMR6pPlib2CQV1u5Z/7t7XHK9E9cUcoCrhPvXDD3F658hrBSox5Nk9jGJ+ yHZVuLlnDz+Tsc8P/102oM6gI0QyR7eiuzy7n9QdgfRkuY9XR+SxLMsNQBTPch7blCij Xh8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WcG8irkvp26gxJ9+MHuyaTs5w0gVkWbw/Q9ep+875/A=; b=gENEUOtRJYxFbl/Tl2T59Fu2DzhgTzynJmT6KwDUM0OY9nqF9WO2Y+g80wE8Xpjokm 3ideW+gRfLFI1MzKODisURMYrPeI0Umt3YzifT/rbhZ3dC47lF5cvolQjbCH7mP9nnGB 7TC5RwdEzTyg+2Fl+JRR9BDN4uo1/b70GdRQiax16ESQ33HbqwY0hK3x+5dO1X+Ii4y5 xz+2gjz5hEaA6yIn1l21ekcWKJgsxUKVWQOlEeDhtE9SdCvjv1wk4pElKywvqBGmSJeD 65K8tjzTgaXaMSQ6OJ7LwLqQ6AmRsIpyFT64bRZCI2MvW5HfNIw+3G3AmP1i0AyR+KTa VtQA== X-Gm-Message-State: AA6/9Rlf/EDmCSMsQ45k61aOZglRDqDRb8Db05rBf/L5pvpQMKpEPP1kvqPdEMLwe2kWLhaGn0KhrepfHIbOSw== X-Received: by 10.129.77.84 with SMTP id a81mr2764573ywb.19.1475248050654; Fri, 30 Sep 2016 08:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Fri, 30 Sep 2016 08:07:30 -0700 (PDT) In-Reply-To: References: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 30 Sep 2016 10:07:30 -0500 Message-ID: To: "Fossati, Thomas (Nokia - GB)" Content-Type: multipart/alternative; boundary=001a1140b7ac03d2b7053dbaf4a5 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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, 30 Sep 2016 15:07:38 -0000 --001a1140b7ac03d2b7053dbaf4a5 Content-Type: text/plain; charset=UTF-8 Hi, Thomas, On Thu, Sep 29, 2016 at 6:51 PM, Fossati, Thomas (Nokia - GB) < thomas.fossati@nokia.com> wrote: > Hi Spencer, > > Thanks very much for your review and sorry for my late reply. > > On 27/09/2016 23:29, "core on behalf of Spencer Dawkins" > wrote: > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >This is going to be a Yes position after we talk, of course ... > > > >Someone can tell me to relax, but I found this text > > > > When found in a Hosting HTTP URI, the scheme (i.e., "coap" or > > "coaps"), the scheme component delimiter (":"), and the double slash > > ("//") preceding the authority MAY be omitted. In such case, a local > > default - not defined by this document - applies. > > > > So, http://p.example.com/hc/s.coap.example.com/foo could either > > represent the target coap://s.coap.example.com/foo or > > coaps://s.coap.example.com/foo depending on application specific > > presets. > > > >worrisome - is it saying that if you leave off the scheme, you don't know > >whether the resulting mapped URI is coap:// or coaps://? > > That's right -- for the "simple form". However, the choice to omit the > scheme is either taken unilaterally by the client (and therefore it is > going to get what it deserves, most probably a 4xx error straight from the > proxy), or it's agreed upon between the HC proxy and the client out of > band. The latter is the way one vendor implemented it, and what the text > documents. (The OOB agreement could be such that coaps URIs are anchored > to hc-proxy.example.com/secure whereas coap URIs are sent to > hc-proxy.example.com/plain-text.) I didn't get that from "local default". Your explanation was extremely helpful. > >If so, how critical is it that this isn't deterministic? > > For the reasons given above, it doesn't look that dodgy to me. > > >Can the HTTP client tell whether the result used coaps://? > > No, if it's using the simple form and there is no OOB agreement. So, I > guess the question is: do you think it'd be better to spell this out > explicitly? If so, we could say that a Target CoAP URI without the scheme > is not allowed unless there is an OOB agreement between client and HC > proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). Or do > you have something different in mind? > That's exactly what i had in mind. It seems much less likely to result in someone making the wrong assumption. >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >In this text from the Abstract, > > > > This document > > covers the Reverse, Forward and Interception cross-protocol proxy > > cases. > > > >are Reverse, Forward, and Interception proxys so well understood that the > >average reader would know what you're talking about? > > I'd hope so, but case [s]?he isn't, in section 2 we provide succinct > definitions for each of the proxy types plus references to RFC 7230, 7252 > and 3040. Right, but our theory is that Abstracts make sense without reading the document itself. We're told there are people who publish Abstracts without providing the RFC text itself, so the definition isn't readily available. > >Do I understand that they're defined directly in this document, not > >referencing some other draft? > > See above. > > >Further in the document, I see this text, > > > > Note that the guidelines apply to all forms of an HC proxy (i.e., > > Reverse, Forward, Intercepting) unless explicitly otherwise noted. > > > >which makes me wonder if you need to mention the various forms of HC > >proxy in the Abstract at all ... > > Sorry, I don't understand the issue :-( See above. Unless there are other types of proxies, just saying "This document covers all forms of proxies." would solve that problem. > >This text, > > > > Note that a Reverse Proxy appears to an HTTP client as an origin > > server while a Forward Proxy does not. So, when communicating with a > > Reverse Proxy a client may be unaware it is communicating with a > > proxy at all. > > > >would be clearer if it followed the definition of Reverse Proxy. > > Yes, it's probably better as you suggest. Will move the block. > > >Confusingly, aren't clients unaware they're communicating with an > >Interception Proxy, as well? > > mmm, clients aren't "communicating" with an Interception Proxy, it's just > a middle-box. Ah, now I understand. But since you moved the text block forward, it's clear what you mean. > >It's easy for me to read this text, > > > > See Figure 1 for an example deployment scenario. Here a HC proxy is > > located at the boundary of the Constrained Network domain, to avoid > > sending any HTTP traffic into the Constrained Network and to avoid > > any (unsecured) CoAP multicast traffic outside the Constrained > > Network. > > > >as saying that secured CoAP multicast traffic might be sent outside the > >Constrained Network. Is that what you meant? > > No, it's not what we meant. We'll remove "(unsecured)". Thanks. > >In this text, > > > > The HC proxy is furthermore > > configured to only pass through GET requests in order to protect the > > constrained network. > > > >did you mean "GET requests and their corresponding responses"? > > Yes, yes. I'm not sure adding that explicitly makes it clearer though. You may be right :-) > >In this text, > > > > The default URI mapping function SHOULD be implemented and activated > > by default in a HC proxy, unless there are valid reasons, e.g., > > application specific, to use a different mapping function. > > > >I found myself wondering if you could point to a valid use of a different > >mapping function. That would have been helpful to me. > > I guess a non-default mapping would be handy if the proxy needs more > freedom when setting up its URI namespace. Right. I'm asking (at the non-blocking comment level) if you could give an example of why it might need more freedom. The point of a SHOULD for me is "unless you understand the consequences". A SHOULD with no explanation leaves the implementer to try to understand whether the implementer is doing something the specification writer anticipated. > >In this text, > > > > However, it should be noted that in certain cases, transcoding can > > lose information in a non-obvious manner. For example, encoding an > > XML document using schema-informed EXI encoding leads to a loss of > > information when the destination does not know the exact schema > > version used by the encoder, which means that whenever the HC proxy > > transcodes an application/XML to application/EXI in-band metadata > > could be lost. Therefore, the implementer should always carefully > > verify such lossy payload transformations before triggering the > > transcoding. > > > >I didn't understand how you "verify" payload transformations. Is that a > >well-understood term of art for the community? > > I'm leaving it for later as I need to check it with my co-authors. Sure, and thanks for checking. Spencer > Thanks again, cheers, > t > > --001a1140b7ac03d2b7053dbaf4a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Thomas,

On Thu, Sep 29, 2016 at 6:51 PM, Fossati, Thomas (Nokia - GB) <thomas.fossati@nokia.com> wrote:
Hi Spencer,

Thanks very much for your review and sorry for my late reply.

On 27/09/2016 23:29, "core on behalf of Spencer Dawkins"
<core-bo= unces@ietf.org on behalf of spencerdawkins.ietf@gmail.com> wrote:
>-------------------------------------------------------------= ---------
>DISCUSS:
>-------------------------------------------------------------= ---------
>
>This is going to be a Yes position after we talk, of course ...
>
>Someone can tell me to relax, but I found this text
>
>=C2=A0 =C2=A0When found in a Hosting HTTP URI, the scheme (i.e., "= coap" or
>=C2=A0 =C2=A0"coaps"), the scheme component delimiter ("= :"), and the double slash
>=C2=A0 =C2=A0("//") preceding the authority MAY be omitted.= =C2=A0 In such case, a local
>=C2=A0 =C2=A0default - not defined by this document - applies.
>
>=C2=A0 =C2=A0So, http://p.example.com/hc/s.co= ap.example.com/foo could either
>=C2=A0 =C2=A0represent the target coap://s.coap.example.com/foo= or
>=C2=A0 =C2=A0coaps://s.coap.example.com/foo depending on applic= ation specific
>=C2=A0 =C2=A0presets.
>
>worrisome - is it saying that if you leave off the scheme, you don'= t know
>whether the resulting mapped URI is coap:// or coaps://?

That's right -- for the "simple form".=C2=A0 However, = the choice to omit the
scheme is either taken unilaterally by the client (and therefore it is
going to get what it deserves, most probably a 4xx error straight from the<= br> proxy), or it's agreed upon between the HC proxy and the client out of<= br> band.=C2=A0 The latter is the way one vendor implemented it, and what the t= ext
documents.=C2=A0 (The OOB agreement could be such that coaps URIs are ancho= red
to hc-proxy.example.com/secure whereas coap URIs are sent to hc-proxy.example.com/plain-text.)
I didn't get that from "local default". Your exp= lanation was extremely helpful.
=C2=A0
>If so, how critical= is it that this isn't deterministic?

For the reasons given above, it doesn't look that dodgy to me.
>Can the HTTP client tell whether the result used coaps://?

No, if it's using the simple form and there is no OOB agreement.= =C2=A0 So, I
guess the question is: do you think it'd be better to spell this out explicitly?=C2=A0 If so, we could say that a Target CoAP URI without the sc= heme
is not allowed unless there is an OOB agreement between client and HC
proxy (client MUST NOT emit / proxy MUST return 4xx on receipt).=C2=A0 Or d= o
you have something different in mind?

= =C2=A0That's exactly what i had in mind. It seems much less likely to r= esult in someone making the wrong assumption.

>-------------------------------------------------------------= ---------
>COMMENT:
>-------------------------------------------------------------= ---------
>
>In this text from the Abstract,
>
>=C2=A0 =C2=A0This document
>=C2=A0 =C2=A0covers the Reverse, Forward and Interception cross-protoco= l proxy
>=C2=A0 =C2=A0cases.
>
>are Reverse, Forward, and Interception proxys so well understood that t= he
>average reader would know what you're talking about?

I'd hope so, but case [s]?he isn't, in section 2 we provide = succinct
definitions for each of the proxy types plus references to RFC 7230, 7252 and 3040.

Right, but our theory is that Abs= tracts make sense without reading the document itself. We're told there= are people who publish Abstracts without providing the RFC text itself, so= the definition isn't readily available.
=C2=A0
>Do I u= nderstand that they're defined directly in this document, not
>referencing some other draft?

See above.

>Further in the document, I see this text,
>
>=C2=A0 =C2=A0Note that the guidelines apply to all forms of an HC proxy= (i.e.,
>=C2=A0 =C2=A0Reverse, Forward, Intercepting) unless explicitly otherwis= e noted.
>
>which makes me wonder if you need to mention the various forms of HC >proxy in the Abstract at all ...

Sorry, I don't understand the issue :-(

See above.=C2=A0

Unless there are other ty= pes of proxies, just saying "This document covers all forms of proxies= ." would solve that problem.
=C2=A0
>This text,
>
>=C2=A0 =C2=A0Note that a Reverse Proxy appears to an HTTP client as an = origin
>=C2=A0 =C2=A0server while a Forward Proxy does not.=C2=A0 So, when comm= unicating with a
>=C2=A0 =C2=A0Reverse Proxy a client may be unaware it is communicating = with a
>=C2=A0 =C2=A0proxy at all.
>
>would be clearer if it followed the definition of Reverse Proxy.

Yes, it's probably better as you suggest.=C2=A0 Will move the bl= ock.

>Confusingly, aren't clients unaware they're communicating with = an
>Interception Proxy, as well?

mmm, clients aren't "communicating" with an Intercepti= on Proxy, it's just
a middle-box.

Ah, now I understand. But sin= ce you moved the text block forward, it's clear what you mean.
=C2=A0
>It's easy for me to read this text,
>
>=C2=A0 =C2=A0See Figure 1 for an example deployment scenario.=C2=A0 Her= e a HC proxy is
>=C2=A0 =C2=A0located at the boundary of the Constrained Network domain,= to avoid
>=C2=A0 =C2=A0sending any HTTP traffic into the Constrained Network and = to avoid
>=C2=A0 =C2=A0any (unsecured) CoAP multicast traffic outside the Constra= ined
>=C2=A0 =C2=A0Network.
>
>as saying that secured CoAP multicast traffic might be sent outside the=
>Constrained Network. Is that what you meant?

No, it's not what we meant.=C2=A0 We'll remove "(unsecu= red)".

Thanks.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">>= ;In this text,
>
>=C2=A0 =C2=A0The HC proxy is furthermore
>=C2=A0 =C2=A0configured to only pass through GET requests in order to p= rotect the
>=C2=A0 =C2=A0constrained network.
>
>did you mean "GET requests and their corresponding responses"= ?

Yes, yes.=C2=A0 I'm not sure adding that explicitly makes it cle= arer though.

You may be right :-)
=C2=A0
>In this text,
>
>=C2=A0 =C2=A0The default URI mapping function SHOULD be implemented and= activated
>=C2=A0 =C2=A0by default in a HC proxy, unless there are valid reasons, = e.g.,
>=C2=A0 =C2=A0application specific, to use a different mapping function.=
>
>I found myself wondering if you could point to a valid use of a differe= nt
>mapping function. That would have been helpful to me.

I guess a non-default mapping would be handy if the proxy needs more=
freedom when setting up its URI namespace.

= Right. I'm asking (at the non-blocking comment level) if you could give= an example of why it might need more freedom.

The= point of a SHOULD for me is "unless you understand the consequences&q= uot;. A SHOULD with no explanation leaves the implementer to try to underst= and whether the implementer is doing something the specification writer ant= icipated.
=C2=A0
>In this text,
>
>=C2=A0 =C2=A0However, it should be noted that in certain cases, transco= ding can
>=C2=A0 =C2=A0lose information in a non-obvious manner.=C2=A0 For exampl= e, encoding an
>=C2=A0 =C2=A0XML document using schema-informed EXI encoding leads to a= loss of
>=C2=A0 =C2=A0information when the destination does not know the exact s= chema
>=C2=A0 =C2=A0version used by the encoder, which means that whenever the= HC proxy
>=C2=A0 =C2=A0transcodes an application/XML to application/EXI in-band m= etadata
>=C2=A0 =C2=A0could be lost.=C2=A0 Therefore, the implementer should alw= ays carefully
>=C2=A0 =C2=A0verify such lossy payload transformations before triggerin= g the
>=C2=A0 =C2=A0transcoding.
>
>I didn't understand how you "verify" payload transformati= ons. Is that a
>well-understood term of art for the community?

I'm leaving it for later as I need to check it with my co-author= s.

Sure, and thanks for checking.

Spencer
=C2=A0
Thanks again, cheers,
t


--001a1140b7ac03d2b7053dbaf4a5-- From nobody Fri Sep 30 08:46:38 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 F2A6712B154; Fri, 30 Sep 2016 08:46:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147525039695.20449.7660600809182856099.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 08:46:36 -0700 Archived-At: Cc: cabo@tzi.uni-bremen.de, core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm Subject: [core] core - New Meeting Session Request for IETF 97 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, 30 Sep 2016 15:46:37 -0000 A new meeting session request has just been submitted by Carsten Bormann, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: artarea dispatch cose t2trg ace lpwan 6lo roll Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm Third Priority: lwig httpbis detnet quic v6ops opsarea cfrg icnrg homenet Special Requests: Please also avoid any IoT related BOFs that might come up. *Preferred* pairing: Tue/Thu or other space between; Friday is also no problem. --------------------------------------------------------- From nobody Fri Sep 30 09:26:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A44A12B420; Fri, 30 Sep 2016 09:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7nzuranJimQZ; Fri, 30 Sep 2016 09:26:21 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2FA12B41C; Fri, 30 Sep 2016 09:26:20 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id CE1D9E3081C01; Fri, 30 Sep 2016 16:26:14 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8UGQHSl009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2016 16:26:17 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u8UGQHWL013500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Sep 2016 18:26:17 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Fri, 30 Sep 2016 18:26:17 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Spencer Dawkins at IETF , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGQ6m8SAo/UHADkCUO8OCqQpJJ6CRFfwAgADvGQCAACaiAA== Date: Fri, 30 Sep 2016 16:26:16 +0000 Message-ID: References: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_D414473071D16thomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-http-mapping@ietf.org" Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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, 30 Sep 2016 16:26:24 -0000 --_000_D414473071D16thomasfossatialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Spencer, >Can the HTTP client tell whether the result used coaps://? No, if it's using the simple form and there is no OOB agreement. So, I guess the question is: do you think it'd be better to spell this out explicitly? If so, we could say that a Target CoAP URI without the scheme is not allowed unless there is an OOB agreement between client and HC proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). Or do you have something different in mind? That's exactly what i had in mind. It seems much less likely to result in = someone making the wrong assumption. Great! Please see whether this suits you: When found in a Hosting HTTP URI, the scheme (i.e., "coap" or "coaps"), the scheme component delimiter (":"), and the double slash ("//") preceding the authority MAY be omitted if a local default - not defined by this document - applies. If no prior mutual agreement exists between the client and the HC proxy, then a Target CoAP URI without the scheme component is syntactically incorrect, and therefore: o it MUST NOT be emitted by clients; o it MUST elicit a suitable client error status (i.e., 4xx) by the HC p= roxy >In this text from the Abstract, > > This document > covers the Reverse, Forward and Interception cross-protocol proxy > cases. > >are Reverse, Forward, and Interception proxys so well understood that the >average reader would know what you're talking about? I'd hope so, but case [s]?he isn't, in section 2 we provide succinct definitions for each of the proxy types plus references to RFC 7230, 7252 and 3040. Right, but our theory is that Abstracts make sense without reading the docu= ment itself. We're told there are people who publish Abstracts without prov= iding the RFC text itself, so the definition isn't readily available. Ah OK! Now I understand what you meant :-) Unless there are other types of proxies, just saying "This document covers = all forms of proxies." would solve that problem. I think I could even get rid of the whole sentence and let the details for = later=85 >This text, > > Note that a Reverse Proxy appears to an HTTP client as an origin > server while a Forward Proxy does not. So, when communicating with a > Reverse Proxy a client may be unaware it is communicating with a > proxy at all. > >would be clearer if it followed the definition of Reverse Proxy. Yes, it's probably better as you suggest. Will move the block. >Confusingly, aren't clients unaware they're communicating with an >Interception Proxy, as well? mmm, clients aren't "communicating" with an Interception Proxy, it's just a middle-box. Ah, now I understand. But since you moved the text block forward, it's clea= r what you mean. OK >It's easy for me to read this text, > > See Figure 1 for an example deployment scenario. Here a HC proxy is > located at the boundary of the Constrained Network domain, to avoid > sending any HTTP traffic into the Constrained Network and to avoid > any (unsecured) CoAP multicast traffic outside the Constrained > Network. > >as saying that secured CoAP multicast traffic might be sent outside the >Constrained Network. Is that what you meant? No, it's not what we meant. We'll remove "(unsecured)". Thanks. >In this text, > > The HC proxy is furthermore > configured to only pass through GET requests in order to protect the > constrained network. > >did you mean "GET requests and their corresponding responses"? Yes, yes. I'm not sure adding that explicitly makes it clearer though. You may be right :-) :-) >In this text, > > The default URI mapping function SHOULD be implemented and activated > by default in a HC proxy, unless there are valid reasons, e.g., > application specific, to use a different mapping function. > >I found myself wondering if you could point to a valid use of a different >mapping function. That would have been helpful to me. I guess a non-default mapping would be handy if the proxy needs more freedom when setting up its URI namespace. Right. I'm asking (at the non-blocking comment level) if you could give an = example of why it might need more freedom. The point of a SHOULD for me is "unless you understand the consequences". A= SHOULD with no explanation leaves the implementer to try to understand whe= ther the implementer is doing something the specification writer anticipate= d. I think part of the confusion here is due to the fact that the SHOULDs are = actually two: 1. It SHOULD implement the default mapping; 2. It SHOULD have the default mapping configured as the default. So that: * It's always possible to replace box from vendor A with box from vendo= r B, and * The reconfiguration needed when deploying B in lieu of A is minimal (= possibly zero). What about: The default URI mapping function SHOULD be implemented and SHOULD be activated by default in a HC proxy, unless there are valid reasons, e.g., application specific, to use a different mapping function. ? >In this text, > > However, it should be noted that in certain cases, transcoding can > lose information in a non-obvious manner. For example, encoding an > XML document using schema-informed EXI encoding leads to a loss of > information when the destination does not know the exact schema > version used by the encoder, which means that whenever the HC proxy > transcodes an application/XML to application/EXI in-band metadata > could be lost. Therefore, the implementer should always carefully > verify such lossy payload transformations before triggering the > transcoding. > >I didn't understand how you "verify" payload transformations. Is that a >well-understood term of art for the community? I'm leaving it for later as I need to check it with my co-authors. Sure, and thanks for checking. So, after internal consultations we came up with this (which also covers on= e of Stephen's comments): [=85] However, there are at least two important factors to keep in mind when implementing and enabling a transcoding function: 1. Maliciously crafted inputs coming from the HTTP side might inflate in size (see for example Section 4.2 of [RFC7049]), therefore creating a security threat for both the HC proxy and the target resource; 2. Transcoding can lose information in non-obvious ways. For example, encoding a XML document using schema-informed EXI encoding leads to a loss of information when the destination does not know the exact schema version used by the encoder, which means that whenever the HC proxy transcodes an application/XML to application/EXI in-band metadata could be lost. It is crucial that these risks are well understood and carefully weighed against the actual benefits before deploying the transcoding function. What do you think? Cheers, t --_000_D414473071D16thomasfossatialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3488F1D84F28AB4FA02EEA3172203A7F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Hi Spencer,

>Can the HTTP client tell whether the result used= coaps://?

No, if it's using the simple form and there is no OOB agreement.&nbs= p; So, I
guess the question is: do you think it'd be better to spell this out
explicitly?  If so, we could say that a Target CoAP URI without the sc= heme
is not allowed unless there is an OOB agreement between client and HC
proxy (client MUST NOT emit / proxy MUST return 4xx on receipt).  Or d= o
you have something different in mind?

 That's exactly what i had in mind. It seems much less likely to = result in someone making the wrong assumption.

Great!  Please see whether this suits you:

   When found in a Hosting HTTP URI, the scheme (i.e., "coap= " or
   "coaps"), the= scheme component delimiter (":"), and the double slash
   ("//") preced= ing the authority MAY be omitted if a local default -
   not defined by this doc= ument - applies.  If no prior mutual agreement
   exists between the c= lient and the HC proxy, then a Target CoAP URI
   without the scheme c= omponent is syntactically incorrect, and
   therefore:
   o  it MUST NOT = be emitted by clients;
   o  it MUST elic= it a suitable client error status (i.e., 4xx) by the HC proxy

>In this text from the Abstract,
>
>   This document
>   covers the Reverse, Forward and Interception cross-protoco= l proxy
>   cases.
>
>are Reverse, Forward, and Interception proxys so well understood that t= he
>average reader would know what you're talking about?

I'd hope so, but case [s]?he isn't, in section 2 we provide succinct=
definitions for each of the proxy types plus references to RFC 7230, 7252 and 3040.

Right, but our theory is that Abstracts make sense without reading the= document itself. We're told there are people who publish Abstracts without= providing the RFC text itself, so the definition isn't readily available.<= /div>

Ah OK!  Now I understand what you meant :-)

Unless there are other types of proxies, just saying "This docume= nt covers all forms of proxies." would solve that problem.

I think I could even get rid of the whole sentence and let the details for = later=85

>This text,
>
>   Note that a Reverse Proxy appears to an HTTP client as an = origin
>   server while a Forward Proxy does not.  So, when comm= unicating with a
>   Reverse Proxy a client may be unaware it is communicating = with a
>   proxy at all.
>
>would be clearer if it followed the definition of Reverse Proxy.

Yes, it's probably better as you suggest.  Will move the block.=

>Confusingly, aren't clients unaware they're communicating with an
>Interception Proxy, as well?

mmm, clients aren't "communicating" with an Interception P= roxy, it's just
a middle-box.

Ah, now I understand. But since you moved the text block forward, it's= clear what you mean.

OK

>It's easy for me to read this text,
>
>   See Figure 1 for an example deployment scenario.  Her= e a HC proxy is
>   located at the boundary of the Constrained Network domain,= to avoid
>   sending any HTTP traffic into the Constrained Network and = to avoid
>   any (unsecured) CoAP multicast traffic outside the Constra= ined
>   Network.
>
>as saying that secured CoAP multicast traffic might be sent outside the=
>Constrained Network. Is that what you meant?

No, it's not what we meant.  We'll remove "(unsecured)&quo= t;.

Thanks.
 
>In this text,
>
>   The HC proxy is furthermore
>   configured to only pass through GET requests in order to p= rotect the
>   constrained network.
>
>did you mean "GET requests and their corresponding responses"= ?

Yes, yes.  I'm not sure adding that explicitly makes it clearer= though.

You may be right :-)

:-)

>In this text,
>
>   The default URI mapping function SHOULD be implemented and= activated
>   by default in a HC proxy, unless there are valid reasons, = e.g.,
>   application specific, to use a different mapping function.=
>
>I found myself wondering if you could point to a valid use of a differe= nt
>mapping function. That would have been helpful to me.

I guess a non-default mapping would be handy if the proxy needs more=
freedom when setting up its URI namespace.

Right. I'm asking (at the non-blocking comment level) if you could giv= e an example of why it might need more freedom.

The point of a SHOULD for me is "unless you understand the conseq= uences". A SHOULD with no explanation leaves the implementer to try to= understand whether the implementer is doing something the specification wr= iter anticipated.

I think part of the confusion here is due to the fact that the SHOULDs= are actually two:
  1. It SHOULD implement the default mapping;
  2. It SHOULD have the def= ault mapping configured as the default.
So that:
  • It's always possible to replace box from vendor A with box from vendor = B, and
  • The reconfiguration needed when deploying B in lieu of A is = minimal (possibly zero).
What about:

   The default URI mapping function SHOULD be implemented= and SHOULD be
   activated by default in a HC proxy, unless there are v= alid reasons,
   e.g., application specific, to use a different mapping= function.

?

 
>In this text,
>
>   However, it should be noted that in certain cases, transco= ding can
>   lose information in a non-obvious manner.  For exampl= e, encoding an
>   XML document using schema-informed EXI encoding leads to a= loss of
>   information when the destination does not know the exact s= chema
>   version used by the encoder, which means that whenever the= HC proxy
>   transcodes an application/XML to application/EXI in-band m= etadata
>   could be lost.  Therefore, the implementer should alw= ays carefully
>   verify such lossy payload transformations before triggerin= g the
>   transcoding.
>
>I didn't understand how you "verify" payload transformations.= Is that a
>well-understood term of art for the community?

I'm leaving it for later as I need to check it with my co-authors.

Sure, and thanks for checking.

So, after internal consultations we came up with this (which also covers on= e of Stephen's comments):

   [=85]
   However, there are a= t least two important factors to keep in mind
   when implementing an= d enabling a transcoding function:

   1.  Maliciously= crafted inputs coming from the HTTP side might
       inflat= e in size (see for example Section 4.2 of [RFC7049]),
    &nb= sp;  therefore creating a security threat for both the HC proxy and
       the ta= rget resource;

   2.  Transcoding= can lose information in non-obvious ways.  For
       exampl= e, encoding a XML document using schema-informed EXI
       encodi= ng leads to a loss of information when the destination does
       not kn= ow the exact schema version used by the encoder, which
       means = that whenever the HC proxy transcodes an application/XML to
       applic= ation/EXI in-band metadata could be lost.

   It is crucial that t= hese risks are well understood and carefully
   weighed against the = actual benefits before deploying the transcoding
   function.=

What do you think?

Cheers, t
--_000_D414473071D16thomasfossatialcatellucentcom_-- From nobody Fri Sep 30 10:35:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737E412B18B; Fri, 30 Sep 2016 10:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmail.fm header.b=Ce7JXWs0; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=EJ783Cuk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IlPPhy4ySaE; Fri, 30 Sep 2016 10:35:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B620312B0A8; Fri, 30 Sep 2016 10:35:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 160E22144B; Fri, 30 Sep 2016 13:35:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 30 Sep 2016 13:35:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=35RPdjnEtgJtFOz/ntP+ktdfJRc=; b=Ce7JXW s0NrdAxcmfox3EY5pLxmiDWwItXgJya376jUttxgIbre93ErAW1iO6pxAJ8VHXQ6 T7kE1vOgfn6u9D3IQomdEPBDC1yacdErnlZmRxV8sZ00rb85MrQuUuY4ZWbZFswr B6LdBQa2BXBkLoa9MF7fsrjcSQfAvqoKHu7gs= 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-sasl-enc:x-sasl-enc; s=smtpout; bh=35RPdjnEtgJtFOz /ntP+ktdfJRc=; b=EJ783CukyILmb+V4Tvfu1jC/nhXhGn762WTjBTBMXtTdZ3l jHiizFrNYYP5hEBzBQAtT9OsSn1Xl5U3IJE7LDiFWAztqmdx5UnX8e2QKTN7f+UO WH+2KDkEobxPcaDSnjLt57SDVqlJ9Yuu1Asw/XbhuyDu7fymlSQIhX/xyaVE= X-Sasl-enc: D8P9v2axODKVB9+gcc75t6RSFRXJhoEosa847a3+bx+V 1475256948 Received: from [192.168.142.154] (foin-mou-peer.customers.otenet.gr [212.205.242.54]) by mail.messagingengine.com (Postfix) with ESMTPA id AF148F29CC; Fri, 30 Sep 2016 13:35:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (13G36) In-Reply-To: Date: Fri, 30 Sep 2016 20:49:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> To: "Fossati, Thomas (Nokia - GB)" Archived-At: Cc: "draft-ietf-core-http-mapping@ietf.org" , "core-chairs@ietf.org" , Spencer Dawkins , "core@ietf.org" , The IESG Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and 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, 30 Sep 2016 17:35:51 -0000 Hi Thomas, On 30 Sep 2016, at 02:51, Fossati, Thomas (Nokia - GB) wrote: >> Can the HTTP client tell whether the result used coaps://? >=20 > No, if it's using the simple form and there is no OOB agreement. So, I > guess the question is: do you think it'd be better to spell this out > explicitly? If so, we could say that a Target CoAP URI without the scheme= > is not allowed unless there is an OOB agreement between client and HC > proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). Or do > you have something different in mind? An alternative is to always require coaps in this case. Might not work for y= our type of document though.