From nobody Tue Aug 3 10:23:57 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDBD3A2ABA for ; Tue, 3 Aug 2021 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gbjOqvTpBKD for ; Tue, 3 Aug 2021 10:23:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FA63A2ABC for ; Tue, 3 Aug 2021 10:23:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DB0F338996; Tue, 3 Aug 2021 13:27:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OfeVULO6b0Na; Tue, 3 Aug 2021 13:27:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 76B8C38995; Tue, 3 Aug 2021 13:27:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 260CA1CB; Tue, 3 Aug 2021 13:23:38 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , core@ietf.org In-Reply-To: References: <26725.1626041953@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] core-sid-16: possible rename of ietf-constrained-voucher to ietf-voucher-constrained X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 17:23:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2021-07-12, at 00:19, Michael Richardson w= rote: >> >> Maybe we need to put text in >> ietf-anima-constrained-voucher's IANA Considerations fixing the name >> clearly? > Yes, please. Then it should be easy to fix in -sid. I have done this in ietf-anima-constrained-voucher's IANA considerations. (In the not-yet-merged pull request) > (Probably during the =E2=80=9Creact to IESG ballots=E2=80=9D phase we= are now in.) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEJe5kACgkQgItw+93Q 3WWkDAf+Nb5F+cxX9+MVYwvSgjmlSAQQp3np7kSYXkZP0dWLfeTRvmkQigu65fI7 7MH7pk3hJzNhhIXrCP598dOF5zkSqdap7gA3g3qgRPQOGguf3buy/iBq145r6d9F Mc96VpmUe7/EMC3uxBFv3J9p9l353GTdOtppFXHNDpWRB7mA77lWZju7RrAzMnvF MjD+/6Du10NiMiZRE+BopA4YaugRMEpLnfiFmJh80HdL+Lfz3Ur1IvabU+F+APUh 78bwCtlq8C59Szhk3UOhttRc1ggUhuEYoF18s3LycZMVxAqL0wlvzXTT8kNiQaq9 zruc2QlVctFGI0ORLQ29HA7+PXOtiQ== =6nLL -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 9 08:05:25 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FC33A1713 for ; Mon, 9 Aug 2021 08:05:23 -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, SPF_HELO_NONE=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 1taWnb5H-YiT for ; Mon, 9 Aug 2021 08:05:19 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653613A170D for ; Mon, 9 Aug 2021 08:05:18 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B8E5040108; Mon, 9 Aug 2021 17:05:12 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 44FDBD0; Mon, 9 Aug 2021 17:05:11 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2902:9110:3a00:3a1b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F31E446; Mon, 9 Aug 2021 17:05:10 +0200 (CEST) Received: (nullmailer pid 3892858 invoked by uid 1000); Mon, 09 Aug 2021 15:05:10 -0000 Date: Mon, 9 Aug 2021 17:05:10 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6GV/ptg5pu1XCC1i" Content-Disposition: inline Archived-At: Subject: [core] Relative times in responses, Age and Max-Age X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 15:05:23 -0000 --6GV/ptg5pu1XCC1i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, discussing an upcoming draft Martine is composing on DNS-over-CoAP, questions on relative times in CoAP responses came up. Root of the issue is that on the application level, different parts of a response can have different life times. At the same time, we want to use CoAP proxy caches (ie. as long as *all* parts of the response are still valid). Consequently, the client does not have the time of its request as a reliable reference point for the times indicated in the response. (Keeping in mind that we don't want to rely on some consensus time frame -- there's no indication devices will know UNIX time). We're currently floating two (largely equivalent) ideas: * Transport all times relative to the first request. Set the Max-Age option to the smallest of the times involved. If the client sees a Max-Age less than the smallest payload time, it will subtract the difference from all times. * Transport all times relative to the end of Max-Age. The client can add Max-Age to all times. HTTP is using an Age header to be subtracted from all values, but a) I'd rather not introduce a new option that all proxies would need to support, and b) using Max-Age gives a compatible unilateral estimation of the true value (a proxy reducing Max-Age doesn't hurt), whereas the lack of an Age value could just as well mean that it was produced by a proxy that doesn't know Age. Is there any experience implementing things like this in CoRE? Best I found was SenML's 'roughly "now"', which doesn't talk about representation lifetimes. Thanks Christian --=20 Yesterday is history, tomorrow is a mystery, and today is a gift. That is why it is called the present. -- ancient saying --6GV/ptg5pu1XCC1i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmERRCIACgkQOY0REtOk veFElg/8DN9Q+LZc9UjMjacUbxbDqtacKUaqC5Y5AQHb8fUMp2c/TfYL5bwjZUXo q/seSCayxXzysWQ9ms6RHXfagXjnuYuhXvEmA3jCrxqEVRr1g4ciYbjmdmfzMTY/ ieOtw7I5pluSPmVQwAW7v/6NZoUQqrGV5k9QiLxQNH0Frc2CYsifB5Bz6pLNTInP sem6euMUbaT2kV3HkQX/K4NSkuH/8r1JksxFvhJdq92n1QfehhuuMvx+Kcbb4oDe +2zDroaMzx+AXTEToq4Rk+Ty5j1vGkV6pVAGIQHhnxsFpxaNTL2AD8tminYdT4oC o4qYMQwdqk4/xHg9CS60GEZuFss7FQ0oS5O0O8txnF4isPM1lpxVG1Ajv9WFlfoV s5ggpsz6yv12yeV70l4fbr8OOAhP91Gl2mu68CsDxrAptzAXmlfLwXcIsvs/WE6F RqHq7J0sbeCMn/krgWrM4t7tU6ssFdOtZbBCdN+EQHkMXkgFbXjLUXjyTai7YpDF FJgpT0hEjIhFZO/1GtwjvInoUdbLa8EGB5eSZkkSzHxv4iFHb7R7MYNf5M3eymbe +lzb+nK11a/kxfodp2cgbcqDvjzVPc4Yre/aZLnmoRZ9lSMskrTmirtmhF5yoJS8 F5lzjMMqydSz0m6wm1fZme0NRyj+EgLnMNn3jfqvu0qg78Dl5Z4= =tEUw -----END PGP SIGNATURE----- --6GV/ptg5pu1XCC1i-- From nobody Fri Aug 13 00:24:46 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B1A3A1027 for ; Fri, 13 Aug 2021 00:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S20iCos7DHU for ; Fri, 13 Aug 2021 00:24:39 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655A53A1022 for ; Fri, 13 Aug 2021 00:24:38 -0700 (PDT) Received: from omf12.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 93562181D2FC2 for ; Fri, 13 Aug 2021 07:24:35 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf12.hostedemail.com (Postfix) with ESMTPA id 65DE624023B for ; Fri, 13 Aug 2021 07:24:35 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 13 Aug 2021 09:24:34 +0200 From: Peter van der Stok To: core@ietf.org Reply-To: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.4.11 Message-ID: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy Content-Type: multipart/alternative; boundary="=_00fce87b88e9080bb31035000bc0256a" X-Rspamd-Server: rspamout01 X-Rspamd-Queue-Id: 65DE624023B X-Stat-Signature: 6jx74xorekf4n7scfizum7ropaam96rd X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Session-ID: U2FsdGVkX1+i2yEVVZZD1sVgv02asBPSyVa8JqlJ550= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:subject:reply-to:message-id:content-type; s=key; bh=rWVjYW5qupq6zaqs4P5KKHdezuaF6coQ233ov+23rXk=; b=PekCdVa28RO2gxbYD0l2qQnv8MqHqmztS+O/mA1e0E0xZrnt1xhgX1qNIblHJeBHyAp0MRnSQ5M2UuvMvOxV3cpxAl4RK66clMRA+1ZodJ5L7ZhV+7Tv+OsaK/gAgufg1MPm0jeNoq9586/sNju1pxe6/gF8xpyxqhssJCYDM/E= X-HE-Tag: 1628839475-805874 Archived-At: Subject: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 07:24:45 -0000 --=_00fce87b88e9080bb31035000bc0256a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi CORE WG, We met a problem with the specification of "join-proxy" used for the BRSKI protocol in ANIMA, The join-proxy provides the connection between a new device (called pledge) and the registrar that authorizes the access to the network for the pledge. The join-proxy is an authorized node that can route messages to the Registrar. The join-proxy also provides coap services on the network. The pledge has only link-local acccess to a neighbour join-proxy The pledge sends a link-local DTLS coap request to a resource on the join-proxy accessable via a non-coap port on the join-proxy. The join-proxy copies the messages received on that port and sends them on to a non-standard discoverable port of the Registrar. The join-proxy resources on the join-proxy are discoverable with rt= brski_xxx The pledge discovers the join-proxy resources and their non-standard port with coap discovery. The protocol between join-proxy and Registrar is not coaps but an UDP protocol that forwards the coaps messages to the Registrar. However, the join-proxy discovers the Registrar port by discovering a related coap resource and its port on the Registrar with rt = brski-yyy Question: Is this a legitimate use of coap discovery to discover the non-standard ports on join proxy and Registrar? thanks for comments, or suggestions, Peter -- Peter van der Stok vanderstok consultancy mailto: stokcons@bbhmail.nl tel NL: +31(0)492474673 F: +33(0)468839947 --=_00fce87b88e9080bb31035000bc0256a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi CORE WG,

We met a problem with the specification of "join-pro= xy" used for the BRSKI protocol in ANIMA,

The join-proxy provide= s the connection between a new device (called pledge) and the registrar tha= t authorizes the access to the network
for the pledge.
The join-p= roxy is an authorized node that can route messages to the Registrar.
T= he join-proxy also provides coap services on the network.
The pledge h= as only link-local acccess to a neighbour join-proxy

The pledge = sends a link-local DTLS coap request to a resource on the join-proxy access= able via a non-coap port on the join-proxy.
The join-proxy copies the= messages received on that port and sends them on to a non-standard discove= rable port of the Registrar.
The join-proxy resources on the join-prox= y are discoverable with  rt=3D brski_xxx

The pledge discove= rs the join-proxy resources and their non-standard port with coap discovery= =2E

The protocol between join-proxy and Registrar is not coaps b= ut an UDP protocol that forwards the coaps messages to the Registrar.
= However, the join-proxy discovers the Registrar port by discovering a relat= ed coap resource and its port on the Registrar with rt =3D brski-yyy
<= br />Question:
Is this a legitimate use of coap discovery to discover = the non-standard ports on join proxy and Registrar?

thanks for c= omments, or suggestions,

Peter
--
= Peter van der Stok
vanderstok consultancy
mailto: stokcons@bbhmail.nl
tel NL: +31(0)49247467= 3     F: +33(0)468839947
--=_00fce87b88e9080bb31035000bc0256a-- From nobody Mon Aug 16 07:40:24 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB22B3A17B5; Mon, 16 Aug 2021 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebnLpAdm7CoB; Mon, 16 Aug 2021 07:40:14 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCE93A17B1; Mon, 16 Aug 2021 07:40:11 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id E4E9D40104; Mon, 16 Aug 2021 16:40:06 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BFC2AD0; Mon, 16 Aug 2021 16:40:04 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:6a01:d988:4e55:c71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3681C46; Mon, 16 Aug 2021 16:40:04 +0200 (CEST) Received: (nullmailer pid 2872286 invoked by uid 1000); Mon, 16 Aug 2021 14:40:03 -0000 Date: Mon, 16 Aug 2021 16:40:03 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Dan Garcia Carrillo Cc: EMU WG , "ace@ietf.org" , Rafa Marin-Lopez , core@ietf.org Message-ID: References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> Archived-At: Subject: Re: [core] [Ace] CoAP-EAP draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 14:40:19 -0000 Hello CoAP-EAP authors and involved groups, (CC'ing core@ as this is a review on CoAP usage), I've read the -03 draft and accumulated a few comments; largely in sequence of occurrence. Over all, the protocol has improved a lot since I've last had my eyes on it. Several comments below are about how prescriptive the message types are. I believe that this should be resolved towards generality, or else the usability of this protocol with generic CoAP components will be limited (or, worse, still implemented and then surprisingly incompatible). * Figure 1: For readers new to the topic of EAP, I think that it might be useful to extend this to cover also the EAP server or AAA infrastructure, if that can be covered without too much complication. Suggestion (without illusions of correctness): IoT device Controller +------------+ +------------+ | EAP peer/ | | EAP auth./ |+-----+[ AAA infra. ] | CoAP server|+------+| CoAP client|+-----+[ EAP server?] +------------+ CoAP +------------+ EAP? \_____ Scope of this document _____/ Figure 1: CoAP-EAP Architecture * `/.well-known/a`: [note: May be irrelevant, see next two items] If the designated experts don't go along with a very-short option (I'd kind of doubt you'd get anything shorter than `/.well-known/eap`) and if that puts you up against practical limits, using a short-hand option might be viable. So far there's no document for it and I've only pitched the idea briefly at an interim[1] (slides at [2]), but if push comes to shove and you need the compactness, let me know and that work can be expedited. [1]: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core [2]: https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 * Discovering the Controller is described rather generically, but with CoAP discovery as an example. As long as CoAP discovery (as per RFC6690/7252) is used, that already produces a URI, which can contain any path the server picked. It has thus no need for a well-known path. Are there other discovery options envisioned that'd only result in a network address? Only for these, a well-known path would make sense. (And then it's up to the envisioned client complexity if one is warranted). For comparison, RD[3] explores some of the options. A path may be discovered using CoAP discovery as `?rt=core.rd*` right away from multicast. Or an address may be discovered using an IPv6 RA option, with CoAP discovery acting on that address. Only for cases of very simple endpoints, it also defines a `/.well-known/rd` name that can be used without CoAP discovery (and thus link parsing) happening beforehand. The same rationales may apply for EAP (the devices using the resource are mostly servers, otherwise, and send a very simple request to start things), but again that's only if the address was discovered through something that's not CoAP discovery already. [3]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte * For message 1, why does this need to go to a fixed resource? There has been previous communication in message 0 in which the resource could have been transported. Granted, it's not as easy as in messages 2-to-3 etc where the Location-* options are around, but the original message 0 POST could just as well contain the path in the payload. There are options as to how to do that precisely (just the URI reference in text form, or a RFC6690 link, or a CBOR list of path segments, or a CRI reference[4] -- if the latter were in WGLC already I'd recommend it wholeheartedly), but either of them would stay more true to the style of the other messages in that the earlier message informs the path choice of the next ones. An upside of this would be that it allows better behavior in presence of proxies (see later), even though it may be practical to not spec that out in full here. (But the path would be open for further specs, and they'd just need some setting down of paving stones). [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ * (Bycatch of suggesting URIs): It may be worth mentioning that the NON's source address can easily be spoofed. Thus, any device on the network can trigger what the authenticator may think of as a device-triggered reauthentication, and the device may think of as an authenticator-triggered reauthentication (provided it works that way, see below when reauthentication is mentioned again). Even sending full URIs in message 0 would be no worse than the current source spoofing. Sending URI paths in message 0 would make this minimally better because the attacker would need to guess (or observe from the network) the CoAP server's path. * In 3.1 General flow, the message types are described in high detail. CoAP can generally be used with different transports (some of which don't even do NON/CON). Also, while I think it's reasonable to expect that a CoAP implementation can deal with requests coming in as either CON or NON, I'd expect that some don't offer all possible choices to applications. (A very constrained device may only send NON requests, or an implementation may decide autonomously whether to send piggy-backed or not). Can you clarify as to what of this is meant to be normative and what exemplary? My recommendation is to state that what is prescribed is the flow of requests and responses (which is what CoAP provides to the next layer), while notes on reliable transmission are recommendations for CoAP-over-UDP/DTLS. A similar statement, which I like a lot, is already in 3.2 on error handling. (I can serve examples of how subtle incompatibilities can develop but go unnoticed, but I'd only go through that if this is all really intended to be prescriptive). * The reuse of the empty token only works if the peers actually respond with piggy-backed responses, so that's where enforcing the above rules would give some benefit -- but at the cost of losing existing CoAP implementations that make no guarantees as to how the response will be sent as long as it's reliable. * Proxying: As it is right now, this protocol just barely works across proxies, and only if they support CoAP-EAP explicitly. (And while it may sound odd to even consider that, bear in mind that they are used in a very similar way in RFC9031). While it's a bit open whether all CoAP-based protocols should reasonably be expected to work across proxies or not, a remark (maybe before 3.1?) that "If CoAP proxies are used between EAP peer and EAP authenticator, they must be configured with knowledge of this specification, or the operations will fail after step 0." * 3.2.2: The use of RST is rather unusual here, for the same reasons as the prescriptive message types. A response of 5.03 (Service Unavailable) has roughly the same size, is available independent of transport, and on most libraries *way* easier to use, if they support sending an RST to a well-formed message at all. (Furthermore, the sender of the 5.03 can encode an estimate of the remaining unavailable time in the Max-Age option; not sure if that is of any help here). * 3.3.1: "received with the ACK", "sends piggybacked response" are, again, overly specific. "received in the last response" and "sends a response" could work as replacements even if message types are presecriptive. * 3.3.1: "after the maximum retransmission attempts, the CoAP client will remove the state from its side". So the device that's being kicked from the network can delay its own eviction for about a minute as long as it doesn't answer? * 3.3.2: Is reauthentication always triggered by the EAP peer, or can it also be triggered by the authenticator? If the latter, will the authenticator use /.well-known/a again, or POST something to the resource from where it'd DELETE in 3.3.1? * cryptosuites: What's the upgrade model of that hardcoded list? As it is now, it looks pretty static, so updates would be through updates of this document. The obvious alternative is an IANA registry with ranges, policies and the usual pros and cons. Then again, this is not the first nor last time AEAD algorithms with their parametrization and hash functions are assigned aggregate numbers (I-D.ietf-lake-edhoc comes to mind which has asymmetric algs in the mix too; probably others as well); can we deduplicate this with anything? (Possibly by bringing this up with COSE or OSCORE people). * OSCORE derivation: Is it cryptographically necessary to derive *both* a master secret and a master salt through KDF? (Sounds like a needless step to me, as both only go into KDF once more when the actual OSCORE parameters are derived). I *guess* there's a good reason why the MSK is not used as the OSCORE IKM right away and the CSO as OSCORE master salt, but it'd help to have at list a comment here on why that's needed. (It may be useful to compare this step to the HKDF steps in OSCORE; their info element is always a 5-element array with a 4th "type" element of "Key" or "IV"; other extractions might just hook in there with different type values, maybe, and save everyone an extra handling step). * OSCORE ID derivation: * Randomly assigned full-length ideas look like an odd choice. They are excessively long (nonce length - 6 is 7 for the MTI AES-CCM-16-64-128 and shorter for other current ones, but I doubt that keeping the IV *short* is necessarily a design criterion for future algorithms). What commonly happens here (eg. in the ACE-OSCORE profile, or in EDHOC) is that each party picks a recipient ID out of its pool of currently unused IDs. This makes for shorter keys, and allows the client to be sure that no two peers use the same context. Any chance something like that can still make it in? * If the parties happen to be assigned the same sender ID, bad things happen (identical key derivation, nonce reuse, nuclear meltdown). If the current pattern of KDF'ing IDs stands, this needs to be prevented explicitly. * The derivations of "OSCORE RECIPIENT ID" and "OSCORE SENDER ID" are confusing as they each need to happen on both sides, and the terms will match on one and need to be opposite on the other. (I couldn't even easily find which is intended to be which). My suggestion is to derive "OSCORE EAP PEER SENDER ID" and "OSCORE AUTHENTICATOR SENDER ID" instead. (Or preferably shorter strings). * Exmaples: Do you envision particular EAP protocols to be used in the given examples? Best regards Christian From nobody Mon Aug 16 15:06:24 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A813A1BF1; Mon, 16 Aug 2021 15:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60Mwirzw8JcO; Mon, 16 Aug 2021 15:06:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C818A3A1BEF; Mon, 16 Aug 2021 15:06:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4D792F40722; Mon, 16 Aug 2021 15:06:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, core@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210816220608.4D792F40722@rfc-editor.org> Date: Mon, 16 Aug 2021 15:06:08 -0700 (PDT) Archived-At: Subject: [core] =?utf-8?q?RFC_9100_on_Sensor_Measurement_Lists_=28SenML?= =?utf-8?q?=29_Features_and_Versions?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 22:06:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9100 Title: Sensor Measurement Lists (SenML) Features and Versions Author: C. Bormann Status: Standards Track Stream: IETF Date: August 2021 Mailbox: cabo@tzi.org Pages: 7 Updates: RFC 8428 I-D Tag: draft-ietf-core-senml-versions-05.txt URL: https://www.rfc-editor.org/info/rfc9100 DOI: 10.17487/RFC9100 This short document updates RFC 8428, "Sensor Measurement Lists (SenML)", by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Aug 17 05:48:44 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113EB3A21F8 for ; Tue, 17 Aug 2021 05:48:43 -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, SPF_HELO_NONE=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 pfQbpao_0Pit for ; Tue, 17 Aug 2021 05:48:40 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33123A21F4 for ; Tue, 17 Aug 2021 05:48:38 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6F1A040104; Tue, 17 Aug 2021 14:48:35 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A71BAD0; Tue, 17 Aug 2021 14:48:34 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8d88:bd61:7974:fcd3]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6884646; Tue, 17 Aug 2021 14:48:34 +0200 (CEST) Received: (nullmailer pid 2976449 invoked by uid 1000); Tue, 17 Aug 2021 12:48:34 -0000 Date: Tue, 17 Aug 2021 14:48:34 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Peter van der Stok Cc: core@ietf.org Message-ID: References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JsfHnZyKUBQlOYji" Content-Disposition: inline In-Reply-To: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 12:48:43 -0000 --JsfHnZyKUBQlOYji Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, > However, the join-proxy discovers the Registrar port by discovering a > related coap resource and its port on the Registrar with rt =3D brski-yyy >=20 > Question: > Is this a legitimate use of coap discovery to discover the non-standard > ports on join proxy and Registrar? If that protocol is really not CoAP, it can be legitimately discovered, but should IMO be indicated with a different protocol than coap, say ;rt=3Dbrski-yyy However, just to get a better understanding, why is the protocol through which the CoAP messages are forwarded between the join-proxy and the registrar neither CoAP nor a new CoAP transport? (Just sounds like it'd be working around the very shortcomics of CoAP proxies that RFC8974 resolved). Is this protocol described anywhere so far? BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --JsfHnZyKUBQlOYji Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmEbsB4ACgkQOY0REtOk veFquRAAvR1O91MOnAo4Mc/s8bEW7AAZtxq7HojeZcT+uQS/KEAI2Luz2fiXzc5i C2pn0JeI2WRXwZa7zIt9dXKvIultBAclkdbW5GroMnLD4JS7bgNZjM9HWnSHEp9x gQbzA8WTCuFglo3TXA9rlWGSyz26YBA58dije/p7vgOmRUG72Wmu4M54kksIGi+N hZs2POxpyJspfJg1zEc0MB/ysHUksBGcQsBeKAW5bzDw+T7yfviN6VdMGrDVNbnp PZ927+CdvepILLhcxfdUZv0HbbR0F7kxnsaa///wAj190xj++RvIN8d/NsHpnSk/ f92co6oUHxukUee9XzQObc1DMYe57w+PFUfdHZmRpt/uUnWLmDGduv00+rrJDXKa QnrNJwSiUMpQK4E3+cR7eaADRGufO4kF9hAjulcnphncr5MR0XQPiPccgmkHpOqU GG9vssC4AFFh+h3eqD6G69j+tqVVrf4qxWf6WrKK/Lfxe5+kYtLCnE9th2EYHAiZ DoQi3IlsfVUoBmtAilwnWshkEd+PHSuI418G7Nwc7YbGKn3iwpqDfqpZSDU8BWNg mH1RhLtjBLzaq6TZLhLTaLAWzBJ5R+toNeSB+ljQCTjsbgJjumTI1pwnL4L10nM1 sKgvAD49HMScXof323D0XAMI6KzzOQsQaZpAtZHUJWJ8PCsG7O0= =1dZU -----END PGP SIGNATURE----- --JsfHnZyKUBQlOYji-- From nobody Tue Aug 17 09:28:11 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCCB3A218A for ; Tue, 17 Aug 2021 09:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XysOSQaS-hnk for ; Tue, 17 Aug 2021 09:28:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891E13A2183 for ; Tue, 17 Aug 2021 09:28:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9029638994; Tue, 17 Aug 2021 12:33:03 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FI_q64ovOh7w; Tue, 17 Aug 2021 12:32:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E204538983; Tue, 17 Aug 2021 12:32:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0CA99407; Tue, 17 Aug 2021 12:27:54 -0400 (EDT) From: Michael Richardson To: Christian =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FAms=3DFCss=3F=3D?= , Peter van der Stok , core@ietf.org In-Reply-To: References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 16:28:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Ams=C3=BCss wrote: > However, just to get a better understanding, why is the protocol > through which the CoAP messages are forwarded between the join-proxy > and the registrar neither CoAP nor a new CoAP transport? (Just sounds > like it'd be working around the very shortcomics of CoAP proxies that > RFC8974 resolved). Is this protocol described anywhere so far? Because, it is CoAP in DTLS in stuff. Between Pledge and Register, it is supposed to look like CoAP-in-DTLS. Between Pledge and Join Proxy, it's CoAP-in-DTLS (over IPv6-LL) Between Join Proxy and Register, it's CoAP-in-DTLS-in-"CBORUDP" (over ULA/G= UA). The "CBORUDP" provides for a stateless (i.e. stored in the network) record of where the packets come from. In RFC9031, which uses OSCORE, and therefore has security *above* CoAP, rather than security *below* CoAP, we use the CoAP (extended) token for the= state. (RFC8974). =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEb44kACgkQgItw+93Q 3WWzMQgAk9RDQGSiDEY4pYf5XQLhTi7pKQ5OTE4TSqxLvIAkMewNdxcMI4HBvV3U Atm3GMFtXdmUk2lYniH4qxRs29P1SKOROs7tibhjDB8ZUc6gS2UTnS2W77hN2wgA CEnoHqHFcAIrl2g62wpvdngiwvVmCzK73xAtnDbrimghK8R/8N9GCR1M5NUWuVvn Nf91r3DGuB6sO/tEYTkqZt89bMckmWR8CYKs5L8OHBxQHeubXbqClNbM/zRWZZpy VWXQnNP1V4jtmgiyazzlqphL3+BRF5DO0LOEoS93vlPvEsdWMscQNvabPHY9L9Zk I3xxMJFgIWs7BSS/+K4iLNi7cyE7aw== =XyMI -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 17 10:19:57 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5733A231B for ; Tue, 17 Aug 2021 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6LIOBSnPShF for ; Tue, 17 Aug 2021 10:19:50 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811BE3A2376 for ; Tue, 17 Aug 2021 10:19:47 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7D30540104; Tue, 17 Aug 2021 19:19:43 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2C23AD0; Tue, 17 Aug 2021 19:19:42 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8d88:bd61:7974:fcd3]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F2BB446; Tue, 17 Aug 2021 19:19:41 +0200 (CEST) Received: (nullmailer pid 3885988 invoked by uid 1000); Tue, 17 Aug 2021 17:19:41 -0000 Date: Tue, 17 Aug 2021 19:19:41 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Richardson Cc: Peter van der Stok , core@ietf.org Message-ID: References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <8819.1629217674@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sJI7M/WI5299mUK0" Content-Disposition: inline In-Reply-To: <8819.1629217674@localhost> Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 17:19:56 -0000 --sJI7M/WI5299mUK0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 17, 2021 at 12:27:54PM -0400, Michael Richardson wrote: > Because, it is CoAP in DTLS in stuff. Ah, so it's now with DTLS and that makes it messy. OK, can live with that. > Between Pledge and Register, it is supposed to look like CoAP-in-DTLS. >=20 > Between Pledge and Join Proxy, it's CoAP-in-DTLS (over IPv6-LL) > Between Join Proxy and Register, it's CoAP-in-DTLS-in-"CBORUDP" (over ULA= /GUA). >=20 > The "CBORUDP" provides for a stateless (i.e. stored in the network) record > of where the packets come from. So a bit like HTTP's CONNECT, and because there's CoAP as a transport and since 8974 it has extended tokens, it can be stateless. Got it. (Will this be specified for standalone use? I don't know to think of it yet, but it's definitely intriguing). If I've formed the right mental model here, there's two things that the proxy can discover on the register (where 2001:db8:1:: might be the actual network, and 2001:db8:2:: the network that's inside the UDP tunnels -- may be the same addresses but may be not): * The endpoint of the CoAP UDP service: ;rt=3Dcborudp (or ;rt=3Dbrski-yyy) * The endpoint of the actual registration service: ;rt=3D... (or is it just ;rt=3D... ?) If so, and if the analogy from 9031 holds, then what the proxy needs to discover is the /udp endpoint. To that endpoint, it does talk CoAP, so it's perfectly legitimate to discover it as a CoAP resource. Of the inside traffic, or its relation to the outside resource, no statement even needs to be discovered. (There might be interesting material in this for core-protocol-indication in that now we have a metadatum of a transport, that is, through which tunneling endpoint its hidden address can be reached, but that's more for theoretical observation; for practical one I think that discovering the CBORUDP entry point would suffice). HTH c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --sJI7M/WI5299mUK0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmEb76kACgkQOY0REtOk veH7UA//YnL6kUsM7IzLT7TIfYQG8RzTBs0HMcrK+xcd+N93mtM5BEvXjWvwQOoI +pvSrKHcI1AbYjReVRJ30zUnAm3sjB3QiKxieP4OiwjK4T22hBvEyVvuSNecSyQ2 11U6dmbxIv9ugGXHNc/mHtUQ2qW1boHBXWYx9CVRzvzDhD6GYCp0d7GVk3TRx9NO XCNEkAUIoNiy0btjtBdUvOBG1xo+Urgevfd8ZJ62BvnUGhsPqwCccp07VSZkLjmU gfPuHhga8UkKDdM0f9O7OocsCUEHK2y4js1GNEbvF+c0YtZErVQ+B+KhO9i3ZUUb yNQzL4Jswpo3CmqCW3wJgburcueZtvPToDSplFDEIXDLRpGV+BG1p2H5mAw1P7JO S2KLJc12xkScT40SV7Bpp2kcnCV+URtC4MYN8eYY3345SFqkcp1f5tmXnY/OpyO8 yO4HKdTj4Q0RAXOv92i+U1SoNypZQUpOjO8RI8tqZ+an1iU6UNiu0xuCEPXuz9WV pGPKucTf6VriORXW1VjgdnygV9JN64zmmKmbAsbE62O85WTqRGHLOtcR7Rvcct8d VPOHjRAF4eYaUwWZlxxGU+vSQFJIt+Y9mbYpH9f0H7Pd1q+IekASku+ULMRqZtEw sg5Pij0UUZRpMfUaTQFxGcRzD5FFCBHmmiDsdcYCAPRxRM3zmTY= =YgTg -----END PGP SIGNATURE----- --sJI7M/WI5299mUK0-- From nobody Tue Aug 17 18:48:08 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E373A1D76 for ; Tue, 17 Aug 2021 18:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAAtE9E96GzY for ; Tue, 17 Aug 2021 18:48:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1CF3A1D73 for ; Tue, 17 Aug 2021 18:48:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D34B389EC; Tue, 17 Aug 2021 21:53:01 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6S6nU328egCB; Tue, 17 Aug 2021 21:52:56 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F260A389CF; Tue, 17 Aug 2021 21:52:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E8301725; Tue, 17 Aug 2021 21:47:50 -0400 (EDT) From: Michael Richardson To: Christian =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FAms=3DFCss=3F=3D?= cc: Peter van der Stok , core@ietf.org In-Reply-To: References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <8819.1629217674@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 01:48:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Ams=C3=BCss wrote: >> The "CBORUDP" provides for a stateless (i.e. stored in the network) >> record of where the packets come from. > So a bit like HTTP's CONNECT, and because there's CoAP as a transport > and since 8974 it has extended tokens, it can be stateless. Got it. > (Will this be specified for standalone use? I don't know to think of = it > yet, but it's definitely intriguing). It's not like HTTP CONNECT. It's a reverse proxy. The destination is forced by the proxy. In order to remove the memory state of the proxy, we store in the network. For (EDHOC)/PSK-OSCORE over CoAP, the proxy can mess with CoAP options. But, DTLS keeps us from doing that. > If I've formed the right mental model here, there's two things that t= he > proxy can discover on the register (where 2001:db8:1:: might be the > actual network, and 2001:db8:2:: the network that's inside the UDP > tunnels -- may be the same addresses but may be not): Just to clarify, there is no IP header inside the tunnel. > * The endpoint of the CoAP UDP service: > ;rt=3Dcborudp (or ;rt=3Dbrski-yyy) yeah. > If so, and if the analogy from 9031 holds, then what the proxy needs = to > discover is the /udp endpoint. > To that endpoint, it does talk CoAP, so > it's perfectly legitimate to discover it as a CoAP resource. Of the > inside traffic, or its relation to the outside resource, no statement > even needs to be discovered. No, that's not the case. To the proxy, it speaks "cborudp". =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEcZsYACgkQgItw+93Q 3WV9oAf/XyJBia4rhcjZkyTAyh4GzAAd9EilzH8vbuL9vG6HZtbT+kL+6y1KnvNR 5hsrOoywc53Ghkp7spRy5GgOFn05KofdULfuGmUtNkiVocNhS3HYB/6UWWymX44B BpLXOIOgJn+w4skFOsVrASzIDcXvUkbpvPfpzYeTscT/nERUrcMfYjOMsDYfTi6E EX1alIlJfkDTeqU7W9tJthJAWSdfSHhrev5z4Ifm68fr6oF/8nUMyXNsu9sTCvHL RFGTWopowvF18n+Pgpf8xEw0Z1a/i5qgcOsAnfeLWhTwdr77YkwAYP/vOdKKQquy tuHIxTNWLKbqEnL4GPSP1THeyGvVzQ== =C5RG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 18 01:35:46 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271BE3A0045 for ; Wed, 18 Aug 2021 01:35:44 -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, SPF_HELO_NONE=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 50gcltCzC7mh for ; Wed, 18 Aug 2021 01:35:40 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B623A003D for ; Wed, 18 Aug 2021 01:35:38 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0D8AE40104; Wed, 18 Aug 2021 10:35:35 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 739B0D0; Wed, 18 Aug 2021 10:35:33 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8d88:bd61:7974:fcd3]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2E5DE101; Wed, 18 Aug 2021 10:35:33 +0200 (CEST) Received: (nullmailer pid 3946651 invoked by uid 1000); Wed, 18 Aug 2021 08:35:32 -0000 Date: Wed, 18 Aug 2021 10:35:32 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Richardson Cc: Peter van der Stok , core@ietf.org Message-ID: References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <8819.1629217674@localhost> <562.1629251270@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZshKLSG0maazKPch" Content-Disposition: inline In-Reply-To: <562.1629251270@localhost> Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 08:35:44 -0000 --ZshKLSG0maazKPch Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ok, then I misunderstood; next attempt. Would it look roughly like this, then? +-----------+-------------+---------+----------------------+ | IP header | UDP header | CBORUDP | DTLS containing CoAP | +-----------+-------------+---------+----------------------+ where CBORUDP is some self-delimited prefix in which the proxy encodes the pledge's address (probably opaque to the register), and by itself doesn't care what precisely is encapsulated in it. In that case, I'd advertise it either as ;rt=3Dcborudp which just announces that there is some service of that kind without saying what can be done with it (although a more precise rel or rt may say that), or as ;rt=3Dsome...join which'd indicate that coaps can be transported through that and that there is a /j resource available. This'd help the proxy to advertise an own `;rt=3Dsome..join` resource which it doesn't on its own control, but still provides for in its reverse proxy capacity. (Given that resource is probably not discovered, that may be of little use). For me, either would work; announcing a would IMO be misleading if no requests really arrive there through CoAP on DTLS directly on UDP. BR c --=20 Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Terry Pratchett (attributed) --ZshKLSG0maazKPch Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmEcxlAACgkQOY0REtOk veHNMw/+ISM3/0UHH+n1DIipGoW+HtbJjeWVmBW38Kxp9KCd8CViOmYh5nPdmeE8 gcNTtkt+0V3TBW8bpk1fzOZNs32EG94I9ygE4VXelFRlDuGLAVBEvoV83RHt527M 6Xn/B5gn/neA5GdQCE/+sXxjiEXuev+L3V6myekRjmjYWMXfPx83Uc6dBz5XtiPu oQXtrBP2znt97dQRM/RxAlul0mqzYs0dP7HTan5w8f7HKzcu/PX2FUQJ5nbljUhH Hl17MDQf+zdLh1BUL6XxLFFnoJ3gHxSqX5nIGhmGwrqQdIf/NT+cNbVaVpl7jMT6 Kj8zlY0RQ4lapSdMJQDru+sGybnpQn4A1TQ4uyRunZ1P4SoGkwn0sz/OjkIzw67A qxS8AHukSag9aLt6WxX0kiPtKD625I0JEE5zVkAjKd6q9EXyLJXj3MEqpnlhXWhH 9DGHonb/SYF1Oo9Ag60ggoqxLKit6hY7jQZ52btOpHYJ8QE08s7IXUMBs+mmVhVT 4chHEX6yh9+3CDr/Ia/JyGabeBUk/r0a8GOZacO+f1HvJUeWYfJrIcK97hPTA8DN gAF+B1k10CgHaa3g/3f1tiyerz2kwUiI7MrknyXlXp8E09GXaAHiUsEK5kqV2efP GtOWI1ZRYQ00mKZ5xalwIRDUfok1hK/Za7XvQIi/PKBm8860HqE= =pO8j -----END PGP SIGNATURE----- --ZshKLSG0maazKPch-- From nobody Wed Aug 18 01:51:22 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A60B3A081F for ; Wed, 18 Aug 2021 01:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzSfiiCCToVe for ; Wed, 18 Aug 2021 01:51:15 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379433A081C for ; Wed, 18 Aug 2021 01:51:14 -0700 (PDT) Received: from omf03.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 8ADF520BE7; Wed, 18 Aug 2021 08:51:11 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA id 3EF2C13D93; Wed, 18 Aug 2021 08:51:11 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 18 Aug 2021 10:51:10 +0200 From: Peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: Michael Richardson , core@ietf.org Reply-To: stokcons@bbhmail.nl In-Reply-To: References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <8819.1629217674@localhost> <562.1629251270@localhost> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <01c960e06e38c3588c8d3a94e2d14cf3@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy Content-Type: multipart/alternative; boundary="=_6a90e9e9d67d996453b8539a7c961986" X-Stat-Signature: p7uso9idbx6i7pfwsc98pwewoycb3hhw X-Rspamd-Server: rspamout03 X-Rspamd-Queue-Id: 3EF2C13D93 X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Session-ID: U2FsdGVkX1+DzRhD7M/XA24vijtDIcNT4EA1FQo7DAU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:cc:subject:reply-to:in-reply-to:references:message-id:content-type; s=key; bh=F4VwHbc0cG+RMvOEJm2dwb254N/x8AeEiZBd3x7Xn8U=; b=XtrA+j6wiNEcSKgTE8ik+GbzjA5yob2VE/IGeI2h1i+ARnc9T+jcFCrkGXm2AcsMC8Ry1dEa4RvTx8zWGjlSnP2uHdkvLEig31o+KdVoC3bNXsprxqERq+S+UBl3i5NYDSVt+rnE8urHF54EihTVnBnLiysxvoz460Byt7pFsN0= X-HE-Tag: 1629276671-344711 Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 08:51:21 -0000 --=_6a90e9e9d67d996453b8539a7c961986 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed HI Christian, very close indeed. I would prefer: ;rt=some...join for advertizing /j in another context as well. My worries concern the impact on coap and the effort needed to standardize coaps+cborudp, remembering former efforts concerning tcp and coap. Peter Christian Amsüss schreef op 2021-08-18 10:35: > Ok, then I misunderstood; next attempt. Would it look roughly like > this, > then? > > +-----------+-------------+---------+----------------------+ > | IP header | UDP header | CBORUDP | DTLS containing CoAP | > +-----------+-------------+---------+----------------------+ > > where CBORUDP is some self-delimited prefix in which the proxy encodes > the pledge's address (probably opaque to the register), and by itself > doesn't care what precisely is encapsulated in it. > > In that case, I'd advertise it either as > > ;rt=cborudp > > which just announces that there is some service of that kind without > saying what can be done with it (although a more precise rel or rt may > say that), or as > > ;rt=some...join > > which'd indicate that coaps can be transported through that and that > there is a /j resource available. This'd help the proxy to advertise an > own `;rt=some..join` resource which it doesn't > on > its own control, but still provides for in its reverse proxy capacity. > (Given that resource is probably not discovered, that may be of little > use). > > For me, either would work; announcing a would IMO > be misleading if no requests really arrive there through CoAP on DTLS > directly on UDP. > > BR > c --=_6a90e9e9d67d996453b8539a7c961986 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Christian,

very close indeed.

I would prefer:

<coaps+cborudp://[ip]:port/j>;rt=3Dsome...join

for = advertizing /j in another context as well.

My worries concern th= e impact on coap and the effort needed to standardize coaps+cborudp, rememb= ering former efforts 
concerning tcp and coap.

Peter

Christian Amsüss schreef op 2021-08-18 10:35:

= Ok, then I misunderstood; next attempt. Would it look roughly like this,then?

+-----------+-------------+---------+------------------= ----+
| IP header | UDP header  | CBORUDP | DTLS containing CoAP = |
+-----------+-------------+---------+----------------------+
where CBORUDP is some self-delimited prefix in which the proxy encodes<= br />the pledge's address (probably opaque to the register), and by itself<= br />doesn't care what precisely is encapsulated in it.

In that = case, I'd advertise it either as

    <cbo= rudp://[ip]:port>;rt=3Dcborudp

which just announces that ther= e is some service of that kind without
saying what can be done with it= (although a more precise rel or rt may
say that), or as

&n= bsp;   <coaps+cborudp://[ip]:port/j>;rt=3Dsome...join<= br />
which'd indicate that coaps can be transported through that and = that
there is a /j resource available. This'd help the proxy to advert= ise an
own `<coaps://[fe80::...]/j>;rt=3Dsome..join` resource wh= ich it doesn't on
its own control, but still provides for in its rever= se proxy capacity.
(Given that resource is probably not discovered, th= at may be of little
use).

For me, either would work; announ= cing a <coaps://[ip]:port/j> would IMO
be misleading if no reque= sts really arrive there through CoAP on DTLS
directly on UDP.
BR
c
--=_6a90e9e9d67d996453b8539a7c961986-- From nobody Wed Aug 18 02:52:22 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692073A1066 for ; Wed, 18 Aug 2021 02:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLMSdB3z5XgV for ; Wed, 18 Aug 2021 02:52:15 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D3F3A1064 for ; Wed, 18 Aug 2021 02:52:14 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GqNV35SVGz2xYM; Wed, 18 Aug 2021 11:52:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Wed, 18 Aug 2021 11:52:11 +0200 Cc: Michael Richardson , core@ietf.org X-Mao-Original-Outgoing-Id: 650973131.052449-476eb736be27fcab1aee31163b8acd90 Content-Transfer-Encoding: quoted-printable Message-Id: <3803FD50-94F2-484B-940A-3E1EA53EDB97@tzi.org> References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <8819.1629217674@localhost> <562.1629251270@localhost> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 09:52:21 -0000 On 2021-08-18, at 10:35, Christian Ams=C3=BCss = wrote: >=20 > CBORUDP Is =E2=80=9CCBOR=E2=80=9D the main feature of that subprotocol? Maybe we can find a better name. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 18 04:03:33 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C993A13F2 for ; Wed, 18 Aug 2021 04:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1YFhk6TUUMy for ; Wed, 18 Aug 2021 04:03:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAC93A13EF for ; Wed, 18 Aug 2021 04:03:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B5DB389A1; Wed, 18 Aug 2021 07:08:28 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zqguyZSoAWKj; Wed, 18 Aug 2021 07:08:23 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DB2E93899A; Wed, 18 Aug 2021 07:08:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 229439C6; Wed, 18 Aug 2021 07:03:16 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FChristian=5FAms=3DC3=3DBCss=3F=3D?= , core@ietf.org In-Reply-To: <3803FD50-94F2-484B-940A-3E1EA53EDB97@tzi.org> References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <8819.1629217674@localhost> <562.1629251270@localhost> <3803FD50-94F2-484B-940A-3E1EA53EDB97@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 11:03:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2021-08-18, at 10:35, Christian Ams=C3=BCss > wrote: >> >> CBORUDP > Is =E2=80=9CCBOR=E2=80=9D the main feature of that subprotocol? Mayb= e we can find a > better name. Yeah, that's a terrible name, but we didn't make up anything else, because = we didn't think we needed to name it. That's probably a goof. names are alwa= ys important. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEc6PMACgkQgItw+93Q 3WW+MQgAqOm/uM+mva/Bam0cnT7fFlPapqaGSu4mLOPPjL7LAIBZCS9KW8q8cbJx xdtJvff+sghkI1cCfrlAAnJ74gAZDA68/3xVSUKhL3IlPr7soofkJIHNQVPlmrCm lmq/ejKTw5B2fHWtPAMHnjaz1/2Yj9nuBoboIhPi1tUomu5PoPOajxeTg+zoESsZ Yz9G7JGBAz9wcKTXfT1jXruBruOtAgxhdnAEmt3I9nAZASp2hS6Q+54OcP3YxYUB 9lEtgKBlSdpmZdf/qDSSeVLDBbrRGUIxrkuvyD+tLqywCEHskJ0WGPeZ0F9m0eyX 3m0B3wCziyr28/3gwAGcAG4HQJWfRQ== =nfHE -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 18 04:06:50 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62DD3A1426 for ; Wed, 18 Aug 2021 04:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBlem0xSDl92 for ; Wed, 18 Aug 2021 04:06:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC8D3A1428 for ; Wed, 18 Aug 2021 04:06:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 77299389A8; Wed, 18 Aug 2021 07:11:30 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bMvjX9JQHBuR; Wed, 18 Aug 2021 07:11:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 84C5D389A3; Wed, 18 Aug 2021 07:11:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 126469C6; Wed, 18 Aug 2021 07:06:19 -0400 (EDT) From: Michael Richardson To: Christian =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FAms=3DFCss=3F=3D?= , Peter van der Stok , core@ietf.org In-Reply-To: References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <8819.1629217674@localhost> <562.1629251270@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] coap discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 11:06:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Ok, then I misunderstood; next attempt. Would it look roughly like this, > then? +-----------+-------------+---------+----------------------+ | IP header | UDP header | CBORUDP | DTLS containing CoAP | +-----------+-------------+---------+----------------------+ Yes, that's essentially it. Although the "DTLS containing CoAP" is actually embedded in the CBOR. But then, each of the things are embedded in the thing to the left. >In that case, I'd advertise it either as > > ;rt=3Dcborudp Aside from the name, I hate having to make up a new scheme. > For me, either would work; announcing a would IMO > be misleading if no requests really arrive there through CoAP on DTLS > directly on UDP. Agreed. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEc6aoACgkQgItw+93Q 3WWntgf/fodtpzkFOGFgABGieDE4EuzpZ2KTUR7j/FauwkJY09MdSuII0WAdluhG M3htvSk0z7Bf0CvkKdUs10tI9N16pGq7besffvAwhxP0qoNQKx1n2xD0RFKS27q+ Rk3YCMFri+bsjJt6UIqzURRCmSlpoUUXrnjA4Np4ThDD2eoIseUlVXbYESWpjJDb oJ2UrnKhkYu185cr1AckAvu4GuJJWZOZS0kyc2u6CoZV2pgFI2IE0VLL9Yqc/2UZ KYr5w7KSfYGAchYbUxwNh3cImG1tGIlARDP1rob/zFONj0BqCZ3oEYP5Mn2iFZTz lh9YPRkLQhEWlFsYmOPxFYdcCu3U1g== =77D3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 19 05:25:16 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28433A1222 for ; Thu, 19 Aug 2021 05:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeL5n_EVMXEz for ; Thu, 19 Aug 2021 05:25:06 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EE73A11FB for ; Thu, 19 Aug 2021 05:25:06 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Gr3qy1BZwz2xG2; Thu, 19 Aug 2021 14:25:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann Date: Thu, 19 Aug 2021 14:25:01 +0200 X-Mao-Original-Outgoing-Id: 651068701.643208-c7125a0d7288eb5d0bbbebd4bd0a80af Content-Transfer-Encoding: quoted-printable Message-Id: <65E74A10-7B77-4F45-887B-ABECD76FA5CE@tzi.org> References: <20210819055955.GB8102@1wt.eu> To: core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Fwd: Subtle incompatibility between H2 and H1's :path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 12:25:15 -0000 As a little nugget of content during our summer vacations, here is an = interesting observation about URI paths from the HTTP working group = mailing list. AFAICT, RFC 7252 (Sections 5.10.1, 6.5) is already able to handle what = is being proposed here; the comment is mostly relevant to core-href = (which I believe also has all that=E2=80=99s needed). Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Willy Tarreau > Subject: Subtle incompatibility between H2 and H1's :path > Date: 2021-08-19 at 07:59:55 CEST > To: HTTP Working Group > Archived-At: >=20 > Hello, >=20 > after tightening up the :path parser in haproxy to strictly comply = with > both RFC7540 and the latest draft, one user of a large hosting = platform > reported breakage of at least one hosted site which contains a few = HTML > links with the path beginning with two slashes, resulting from the > concatenation of a base URL ending with a slash and a prefix. E.g: >=20 > >=20 > At first I responded "that's expected as it is explicitly forbidden by > the H2 spec (RFC7540), which says": >=20 > "The ":path" pseudo-header field includes the path and query parts > of the target URI (the "path-absolute" production and optionally = a > '?' character followed by the "query" production (see Sections = 3.3 > and 3.4 of [RFC3986])." >=20 > And RFC3986#3.3: >=20 > path-absolute ; begins with "/" but not "//" > path-absolute =3D "/" [ segment-nz *( "/" segment ) ] > segment-nz =3D 1*pchar > segment =3D *pchar >=20 > Then I wondered why before this change the request was processed by = the > HTTP/1.1 backend server, had it been too lenient or was there a = difference > in the protocol spec. The response is the latter. In RFC7230 #2.7, a > purposely different absolute-path is defined: >=20 > An "absolute-path" rule is defined for protocol elements that can > contain a non-empty path component. (This rule differs slightly from > the path-abempty rule of RFC 3986, which allows for an empty path to > be used in references, and path-absolute rule, which does not allow > paths that begin with "//".) >=20 > request-line =3D method SP request-target SP HTTP-version CRLF > request-target =3D origin-form > / absolute-form > / authority-form > / asterisk-form >=20 > origin-form =3D absolute-path [ "?" query ] > absolute-path =3D 1*( "/" segment ) >=20 > And this version is the one that was adopted by the HTTP core spec, = but > the H2 spec keeps its difference with path-absolute that cannot start > with "//", even in the latest draft. >=20 > This use of "path-absolute" was introduced into the H2 spec between = draft > 04 and draft 05 when trying to precise the definition of :path. And I = think > that by then the difference between HTTP/1 and RFC3986's = interpretation of > path-absolute and absolute-path has simply been overlooked. >=20 > Given that in the report above the browsers happily sent the request = using > the HTTP definition of absolute-path and not RFC3986's definition of > path-absolute (thus violating RFC7540), that sites *are* written to = rely > on this, that this seems to be how other H2 implementations are = currently > handling it, and that the new HTTP spec defines the format of a = request-target > in origin form as an absolute-path as well, I think we should fix the = latest > H2 draft to adopt the common definition of absolute-path (which = explicitly > permits "//") and stop keeping a non-interoperable exception here. >=20 > Does anyone disagree ? >=20 > Thanks, > Willy >=20 From nobody Mon Aug 23 13:07:21 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA6B3A1369; Mon, 23 Aug 2021 13:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKNLEg31ZcyB; Mon, 23 Aug 2021 13:07:13 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2042.outbound.protection.outlook.com [40.107.22.42]) (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 0A8F73A1366; Mon, 23 Aug 2021 13:07:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gqKXL+gNUjpAc8Ya8JKXxMS3C68MLDeLFSltcpSX4i7H4w9Uy1sf7BYMTmmWnrfoDmjpWxr6U5NBnHvcONhAatZfAkXyso7n2gnermS09b/CC5JXv3gmmWBoMi5/mtZGbgtJgioVCl9qY7LTUsvfypOwTH06jqqVXg2fUmm1PoPS14jnijkX1hH3bJ5ANbngIecpzUMluJwvfxZGV/99HaiG41QgFIfyJaGkAE/++GK346Txmlx5NncQpqKyLyqLPaq+f6l6xghLMy/9KvJMNbmN+9BytZBBzkdVBTo2HIiSglAxRnl05YsRakMhVixpkom50nE68GbwnETuiS6J6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZUcoJMQ0chciHkf7zLGCr2TiEi4ZpWyrjINZa5p5EGM=; b=PxRJN93moKiojzWi9QQWcKMiuGxPpMNv08wocvuMUtqzl6suASQgczp6F7PYAyAubGpSzfry7UUlg+TpEnPSXFGsmSwGwqXXDiZJRzRA21pYGaWRIfRdMqKNhgPI+eOg1qugNMZhUnP+B2j7EuHfN5Yrv0lJER5wZUdCh/6HQ5tafJw8FmNvfyvw6mFkLn3bKcgpzP9GHv8jh4A6TJb5T0O0pjAnFdSG3r6aWKK4wX6r0TmrYauHp84SI8KslmxyJwm3mw1UcTRn7mnvpWrM3PcWSSBLFmvWf7rTdBQnshlm5A2/A6dLJ4JXyRlQw1pY4D480k3jfp9ab2ZzU1x6yQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZUcoJMQ0chciHkf7zLGCr2TiEi4ZpWyrjINZa5p5EGM=; b=SYL03FMlEsX8uOCTvSO6HR5Lyv1JkpeSiWKXbc5AGCbdW7GEE93Uxy+2BK4z9sK5TJJfL933Y+2aLvfXCx/CVCgrcfvCbXSE3V8j9dRWj9oA/9l0u3D9xsEVhCHbzyxNRml9Cr8NrjUslJ4XtS8eNiBzKKe+AQL339KwDhIAgQ0= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2972.eurprd07.prod.outlook.com (2603:10a6:3:56::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.16; Mon, 23 Aug 2021 20:07:04 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6536:1eff:d4ae:d51a]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6536:1eff:d4ae:d51a%7]) with mapi id 15.20.4436.024; Mon, 23 Aug 2021 20:07:04 +0000 From: Francesca Palombini To: "draft-ietf-core-senml-data-ct.all@ietf.org" , "core@ietf.org" Thread-Topic: AD review of draft-ietf-core-senml-data-ct-04 Thread-Index: AQHXmFpxg9dovoeIP066E1NsHR9gTg== Date: Mon, 23 Aug 2021 20:07:04 +0000 Message-ID: <8DC48816-852A-47D9-B533-37D9FB69E97A@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8340b311-1818-43f6-a99a-08d9667193ae x-ms-traffictypediagnostic: HE1PR0701MB2972: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hAwe9/P6X9fFwQ+o6Tq0jouEk1WdOrh3CHog9YmfUnMsVFXjRTL15b3o3hxngsd36vKIDRtBoWceuZtv6AQ0+AO+JB4L7LRQAMmfVBETxuNg5PRx3LGculGqwoF+XgUS4unlHPQDlp93hi3MQxvaQjLcUbFAqagf1Zj+EB5pnKcy31b3h9xmLtkaFS7GM/vch3vio84jZjahTchF9p8KiQgC9xCZ2cYf1+ucwyQX4P6ZtUVxNfxMvOde6KAnLQMKrf1Yxpd0iIvSJ5tBUHPulDFVTxpR7CBt+nEKieh+QN2aqN0lRnmb7cLwlVGqyO9sC5iRbW9CCTD9hqBSAckxHyAl0TE6RIHEXNMXWJTDjJVgP13DqTpMPQgNEAqiDAAp8c4Qo1V6GKjK4P3DpHO7AMia5SWj8bqaOy3vBVCNRV5umQ9TzygdNfhYJvyqfVIPMxZfJ46dHaPhvvVSsFL1GH9CUgnKIfNNr6slu4NF22n2jFMv2HUoLZm3DqpIbOz9c8VldO+oinTM/bjH2BWHmCetOC9iYE/e4Ldm7lcVunQ4wQ7P7iNdkpHK2ZpL6VtfxnSYgxJG/18lm4x11dyzUstvQgf3G8BN/P9BWGcnCAz+4pWXPh0OxHfst6ljvdlnCeu8aWiGz/ybJ6HegRvUJV4qGTQeUALy9oNYvLDW9iw5z3lFLr8Cd4Ydt5W5/y2IRDf8Lchg5HMvXIgi7r49Hw+KL0nI8YkFZAhvKF8XXkPntBzkoinIn2Dbr6da8FM8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(39860400002)(346002)(396003)(8936002)(6506007)(6512007)(86362001)(2616005)(83380400001)(38100700002)(8676002)(76116006)(66946007)(66476007)(64756008)(66446008)(5660300002)(66556008)(2906002)(478600001)(110136005)(71200400001)(6486002)(186003)(316002)(122000001)(450100002)(38070700005)(36756003)(33656002)(44832011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eFlIVm9WcUhwR1RwRzBWdHpmNzg1SURXNTkvKzNreFZwSXBlTlNpSHJ5Z0M5?= =?utf-8?B?bytSZVNiRU1iT0RTL1FESGc0OVdNMVovNHNIMzRkOWx2SDAxcG1zNGFHK3Jl?= =?utf-8?B?eDlxVVAyV1VQZ2ZtMXpDVVRLOHNvcllVcVNnU05pT3dwUlArZE9TNjVsRDVy?= =?utf-8?B?WmhUQXZ5b2RSMGpPMHZqd0JHV0xYdml1bWxGemR4SGNrdVE0OHRyMU1KZUFG?= =?utf-8?B?dVBMVjIzKzJTY29xMmJaanVaMjBVNGU0VnUvUDB2UnpTSGlPSGdVRmREYXMz?= =?utf-8?B?MXJLNW13Q2ZvMjFmRDQ3UDQrbmNzOThHSjRMRCt3UGEyKzBiVTZQbmFaa1dz?= =?utf-8?B?WkhKNGNOMFVpZUZBNy9nU08yZWMxRjAzMitHenFMRVhKTUZjem5iRDFab1o4?= =?utf-8?B?VFh1djA4OUs0OUcrNlZrRlFqT01FdG9SU0lPVk1CRUJKSjdOTXZLY1pOTHFk?= =?utf-8?B?elBXK29tM25WSjFFNkY3enJpVHdPU1VWbUdyMy9FbVp1NEdwendLRWdMMFNu?= =?utf-8?B?THRLMENJZkg1cnlXRTh4d0RKRGRqNEp5M3hnaFdLWnJMTUtQTlhqVnlqYXlv?= =?utf-8?B?eVJqU1pzNjNhc2g1WGV5Zy9XYjY3SGVyQUVLT29wNHdMbFZJOGo4TjdERlFD?= =?utf-8?B?RGNxdTRSYjJKVFArdDI3cmJjdTlXYVB2MUh5dDB6SjVqOGRtWEQ5WkdHZUp0?= =?utf-8?B?YlRsRnZHWTBGMTI2d2FUTnBRSnowVFZ5cCtwMEdQYmozeVhQcnVVRlBXRi9N?= =?utf-8?B?cEM1TGlMS3BwWnltRm9hOXdxQ3liZmFQU2dYbHpOalZWRWRvbzYrNWFxV0xx?= =?utf-8?B?WU9jZEdibnQ0QVB2citTUjZCcnM1cUd4OUdpOXVUaytzQXF2dy9XMkxabk40?= =?utf-8?B?RzZqTm9nZ1JiOUJMS3Y3VGtHZ0hhOFBheFF6U1JObHZaM0ZaTHpJWk1UcWFI?= =?utf-8?B?Z29XRGFQcWZGZVRXTGlhM041MGVJbFlmUE05cDhSU3VaZTlYOEpnWGwrRzNG?= =?utf-8?B?QzNKT3JWS1FmSXorVkxDM2ZZQkx4OFpDRFp1NGhLYWp6eEFHNTNwU0xyTmFL?= =?utf-8?B?eXlNSjlwMWlrT1AydklQeTcwWEsxUzdScWV3KzJINGUrbENsL1kyZjlaWjZq?= =?utf-8?B?ZXY0RWllN0F4Zm1iOFFNTU9JSy9GT0Q0MnNkZnQ3VjAwcy9KZm1PVFc0Szdx?= =?utf-8?B?Z1ViOGFsa2Z6ZzBYT1hYWnBwNFlPNHh0Q3dFMFBFenRUVE1LYzJvWmhQLzlT?= =?utf-8?B?SWF5UFppMXlrVkVRV3M0N3BtQjBYdlNFbmgraHFnUlJPVFBvZVFSeDRHMmNR?= =?utf-8?B?LzRTNVg3U0VoeDU0VEh4enpOR01teS9GYmc1QXg3ZExqL0E1bkFGdjhKM3Vn?= =?utf-8?B?bVRUdmdkcUFZWFRTYVZZeFllK0M3UFdJbXpkVFRYZG0wMGlEbXc5ODBESFZY?= =?utf-8?B?aWZBQitEZC9zaDBUUS8vVVd6cDJmS1d6VExSL1VXRFBQblBRUXZ1K3BCTWUw?= =?utf-8?B?SHRVOGRPV201SWVUVDA0aGlwYzhDU3FXaUVtd1NvMXN2RDk5VEJMN01aMEdR?= =?utf-8?B?RFVjVEFuVXNmdFJDZms5RWJPMnZ2QkNPYWhzZXlpYTVZamNjUVdwM3ZvUFpT?= =?utf-8?B?K25wOEJTbDRTVnZYQ0tHNjR6S2U5eWNGQWN4WUNzMTFlT3RiZy8rQ2FJNVBL?= =?utf-8?B?S2hUd2NnaHp1UDk5ekRJOFZ1UTdSbE5JRklIMTNyY3p6NTR2YXBLTTZBYS9N?= =?utf-8?B?dzFIS3FFQnJYQk9SVW1PYVlvaFBIenRvYTg0ZVl4VlRDRmYwOWVaOXI3QmY1?= =?utf-8?B?aWNvS096NzY3dUFHSnFhZW1RNHZvUUVKQnF6REJMVWM2ZTBRRTlMTjRUWUh1?= =?utf-8?B?U1VJNnFNNGprNFJMWGJKclNqQ0doc1pYOUI3L2JmU1RLUHc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <140F059E2359CF4E9582AAAAD5C10ADB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8340b311-1818-43f6-a99a-08d9667193ae X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2021 20:07:04.3531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yDWOt2xEbaYuyX93bh7d3xTwVuXBXCM02LLzoL4uJKOOXQk1ZgTF7WpjA5MkYyGAijnnP2ZeuVZdc1pVPH0Uoi1yswS51ZVhmpMghBgNcOQ96jsnCM9JkWnMG0J5sOy9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2972 Archived-At: Subject: [core] AD review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 20:07:19 -0000 VGhhbmsgeW91IGZvciB0aGUgd29yayBvbiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgdGFrZSBjYXJl IG9mIHRoZXNlIG1pbm9yIGNvbW1lbnRzIGF0IHRoZSBzYW1lIHRpbWUgYXMgdGhlIExhc3QgQ2Fs bCBjb21tZW50cy4NCg0KRnJhbmNlc2NhDQoNCjEuIC0tLS0tDQoNCkZQOiBGaXJzdCBvZiBhbGws IEkgd2FudGVkIHRvIGNvbmZpcm0gd2l0aCB0aGUgV0cgdGhhdCB0aGUgc3RhdHVzICJwcm9wb3Nl ZCBzdGFuZGFyZCIgaXMgdGhlIGFwcHJvcHJpYXRlIG9uZSBoZXJlLiBKdXN0IG1ha2luZyBzdXJl IHRoaXMgd2FzIGNvbnNpZGVyZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgYW5kIHRoZSBhdXRob3Jz LCBhcyBJIG5vdGUgdGhhdCB0aGUgc3RhbmRhcmQgdHJhY2sgaXMgbm90IG5lZWRlZCBmb3IgdGhl IElBTkEgcmVnaXN0cmF0aW9ucywgd2hpY2ggcmVxdWlyZSBvbmx5IGV4cGVydCByZXZpZXcuDQoN CjIuIC0tLS0tDQoNCiAgIHVzZWQgdG8gc2VuZCB2YXJpb3VzIGtpbmRzIG9mIGRhdGEuICBJbiB0 aGUgZXhhbXBsZSBnaXZlbiBpbg0KICAgRmlndXJlIDEsIGEgdGVtcGVyYXR1cmUgdmFsdWUsIGFu IGluZGljYXRpb24gd2hldGhlciBhIGxvY2sgaXMgb3BlbiwNCiAgIGFuZCBhIGRhdGEgdmFsdWUg KHdpdGggU2VuTUwgZmllbGQgInZkIikgcmVhZCBmcm9tIGFuIE5GQyByZWFkZXIgaXMNCiAgIHNl bnQgaW4gYSBzaW5nbGUgU2VuTUwgcGFjay4NCg0KDQpGUDogTWlnaHQgYmUgd29ydGggc3RhdGlu ZyBpbiB0aGUgc2VudGVuY2UgYWJvdmUgdGhhdCB0aGUgZXhhbXBsZSB1c2VzIEpTT04gYW5kIGJh c2U2NCBlbmNvZGluZy4NCg0KMy4gLS0tLS0NCg0KDQogICBNZWRpYS1UeXBlLU5hbWU6ICBBIGNv bWJpbmF0aW9uIG9mIGEgdHlwZS1uYW1lIGFuZCBhIHN1YnR5cGUtbmFtZQ0KICAgICAgcmVnaXN0 ZXJlZCBpbiBbSUFOQS5tZWRpYS10eXBlc10gYXMgcGVyIFtSRkM2ODM4XSwgY29udmVudGlvbmFs bHkNCiAgICAgIGlkZW50aWZpZWQgYnkgdGhlIHR3byBuYW1lcyBzZXBhcmF0ZWQgYnkgYSBzbGFz aC4NCg0KRlA6IFJGQyA2ODM4IGlzIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSwgSSB3b25kZXIg aWYgaXQgd291bGRuJ3QgbWFrZSBtb3JlIHNlbnNlIHRvIGJyaW5nIGl0IHVwIHRvIG5vcm1hdGl2 ZSwgZ2l2ZW4gdGhhdCB0eXBlLW5hbWUgYW5kIHN1YnR5cGUtbmFtZSAoYW5kIG1lZGlhIHR5cGVz IGluIGdlbmVyYWwpIG5lZWQgdG8gYmUgdW5kZXJzdG9vZCBpbiB0aGlzIHNwZWNpZmljYXRpb24u DQoNCjQuIC0tLS0tDQoNCiAgIENvbnRlbnQtVHlwZTogIEEgTWVkaWEtVHlwZS1OYW1lLCBvcHRp b25hbGx5IGFzc29jaWF0ZWQgd2l0aA0KICAgICAgcGFyYW1ldGVycyAoc2VwYXJhdGVkIGZyb20g dGhlIG1lZGlhIHR5cGUgbmFtZSBhbmQgZnJvbSBlYWNoIG90aGVyDQogICAgICBieSBhIHNlbWlj b2xvbikuICBJbiBIVFRQIGFuZCBtYW55IG90aGVyIHByb3RvY29scywgdXNlZCBpbiBhDQoNCkZQ OiBQbGVhc2UgYWRkIGEgcmVmZXJlbmNlIHRvIHRoZSBSRkMgZGVmaW5pbmcgbWVkaWEgdHlwZXMg cGFyYW1ldGVycy4NCg0KNS4gLS0tLQ0KDQogICAgICAiQ29udGVudC1FbmNvZGluZyI7IHdlICpu ZXZlciogdXNlIHRoaXMgdGVybSAoZXhjZXB0IHdoZW4gd2UgYXJlDQogICAgICBpbiBlcnJvciku DQoNCkZQOiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhlIGdvYWwgb2Ygd2hhdCBzdGF0ZWQgaW4g cGFyZW50aGVzaXMuDQoNCjYuIC0tLS0tDQoNCkZQOiBUaGVyZSBpcyBhIHN1YnRsZSBkaWZmZXJl bmNlIGJldHdlZW4gQ29udGVudC1Gb3JtYXQgYW5kIENvbnRlbnQtRm9ybWF0LVNwZWMsIHRoZSBs YXR0ZXIgYmVpbmcgdGhlICJzdHJpbmcgcmVwcmVzZW50YXRpb24iIG9mIHRoZSBmb3JtZXIuIEJ5 IHJlYWRpbmcgdGhlIHR3byBkZWZpbml0aW9ucywgaXQgZG9lcyBmZWVsIGxpa2UgdGhlIHNhbWUg dGhpbmcgaXMgc3BlY2lmaWVkIHR3aWNlLCBpdCBtaWdodCBiZSB3b3J0aCBtb3ZpbmcgdGhlIGZv bGxvd2luZyB0byBDb250ZW50LUZvcm1hdC1TcGVjOg0KDQogICAgICAgLCBpZGVudGlmaWVkIGJ5 ICgxKSBhIG51bWVyaWMgaWRlbnRpZmllciBkZWZpbmVkIGJ5IHRoZQ0KICAgICAgIkNvQVAgQ29u dGVudC1Gb3JtYXRzIiBzdWJyZWdpc3RyeSBvZiBbSUFOQS5jb3JlLXBhcmFtZXRlcnNdIGFzDQog ICAgICBwZXIgW1JGQzcyNTJdIG9yICgyKSBhIENvbnRlbnQtRm9ybWF0LVN0cmluZy4NCg0KQWxz bywgQ29udGVudC1Gb3JtYXQtU3BlYyByaWdodCBub3cgbWVudGlvbnMgIkNvbnRlbnQtRm9ybWF0 IG51bWJlciIuIElmIHlvdSBkb24ndCBkbyB0aGUgY2hhbmdlIGFib3ZlLCBpdCBtaWdodCBiZSB3 b3J0aCBhZGRpbmcgdGhlIGZvbGxvd2luZyBjbGFyaWZpY2F0aW9uOg0KDQpPTEQ6DQogICBDb250 ZW50LUZvcm1hdDogIHRoZSBjb21iaW5hdGlvbiBvZiBhIENvbnRlbnQtVHlwZSBhbmQgYSBDb250 ZW50LQ0KICAgICAgQ29kaW5nLCBpZGVudGlmaWVkIGJ5ICgxKSBhIG51bWVyaWMgaWRlbnRpZmll ciBkZWZpbmVkIGJ5IHRoZQ0KICAgICAgIkNvQVAgQ29udGVudC1Gb3JtYXRzIiBzdWJyZWdpc3Ry eSBvZiBbSUFOQS5jb3JlLXBhcmFtZXRlcnNdIGFzDQogICAgICBwZXIgW1JGQzcyNTJdIG9yICgy KSBhIENvbnRlbnQtRm9ybWF0LVN0cmluZy4NCk5FVzoNCiAgIENvbnRlbnQtRm9ybWF0OiAgdGhl IGNvbWJpbmF0aW9uIG9mIGEgQ29udGVudC1UeXBlIGFuZCBhIENvbnRlbnQtDQogICAgICBDb2Rp bmcsIGlkZW50aWZpZWQgYnkgKDEpIGEgbnVtZXJpYyBpZGVudGlmaWVyIGRlZmluZWQgYnkgdGhl DQogICAgICAiQ29BUCBDb250ZW50LUZvcm1hdHMiIHN1YnJlZ2lzdHJ5IG9mIFtJQU5BLmNvcmUt cGFyYW1ldGVyc10gYXMNCiAgICAgIHBlciBbUkZDNzI1Ml0gKHJlZmVycmVkIHRvIGFzIENvbnRl bnQtRm9ybWF0IG51bWJlcikgb3IgKDIpIGENCiAgICAgIENvbnRlbnQtRm9ybWF0LVN0cmluZy4N Cg0KKENvbnRlbnQtRm9ybWF0IG51bWJlciBpcyB1c2VkIGFsc28gaW4gc2VjdGlvbiAzKQ0KDQo3 LiAtLS0tLQ0KDQpGUDogSSB3b3VsZCBoYXZlIGFwcHJlY2lhdGVkIGFuIGV4YW1wbGUgb2YgdXNl IG9yIHRoZSAiYmN0IiBmaWVsZCBpbiBTZWN0aW9uIDQuDQoNCjguIC0tLS0tDQoNCkZQOiBJIHRo aW5rIGFuIGV4YW1wbGUgdXNpbmcgYSBDb250ZW50LUZvcm1hdC1TdHJpbmcgaW5jbHVkaW5nIGEg cGFyYW1ldGVyIGNvdWxkIGhhdmUgYmVlbiB1c2VmdWwuDQoNCjkuIC0tLS0tDQoNCkZQOiBJbiBT ZWN0aW9uIDgsIHNldmVyYWwgY29sdW1ucyBmb3IgdGhlIHJlZ2lzdHJhdGlvbiBvZiBTZW5NTCBs YWJlbHMgYXJlIG1pc3Npbmc6IENCT1IgbGFiZWwsIGV4aSBJRC4NCg0K From nobody Mon Aug 23 14:23:32 2021 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 AF1723A1B4F; Mon, 23 Aug 2021 14:23:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk CC: Jaime Jimenez , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml-data-ct@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <162975380989.1495.11054637843809011378@ietfa.amsl.com> Date: Mon, 23 Aug 2021 14:23:30 -0700 Archived-At: Subject: [core] Last Call: (SenML Data Value Content-Format Indication) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:23:31 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'SenML Data Value Content-Format Indication' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Aug 25 06:30:25 2021 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 2DF023A0879; Wed, 25 Aug 2021 06:30:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana via Datatracker To: Cc: core@ietf.org, draft-ietf-core-senml-data-ct.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162989820511.22802.13018106629607951033@ietfa.amsl.com> Reply-To: Bron Gondwana Date: Wed, 25 Aug 2021 06:30:05 -0700 Archived-At: Subject: [core] Artart last call review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 13:30:14 -0000 Reviewer: Bron Gondwana Review result: Ready with Nits This is a last-call review as part of the ARTART review team, of the document draft-ietf-core-senml-data-ct-04. This document describes an extension to RFC 8428 (SenML) to indicate the media type and content-coding. It is mostly easy to understand, however there is a missing reference to one registry, and some phrases that may be confusing. The missing registry is here: http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding (I found it by following normative references, however other similarly registered data fields in this document link to their registries, and could likewise be found by following references) The document specifies `Content-Coding` as: Content-Coding: a registered name for an encoding transformation that has been or can be applied to a representation. Confusingly, in HTTP the Content-Coding is then given in a header field called "Content-Encoding"; we *never* use this term (except when we are in error). I found this quite confusing, and it also comes across as very snarky and suggesting infighting. I suggest removing the "except when we are in error" entirely. I also found "has been or can be" is also confusing. In the context of this document, I understood Content-Coding in a `ct` field to mean that said coding HAS BEEN applied to the value in `vd`, however this wording makes me question that assumption. Maybe something like this is sufficient? Content-Coding: a name registered in [IANA.content-coding] as specified by [RFC7230]. Confusingly, in HTTP the Content-Coding is found in a field called "Content-Encoding", however "Content-Coding" is the correct term. The other confusing section was this in section 3: If no "@" sign is present outside the media type parameters, the Content-Coding is not specified and the "identity" Content-Coding is used -- no encoding transformation is employed. "If no @ sign is present outside" is a really clunky turn of phrase that left me more confused than the examples! I assume this construction was used because theoretically an '@' sign could be present inside the media-type, or inside a parameter, if correctly quoted. I would suggest at least changing "present outside" to after, or trailing, or something. Maybe this? If no "@" sign is present after the media-type parameters, then no Content-Coding has been specified, and the "identity" Content-Coding is used -- no encoding transformation is employed. Other than those two slightly confusing bits, great document - I enjoyed reading it and the intentions, purpose and use of this document are clear. From nobody Wed Aug 25 10:52:09 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70F73A120A; Wed, 25 Aug 2021 10:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC4cFaPS2ULY; Wed, 25 Aug 2021 10:51:50 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D263A1201; Wed, 25 Aug 2021 10:51:48 -0700 (PDT) Received: from [192.168.217.118] (p548dc8d5.dip0.t-ipconnect.de [84.141.200.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Gvtp91dyDz2xY3; Wed, 25 Aug 2021 19:51:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162989820511.22802.13018106629607951033@ietfa.amsl.com> Date: Wed, 25 Aug 2021 19:51:44 +0200 Cc: art@ietf.org, last-call@ietf.org, draft-ietf-core-senml-data-ct.all@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 651606704.662935-5aa696863cfea984958527d0dd4247e4 Content-Transfer-Encoding: quoted-printable Message-Id: <8AE2D0CA-C259-4E4A-8369-601D750DAA9D@tzi.org> References: <162989820511.22802.13018106629607951033@ietfa.amsl.com> To: Bron Gondwana X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 25 Aug 2021 17:51:59 -0000 Hi Bron, Thank you for this quite actionable review! > It is mostly easy to understand, however there is a missing reference = to one > registry, and some phrases that may be confusing. >=20 > The missing registry is here: > = http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#cont= ent-coding > (I found it by following normative references, however other similarly > registered data fields in this document link to their registries, and = could > likewise be found by following references) I completely agree that we need to become better in identifying the = registries that we are using. Fix below. > The document specifies `Content-Coding` as: >=20 > Content-Coding: a registered name for an encoding transformation > that has been or can be applied to a representation. = Confusingly, > in HTTP the Content-Coding is then given in a header field called > "Content-Encoding"; we *never* use this term (except when we are > in error). >=20 > I found this quite confusing, and it also comes across as very snarky = and > suggesting infighting. =20 (It=E2=80=99s more about being humbled by having made the same mistake = before, say in Section 12.3 of RFC 7252=E2=80=A6) > I suggest removing the "except when we are in error" > entirely. >=20 > I also found "has been or can be" is also confusing. In the context = of this > document, I understood Content-Coding in a `ct` field to mean that = said coding > HAS BEEN applied to the value in `vd`, however this wording makes me = question > that assumption. That text was stolen from RFC 7231: Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are But =E2=80=9Ccan be" here probably is more about Accept-Encoding, for = which we don=E2=80=99t have an equivalent in SenML, so we can leave this = aspect out. > Maybe something like this is sufficient? >=20 > Content-Coding: a name registered in [IANA.content-coding] as = specified by > [RFC7230]. Confusingly, in HTTP the Content-Coding is found in a = field called > "Content-Encoding", however "Content-Coding" is the correct term. Combining some better use of references (see your point above) with this = input, I came up with: Content-Coding: A name registered in the HTTP Content Coding registry [IANA.http-parameters] as specified by Section 8.5 of [RFC7230], indicating an encoding transformation with semantics further specified in Section 3.1.2.1 of [RFC7231]. Confusingly, in HTTP the Content-Coding is found in a header field called "Content-Encoding", however "Content-Coding" is the correct term. (Links in the HTML version on every section or registry reference, which = are not visible in this plaintext copy-paste.) Now in https://github.com/core-wg/senml-data-ct/commit/90a3deb > The other confusing section was this in section 3: >=20 > If no "@" sign is present outside the media type parameters, the > Content-Coding is not specified and the "identity" Content-Coding is = used --=20 > no encoding transformation is employed. >=20 > "If no @ sign is present outside" is a really clunky turn of phrase = that left > me more confused than the examples! I assume this construction was = used > because theoretically an '@' sign could be present inside the = media-type, or > inside a parameter, if correctly quoted. I would suggest at least = changing > "present outside" to after, or trailing, or something. >=20 > Maybe this? >=20 > If no "@" sign is present after the media-type parameters, then no > Content-Coding has been specified, and the "identity" Content-Coding = is used -- > no encoding transformation is employed. I restructured the paragraph along these lines: To indicate that a Content-Coding is used with a Content-Type, the Content-Coding value is appended to the Content-Type value (media type and parameters, if any), separated by a "@" sign. For example (using a Content-Coding value of "deflate" as defined in Section 4.2.2 of [RFC7230]): text/plain; charset=3Dutf-8@deflate If no "@" sign is present after the media type and parameters, then no Content-Coding has been specified, and the "identity" Content- Coding is used -- no encoding transformation is employed. (Again, a link in the HTML version on the section reference.) Now in https://github.com/core-wg/senml-data-ct/pull/4/commits/4d994bb > Other than those two slightly confusing bits, great document - I = enjoyed > reading it and the intentions, purpose and use of this document are = clear. Thank you! Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 30 10:58:01 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BBB3A1C07; Mon, 30 Aug 2021 10:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGx5MgWxWlt7; Mon, 30 Aug 2021 10:57:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7A2EA3A1C04; Mon, 30 Aug 2021 10:57:46 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17UHvZPO014853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Aug 2021 13:57:40 -0400 Date: Mon, 30 Aug 2021 10:57:34 -0700 From: Benjamin Kaduk To: Christian =?iso-8859-1?Q?Ams=FCss?= Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, core@ietf.org Message-ID: <20210830175734.GN96301@kduck.mit.edu> References: <161362172020.28530.15247844895355003249@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 Aug 2021 17:57:53 -0000 Hi Christian, My apologies for the slow response as well. I don't think I have as good of an excuse... I am really happy with the direction taken in the -13 and will reballot after sending this, with some editorial/nit remarks. On Sun, Jul 18, 2021 at 10:38:17PM +0200, Christian Amsüss wrote: > Hello Ben, > > thanks for your input on echo-request-tag, and apologies for the delay > in processing them to completion -- I should have taken your note on > "fairly substantive comments that might result in significant text > changes" more seriously. > > Please see [1] for a few general comments; here are individual responses > to your comments (with suggested terms / phrases that were accepted and > similar small items removed from the list): > > > Thank you for working on this document; these mechanisms are important > > and will help fill some long-standing gaps in CoAP operation. That > > said, I do have some fairly substantive comments that might result in > > significant text changes. > > > > While I recognize that there is going to be a spectrum of requirements > > for determining freshness, I would have expected the far extreme of that > > spectrum to include a strongly time-limited single-use cryptographic > > nonce (akin to what the ACME protocol of RFC 8555 uses but with time > > limit), as well as discussion of some points on the spectrum and which > > ones might be more or less appropriate in various cases. I do see some > > discussion of different use cases, but not much about the tradeoffs > > along the spectrum, and no discussion at all about the strongest > > properties that it is possible to obtain with this mechanism. > > This spectrum, with the axes kind-of-freshness and > authority-over-synchronized-property, is now described in a new > Characterization of Echo Applications subsection, which includes > limited-time-single-use as a combined form of kind-of-freshness. > > Particularly the part that deals with unique-but-predictable Echo values > is frequently referenced later, and also mentioned in [1] as > GENERIC-SHORT-ECHO. > > (It also addresses Roman's "helpful to explicitly state".) > > > In several places we mention that the Echo option enables a server to > > "synchronize state", which to me is a confusing or misleading > > characterization -- as I understand it, both additional (application) > > protocol mechanism and constraints are required in order for state > > synchronization to occur. Specifically, the client has to be the > > authority for the state in question, and the application protocol needs > > to specifically indicate under what conditions and which state is to be > > synchronized. In essence, the Echo option provides a mechanism for > > ensuring request freshness, and that mechanism is leveraged by the > > application protocol to make a synchronzed transfer of state from client > > to server. But AFAICT it is not a generic state synchronization > > mechanism, the state to be synchronized is not conveyed in the option > > body, etc. My preference would be to take "synchronize state" out of > > the primary list of what is possible and mention it in a separate > > sentence as something that can be constructed using the functionality > > that the Echo option provides. > > State synchronization is indeed something that can be done with > freshness; text was tweaked to make that more visible. It's still > mentioned often together with freshness, as it is a very important class > of use cases. That the state is not carried inside the Echo option is > now emphasised in the applications list. > > On the topic of authority, this is now covered in the characterization > of Echo applications (see also GENERIC-SHORT-ECHO). > > > There are a couple places where we recommend (implicitly or explicitly) > > a sequential counter in contexts that might otherwise use a randomized > > value. I think I mention them all in my section-by-section comments, > > but in general the sequential counter might be placing too strong a > > requirement on the value, and the considerations of > > draft-gont-numeric-ids-sec-considerations seem relevant. > > Under the threat model of pearg-numeric-ids-generation, relevant > identifiers are outer Request-Tag and outer Echo values of OSCORE (as > inner and DTLS protected ones are protected by message integrity, and > Token rules are only updated for DTLS where it is protected as well). The network attacker is definitely the most important case to cover, and I agree with your assessment for that case. I think the PEARG work does also consider some other cases where there can be information leakage even to the intended recipient, but those tend to result from a counter on one endpoint that is global across all endpoints (and thus can reveal information about what's happening with endpoints other than the one receiving the values). It would be a bit of a stretch for that to apply here (I guess it could happen for something like an integrity protected timestamp that has the actual timestamp in the clear, but where the timestamp is only updated in a way that depends on the global traffic pattern at the server, and so if the client sees timestamps that don't correspond to its own traffic the client can learn something about other traffic), though... > For the remaining cases, a paragraph has been added to the privacy > considerations section. ...so I think it's fine to call this "good enough" and leave it as-is. > > I think it would also be enlightening to have a comparison between the > > anti-replay/freshness properties provided by the optional DTLS replay > > protection mechanism and the Echo option. I know they have differences, > > but I think there is also some commonality, and giving readers guidance > > on whether one vs the other suffices or both are needed could be useful. > > Such a comparison was attempted, but found to be tied too deeply into > core-coap-attacks; an issue has been opened at > https://github.com/EricssonResearch/coap-actuators/issues/8. Ok. Thank you for attempting the comparison (and it's interesting even to learn that it's tied into the core-coap-attacks work!) > That comment did inspire a paragraph on the relationship between > Request-Tag and replay protection, which did get more interesting when > the document was adapted in awareness of DTLS's option to not use replay > protection at all. Yes, that paragraph seems quite helpful to have! > > Section 2.3 > > > > Upon receiving a 4.01 Unauthorized response with the Echo option, the > > client SHOULD resend the original request with the addition of an > > Echo option with the received Echo option value. [...] > > > > [just noting that IIUC the revised requirements on token generation made > > later in this document are needed in order for this "resend the original > > request" to be safe" ... I am not sure if it needs to be called out here > > specifically, though.] > > If the client does not increment the token, it would be susceptible to > the 4.01 response being reinjected, so it may try again -- but as it is > not incrementing tokens, the server processes the request only once > anyway (but the client is left ignorant of its success). > > So yes there are some light implications (and more severe ones in corner > cases), but the trouble from token reuse is so much bigger than this one > case that pointing it out specifically would probably distract more than > help. Ok, makes sense. > > I don't think the example of this in Figure 3 meets the requirements, > > though, since the echo option value is just a counter that is easily > > spoofable. > > It does meet the particular requirement of the above paragraph > ("different except with negligible probability") as it is just counting > up (where after 255 events it'd overflow to two bytes and further). > > For the general requirements, these should now be clearer (see > GENERIC-SHORT-ECHO). > > > [...] When used to demonstrate > > reachability at a claimed network address, the Echo option SHOULD > > contain the client's network address, but MAY be unprotected. > > > > What does "contain" mean, here? Plaintext? That seems potentially > > problematic; using it as an input to the MAC that is not transmitted (as > > I mention later) is more conventional, in my understanding. > > That's what it should have said in the first place; fixed. > > > The CoAP client side of HTTP-to-CoAP > > proxies SHOULD respond to Echo challenges themselves if they know > > from the recent establishing of the connection that the HTTP request > > is fresh. Otherwise, they SHOULD respond with 503 Service > > Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive > > connection. If the HTTP request arrived in Early Data, the proxy > > SHOULD use a 425 Too Early response instead (see [RFC8470]). They > > MAY also use other mechanisms to establish freshness of the HTTP > > request that are not specified here. > > > > Where is the MUST-level requirement to actually ensure freshness (by > > whatever mechanism is available/appropriate)? > > That was indeed missing; the "they SHOULD respond with" was intended to > leave room for other methods of obtaining freshness, not to just ignore > the issue and respond to the Echo challenge unchecked. A "MUST NOT > repeat an unsafe request and [SHOULD]" was added. > > (The exception for safe methods allows filling caches, similar to how > item 3.1 of the Applications of the Echo Option section describes > CoAP-CoAP proxies that forward to their client interface though they > reject on their server interface). > > > * If a server reboots during operation it may need to > > synchronize state or time before continuing the interaction. > > For example, with OSCORE it is possible to reuse a partly > > persistently stored security context by synchronizing the > > Partial IV (sequence number) using the Echo option, see > > Section 7.5 of [RFC8613]. > > > > In light of my toplevel comment, I'd suggest rewording this to clarify > > that the protocol specified in RFC 8613 includes a mechanism for > > resynchronizing the partial IV state, that uses the Echo option in a > > specific controlled protocol interaction. > > > > (A similar consideration would apply to the group communication example, > > though it might be a little harder to write clearly.) > > The "authority over synchronized property" concept intoduced in response > to the toplevel comment (GENERIC-SHORT-ECHO) covers most of this. Thus, > also the time synchronization given can be valid here -- provided the > client is a recognize authority for it. Which, in a group case, it will > likely not be; thus, removing the example from there. (Also upgrading > the "see" to an "as specified" to softly indicate that this is not done > easily). > > > 3. A server that sends large responses to unauthenticated peers > > SHOULD mitigate amplification attacks such as described in > > Section 11.3 of [RFC7252] (where an attacker would put a victim's > > address in the source address of a CoAP request). The > > RECOMMENDED way to do this is to ask a client to Echo its request > > to verify its source address. [...] > > > > (editorial) this usage of "ask a client to Echo its request" seems > > rather divorced from the actual mechanicis of the Echo option...in the > > rest of the document (bar one other instance noted below) we restrain > > ourselves to saying that the Echo option is what is echoed, divorced > > from the containing request/response. > > It kind of makes sense, but (with the current terminology) would really > need terminology introduction. This particular occurrence has been > cleared up in unrelated edits already; the later is changed. > > > This needs to be done only once > > per peer [...] > > > > How is the "peer" identified in this case? Is it tied to a single > > (security) association, or the identity (if any) associated with that > > security association, or IP address (and port?), or something else? > > How long can/should the reachability information be cached for? > > Different strategies are valid here, and to be honest it may need some > additional deployment experience to give hard and fast criteria here. > > The distinction only starts to matter when an attacker finds a potential > amplification helper that already is in legitimate contact with its > victim. Picking "the endpoint" as peer definition (which is host and > port on both sides, plus the security association), as that curbs the > attack at least in the case in which the amplification-helper-to-be does > the OSCORE itself, and will then be suspicious of unprotected requests > for large responses from the attacker. > > There is some wiggle room in the interpretation of endpoint, especially > in layered setups (I like to think of a CoAP library as a proxy that > translates CoAP-over-API to CoAP-over-transport), and some room for > optimization (if the unsecured endpoint is good, no need to check for > reachability of the secured equivalent), but that at last *will* need > the deployment experience to be gathered over the next months and years > to see what is practical. I see this is quite a bit more complicated than I thought at first! Thanks for explaining the situation for me. > > Section 3.1 > > > > In order for a security > > protocol to support CoAP operations over unreliable transports, it > > must allow out-of-order delivery of messages using e.g. a sliding > > replay window such as described in Section 4.1.2.6 of DTLS > > ([RFC6347]). > > > > My understanding is that the requirement is only to allow out-of-order > > delivery of messages (not necessarily including replay detection), so > > the clause about the sliding window is not needed. here. > > Indeed. Realizing that DTLS can be used with replay protection off made > this half-sentence go away and caused some follow-up adaptions. > > > Section 3.2 > > > > In essence, it is an implementation of the "proxy-safe elective > > option" used just to "vary the cache key" as suggested in [RFC7959] > > Section 2.4. > > > > The referenced section of RFC 7959 covers Block2 operation, but my > > understanding is that the Block1 operation (covered in Section 2.5 of > > that same document) would be a more applicable reference. > > Section 2.4 is where the cited suggestion is made. This is the relevant > reference because there it is made clear that "the resource" to which > block operations are keyed is the cache key and not the URI. > > Section 2.5 explains the general Block1 phase behavior. Its last > paragraph is on concurrent transfers, but does not add anything to the > understanding of Request-Tag, whereas the 2.4 statements contain the > justification for why this can work that way (which applies to Block1 > and Block2 alike). (Okay, I see now that you are correct.) > > Section 3.3 > > > > Also, a client that lost > > interest in an old operation but wants to start over can overwrite > > the server's old state with a new initial (num=0) Block1 request and > > the same Request-Tag under some circumstances. Likewise, that > > results in the new message not being part of the old operation. > > > > Where are those "some circumstances" enumerated? > > This could precisely this could say "if the client can recycle the > request tag" -- but that has not been introduced at this point, and more > importantly the paragraph is about server behavior (examplifying how > "equal request tags" doesn't necessarily mean "same operation"). > > > * The client MUST NOT regard a block-wise request operation as > > concluded unless all of the messages the client previously sent in > > the operation have been confirmed by the message integrity > > protection mechanism, [...] > > > > nit: confirmed as what? Delivered? > > With the DTLS replay window realization, this would have become > unwieldly, and thus was simplified to the "when the client knows the > server won't accept it" that was already there. What that means in > practice is spelled out for OSCORE and DTLS in the following paragraphs > anyway. > > > In DTLS, this can only be confirmed if the request message was not > > retransmitted, and was responded to. > > > > Similarly, this would be "When security services are provided by DTLS" > > -- DTLS does include a native retransmission layer, but only for DTLS > > handshake messages, so this phrasing is needlessly ambiguous as to > > whether it is the CoAP request that got retransmitted. > > The point about retransmission is on CoAP here; made more explicit in > the rephrasing. > > The line was also changed to include the necessity for the server to > perform replay protection (which until the RD review I was unaware was > even optional). The over-all statement (which leaves the door open for > request tag recycling in DTLS) is left open, even though this new > constraint is making it *even* harder to be sure -- but the situations > in which that could previously done were already pretty niche, and in a > setup where the application can alreay know what got ACKed and what got > retransmitted, it is not out of the question that it knows the server > well enough to assert that it has replay protection active as well. > > > Authors of other documents (e.g. applications of [RFC8613]) are > > invited to mandate this behavior for clients that execute block-wise > > interactions over secured transports. In this way, the server can > > rely on a conforming client to set the Request-Tag option when > > required, and thereby conclude on the integrity of the assembled > > body. > > > > Could you clarify which client behavior would be mandated? The overall > > "body integrity based on payload integrity" procedures, or the specific > > "typically, in OSCORE" behavior? > > The behavior is the whole subsection's. (Many such specifications WOULD > PROBABLY also mandate a particular security mechanism, narrowing it down > to one of the cases, but the intention is to use the abstract behavior) > > Now clarified. > > > Section 3.6 > > > > The Request-Tag option is repeatable because this easily allows > > several cascaded stateless proxies to each put in an origin address. > > They can perform the steps of Section 3.5.3 without the need to > > create an option value that is the concatenation of the received > > option and their own value, and can simply add a new Request-Tag > > option unconditionally. > > > > Thanks for including this! However, it wasn't clear to me from reading > > https://tools.ietf.org/html/rfc7252#section-5.4.5 and this document > > whether the order of repeated Request-Tag options was significant. > > Some clarification might be helpful. > > The order of CoAP options is significant in the information model (and > if any doubt on this arises, core-corr-clar would be the place to to > dispell them). > > As Request-Tag has no own semantics, intermediaries can put theirs in > the front or back (or not use repeatability at all), but as implementers > can pick any, I don't see much to point out. Makes sense. > > Section 3.7 > > > > That approach would have been difficult to roll out reliably on DTLS > > where many implementations do not expose sequence numbers, and would > > still not prevent attacks like in [I-D.mattsson-core-coap-actuators] > > Section 2.5.2. > > > > (I agree that DTLS implementations largely don't expose sequence numbers > > and that is unlikely to change. But) I am not sure I fully understand > > the scenario referenced in draft-mattsson-core-coap-actuators §2.5.2. > > Perhaps it is not what was intended to be conveyed, but it seems like in > > a setup that is tracking both sequence and fragment numbers, it would be > > pretty easy to enforce that a fragment-0 block will only start a new > > request if the sequence number is larger than the sequence number of the > > current/previous blockwise request. IIUC that would reject the > > "withheld first block" as being too old. > > Enforcing that means that not only state about ongoing block-wise > operations is kept (which is about as much state as can be tolerated), > but that in addition also state about block-wise transfers that are not > pursued any more would need to be kept -- and that's too much to ask (as > it'd be per-client times per-resource information). There might be a variant that only needs per-client state, but we're pretty far off in the weeds here so I don't think we should spend more time thinking about it. > > Section 3.8 > > > > and MUST NOT use the same ETag value for different > > representations of a resource. > > > > (side note) I was a little surprised that this was not already a > > requirement, but I couldn't find an equivalent statement in a quick > > review of RFC 7252. (It's definitely correct that this is required > > behavior to get the protection in question.) > > Neither was any found in RFC 7959. > > > Section 4.1 > > > > In HTTPS, this type of binding is always assured by the ordered and > > reliable delivery as well as mandating that the server sends > > responses in the same order that the requests were received. [...] > > > > I believe this description applies to HTTP/1.1 over TLS, but not to > > HTTP/2 or HTTP/3 (both of which provide other mechanisms for reliably > > binding requests and responses in the form of stream IDs). > > Changed to refer to HTTP/1.1. Covering what /2 and /3 do might be > interesting comparison material, but given we're just tweaking the Token > mechanism here (and not introducing it anew, which would warrant the > detailed related-work comparison over the setting-the-mental-frame > reference to HTTP/1.1), that should suffice. > > > Section 4.2 > > > > One easy way to accomplish this is to implement the Token (or part of > > the Token) as a sequence number starting at zero for each new or > > rekeyed secure connection. This approach SHOULD be followed. > > > > I note that sequential assignment often has some additional undesirable > > properties, as discussed in draft-gont-numeric-ids-sec-considerations. > > Would a different method (e.g., one listed in > > draft-irtf-pearg-numeric-ids-generation) provide the needed properties > > with fewer side effects? > > In particular, sequential increment is at odds with the "nontrivial, > > randomized token" recommended for clients not using TLS (that is > > intended to guard against spoofing of responses). > > ("use of a sequence number" and "a sequence number approach" also appear > > in §5.1, if this is changed.) > > These recommendations are for secured transports without > request-response binding, i.e. DTLS. As the identifiers are protected by > the DTLS integrity protection, they are outside the scope of the threat > model described in numeric-ids-generation. (On the other hand, the > nontrivial, randomized token recommended for non-TLS cases, and this > document makes no updates for them.) > > The concepts of numeric-ids did result in additions to the privacy > considerations for outer Echo and Request-Tag values. > > > For the purpose of generating timestamps for Echo a server MAY set a > > timer at reboot and use the time since reboot, in a unit such that > > different requests arrive at different times. [...] > > > > Something about this sentence confuses me, possibly around "in a unit". > > "choosing the granularity such that". (Which may not be necessary for all > applications, but is convenient when using both time and events). > > > Section 5.1 > > > > Tokens that cannot be reused need to be handled appropriately. This > > could be solved by increasing the Token as soon as the currently used > > Token cannot be reused, or by keeping a list of all blacklisted > > Tokens. > > > > editorial: perhaps "unsafe to reuse" is more clear than "blacklisted"? > > Changed simillarly ("keeling a list of all Tokens unsuitable for reuse"). > > > Section 6 > > > > This seems to be the first (and only) place where we use the term > > "preemptive Echo values"; it might be worth a bit more exposition that > > these are ones piggybacked on non-4.01 responses (assuming that's > > correct, of course). > > It is, and now properly introduced. > > > Section 8.1 > > > > I note that DTLS 1.3 is in IETF Last Call. I did not notice anything in > > this document that's specific to a DTLS version, which suggests that it > > woudl be safe to change the reference according to relative publication > > order of these documents. It would be good for the authors to confirm > > that at their leisure, so as to not be rushed into a decision if/when > > the RFC Editor asks during their processing. > > DTLS 1.3. works just as fine, a note to the editor has been added. > > > Section 8.2 > > > > I note that draft-mattsson-core-coap-actuators is referenced from > > several locations (for useful additional discussion, to be clear), but > > it is only an individual draft that expired almost two years ago. Is > > there any likelihood that it will ever progress to an RFC? > > Work on the document has been taken up again as > draft-mattsson-core-coap-attacks-00, the references are updated. > > > One might argue that "SHOULD use a 425 Too Early response" is enough to > > promote RFC 8470 to being a normative reference (see > > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/). > > Given there is no way to indicate modularity here, yes, that's what the > rules say; changed. > > > Section A > > > > 2. Integrity Protected Timestamp. The Echo option value is an > > integrity protected timestamp. The timestamp can have different > > resolution and range. A 32-bit timestamp can e.g. give a resolution > > of 1 second with a range of 136 years. The (pseudo-)random secret > > key is generated by the server and not shared with any other party. > > The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit > > timestamp and a 64-bit MAC, the size of the Echo option value is 12 > > bytes and the Server state is small and constant. The security > > against an attacker guessing echo values is given by the MAC length. > > If the server loses time continuity, e.g. due to reboot, the old key > > MUST be deleted and replaced by a new random secret key. Note that > > the privacy considerations in Section 6 may apply to the timestamp. > > Therefore, it might be important to encrypt it. Depending on the > > choice of encryption algorithms, this may require a nonce to be > > included in the Echo option value. > > > > I note that a MAC construction allows additional information to be > > covered under the MAC that is not sent alongside it, e.g., identity > > information about the client to which the Echo option value is being > > associated. Are there common situations in which including such > > additional contextual information under the MAC would be valuable (to > > prevent an echo option value received on one connection from being > > usable on a different one)? > > There is one -- demonstrating network reachability. It's not a common > case (often the large responses are from GETs that don't need freshness > anyway), but educational in the sense that it helps fill the continuum > between MAC-the-address (RECOMMENDED for reachability) and > time-and-MAC-of-time (RECOMMENDED for freshness) to guide the reader > towards understanding the whole and not just coding down the recipes. > Added. > > > 3. Persistent Counter. This is an event-based freshness method > > usable for state synchronization (for example after volatile state > > has been lost), and cannot be used for client aliveness. It requires > > that the client can be trusted to not spuriously produce Echo values. > > > > I have severe qualms about specifying a protocol mechcanism that relies > > on trusting a client to this extent. It seems to expose a lot of latent > > risk; even if we think there should be mechanisms in place to protect > > against that risk, they might fail, or the mechanism might get used > > outside its intended context, etc.; if there are other mechanisms > > available for similar cost that provide the needed properties it seems > > more robust to suggest their use in place of the persistent counter. > > The additions of GENERIC-SHORT-ECHO, especially on "authority over > synchronized property", should help in describing this and limiting any > ill-effects. It does help, and thanks again for writing it up so nicely. Thanks again for all the changes and responses here -- even though I didn't reply to all of them, I did read them. -Ben > If the client is *not* trusted, we're fast into the order of magnitude > of 64-bit MACs; anything less might just give a false sense of security. > Where these are transported regularly (as in [RD]), that quickly adds up > in total bytes on the air. Thes cases *do* need good analysis, and it is > hoped that with the new text the tools for this are there, but when the > result is that trusting the client on this freshness is fine, then a > counter should be too and has the least cost. > > Best regards > Christian > > [1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4 > [RD]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-request-freshness > > -- > This may seem a bit weird, but that's okay, because it is weird. > -- perldata(1) about perl variables From nobody Mon Aug 30 10:59:06 2021 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 A8A643A1C08; Mon, 30 Aug 2021 10:59:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <163034634166.17431.14820107713355769156@ietfa.amsl.com> Date: Mon, 30 Aug 2021 10:59:01 -0700 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-13: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 17:59:02 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-echo-request-tag-13: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I really like the changes made in the -13 overall; thank you for adding in all the additional discussion. I only have editorial/nit-level comments remaining. Section 2.5.2 The information extracted by the server from the request Echo value has different sources of truth depending on the application. I think that the "sources of truth" phrase might be a source of confusion for some readers. I'd consider something more like: % The request Echo value conveys freshness information to the server, % and the freshness is applied to some data or information related % to the request. which then transitions decently into "Understanding who or what is the authoritative source of that information helps the server implementer decide ..." If all that the server extracts is information which the client is authorized to provide arbitrarily, (which is another way of saying that the server has to trust the client on whatever Echo is used for), then the server can issue Echo values that do not need to be (nit) I'd suggest "whatever Echo is being used for" (add "being") In most other cases, there are properties extracted of which the server is the authority ("The request must not be older than five minutes" is counted on the server's clock, not the client's) or which [If my above suggestion is used, that removes the word "extracted", this use of "extracted" should probably be reworded as well.] Section 3.5.1 When security services are provided by DTLS, this can only be confirmed if there was no CoAP retransmission of the request, the request was responded to, and the server performs replay protection. (nit) I think the server would either "perform replay detection" or "[provide/use] replay protection" -- performing protection is not a common phrasing. way, the server can rely on a conforming client to set the Request- Tag option when required, and thereby have confidence the integrity of the assembled body. (nit) "have confidence in" Appendix A This method is suitable both for time and for event base freshness (e.g. by clearing the cache when an event occurs), and independent of the client authority. (nit) "for time- and for event-based freshness" (and again a couple paragraphs later) From nobody Mon Aug 30 11:26:40 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838713A1CFC for ; Mon, 30 Aug 2021 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLw5mi8_lhsa for ; Mon, 30 Aug 2021 11:26:29 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2075.outbound.protection.outlook.com [40.107.21.75]) (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 C10B83A1CFA for ; Mon, 30 Aug 2021 11:26:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eFAgrDBJuoMRrMOsQnKEKTbkG76p+3+HJ2mJpZ7fXgoK/pJl4kUuehCQgaTisAxJRA4N//d79RNtOFnWPqWZvo/f5d8oz6eNbZKJF7gzzwigv/Ns0uwZBsdyFGyoEzbAM1QQ6hsmSHJxZcLy4QpI8I1b+9gkyVGexejMyEWxka3SCqEUW3TqWxGlDXd1EMAjLWxffCyynPutUEUL1wCoqV0uDicEA92qkKScOyiQwUi5RFC1wjkFX5r3Kfy8l3OdOSg/MBLH4VDMNJaAsQxYKv7sYuZaFnXwvfvfMKRHgKVHhzWzYNNIkHG7iObz16orXg09FVLq+d7Ymo2Vxer05g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+dGObXqK4AtTTpgPw7mViYIvOjPTZynMLUuEMqjWMYQ=; b=EcDXWhYOEAQQTzH+FmU9GNcvBt3TFDMwdJ7eFdUhAHJRvQZ5jKFwEwjs2sb16cDH2Inp9+oO15+KdMXrAU228KIh+KehkdIsKfva+jM5LWHk4APeu6H/B1u/Ug8C0/Ebs7a9pjwsVGlpcEGcxQpyu3R+JvbWT0pzmnMaSr4mzK9khxUBSWPE4sEQpF5Denbffeq+aclujEVpAGF0v+wWq+/cimh7SOJUhwkbmYgX4FYjI7a9oYm4P1Cf44FMRxTRw5QqTSjZVs2+ifvVr0bvY2tFR2/SH3+wuwhtdt7yVt+PejwEhMwnkTSZY2cRRFkyfDEqL99ingBxozLhGEmBpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+dGObXqK4AtTTpgPw7mViYIvOjPTZynMLUuEMqjWMYQ=; b=PHlHoWZWJZc7Gv6/unlSBrI8wrCk6+HRhTbSezUn3VEXRQIm1eNsbV04Nh2p6FTjzzXJcUhxSEXllWHFGj70jPt23HOX/655j73dq/VL9skNIUb61mIZG4HgwjaBQpkz2yxRO6jAdglnOMq8OeK6ei+5t4T4h6GbCTSgnbgQOOk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1514.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a9::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18; Mon, 30 Aug 2021 18:26:22 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a9af:c9af:e0cc:4e53]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a9af:c9af:e0cc:4e53%3]) with mapi id 15.20.4457.024; Mon, 30 Aug 2021 18:26:22 +0000 References: <41AC2BA4-118A-4E56-A218-488E9ACEA85D@vigilsec.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <41AC2BA4-118A-4E56-A218-488E9ACEA85D@vigilsec.com> Message-ID: Date: Mon, 30 Aug 2021 20:26:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <41AC2BA4-118A-4E56-A218-488E9ACEA85D@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GQgw2jWLeiSwL4jXYrlhWPiFqOJw9IgCw" X-ClientProxiedBy: HE1PR08CA0059.eurprd08.prod.outlook.com (2603:10a6:7:2a::30) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.4] (185.219.140.117) by HE1PR08CA0059.eurprd08.prod.outlook.com (2603:10a6:7:2a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18 via Frontend Transport; Mon, 30 Aug 2021 18:26:21 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 473b1450-650a-485b-03c5-08d96be3aae8 X-MS-TrafficTypeDiagnostic: DB9P189MB1514: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3VumVnZmAx/l6V0B/ZPmqEV4BKJcVspgW6YPJtYtw08zIBq+M0b+Qojl515RS1hLev/J9tbUMUujJgLulYLke5LEq6vFj+clJg/oFJNL9yQ/WMi+4DMoPTCVTNH46c+9cGTrtoTOtZZIf/e6aD3Uh7qh+KSrhLi0NmNoHpiM+E9S0MdaUf1kMYjDekBE2WJ+ogiSfJcCY6IlD+g4wKcfGToh3qPmjAsGH8104XK3gn0TqSg0jzC8Awkw5OVg7EO/xgMuyNMp2D1iI14SGKZC9jGkgovIrqM18PLOn4pv/bvDM8CeXnqpZVOL1dzsuaFVgcVgvIsCJD1NWsIxJlnn70bG4I55qYt5se9iWRLmILuNXz0qBUpzx4iJXF8+PyEBNmKISgqxGyTd5QGloVXZTiJr8YWE7UXwL74HX51C1QWGyBYNP1wSZXPlhn8jiHd/JdaN4hpxjeORtuIjiN8NLPF7XAd+SzKYSfOnAcIjZnYnHkPfmZW9Ccg/xfA7SY3EH3V2mCsruVmUzq34ApQgpb6yGW+hB9RVvoebV0hwFKNUKW6ccH1HG91dTa+UdfE7f1TvdeDGTaDwIMpc6zsm4PIZ0ffGbBfvqdJEvnb4lmHdazZApSfALT8YkuwfpJuQTXi1r733KV2XFdrVb4sGvM/sDff8uBt7eBfbklpgBdmo4Uaf2KTcXHyg/A9Patte5e3N7nQwJblgzKaFPlWgE9YSLYbbw0UQJuS6ETlsRCMsb1wkPqZBmpDEo3SzemKJdBkSxDguUdoQDc5xGymaZEFXbC918GiYGtgaBpdef/PCW70VGm4jG9lkePnpiAzV X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(366004)(346002)(396003)(136003)(2906002)(66946007)(66556008)(36756003)(316002)(66476007)(66616009)(6916009)(16576012)(2616005)(186003)(66574015)(956004)(21480400003)(166002)(235185007)(478600001)(31686004)(86362001)(45080400002)(44832011)(83380400001)(30864003)(5660300002)(26005)(8936002)(8676002)(6486002)(31696002)(966005)(33964004)(38100700002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MCs2TXFhYlVkYWJyR3B6SjE4cFFLT2E3Zm9pMlZoZk1sby9QKzlOTHJqVmZG?= =?utf-8?B?aEJiZ3lLdzloQ1VMaEJmYjRLd2RicS90NVhEck5uNTRWK0twVEp0eSs0T1JM?= =?utf-8?B?STNRaHR0TW8vSC9lZTlTa2hGOUJzWno1THNDaDdMN2ZNYmVhdGNMS2R1WS9s?= =?utf-8?B?Sm1KSE82ZXhLT1QzVlh4bmxFZjZTLzBQUkxaOXVRNzBjSW4zNkNDbHFiZTk4?= =?utf-8?B?cFVVWVNvVVBReDFHOTh4NGk2QWIvMCtyRW04UjlVT09JRGt1QzB5eHhLdzVE?= =?utf-8?B?VlpuTnpzU2d1ZStKYmNQQVhXRFMrTWZ1TXBBckk4enpyd3RYVzUrZWFXMW5y?= =?utf-8?B?c2FmZHdJaWQwQTg0YnpHb095NDNPZUV3ZHhnMzFoUXErY3plenZ3aVJjdjlX?= =?utf-8?B?eGlNcmZON2VlRmZJMDJyUEdNYkJuaVlSai9PWERUcWNBVXd4Zm5LTENJb2Jq?= =?utf-8?B?Q0pCdC9oZmQ1dkZ5Z25odFJyRnNvNmlveHVaSnpkdE51Yk1sZ2gybWl2SGtW?= =?utf-8?B?UUtsd2krKzA0VFBRbFFUZk9WK0FCOWdsMkI4cjB4SktBWkw5QlB0UDhyMk1K?= =?utf-8?B?bkFvcEppMytpMWVhUnZCSWhsVDRsRW5yODJMazY3MkJBWFBzUER5WmlOU2FK?= =?utf-8?B?cGFGWG5peEk4TWtBZlFvc09TbzVXS2pyS0hCZjZDdW4zVkpZaG42SmFvZzc3?= =?utf-8?B?OEtxeWlWY3lxdEZmd3lKKzZ5YUw3bzVmbVpVSHpoVzJZN1FHd0pSWlFFK09K?= =?utf-8?B?NlFUczhwdjFwWnlCcGExbjVwb2RWTFUzbjZrRXBWMzR6SW5Mc1IrNm5WcUFz?= =?utf-8?B?Q2J3c2dqTGlDQW5yTzk4SzlHOVdQK3dkTlE3blQ4ZlNSbENUYlovUlAzK3V5?= =?utf-8?B?V1F6VmVtVGI4L2E2VHYwTWZpL1JwdzhHcEI0MnZXRkhFN3FBVzg2MGkvQWg0?= =?utf-8?B?dUhpUmNYNzlGWHZnM3NiNjdSNkt4UWpNa2paOGh2VVUxMHpsQ3QvR0t1bXU0?= =?utf-8?B?Q2ZFTUFPYU93eVVUdzYwdE02ZjNrblBqem1Pd0d4TTBJWU1DY1FUYXdCWlZs?= =?utf-8?B?N282alNsaVU4TmxMVEZKam1RSUdWWUtrYU0zaFgxV3d0Y1krbHFQMWh3ano5?= =?utf-8?B?dGtEUTdvUWR5eXI4SVk5cHo4WnhKRHVHRlp5QmsrY3EzdWpad054ZVZtdnRr?= =?utf-8?B?WmFIMzZzN0hRZU5OVHJyRmFWZ21lK3YyYkxtbkFxN3hSRHgzOEhYSjVhY25z?= =?utf-8?B?WDJpQWxVTEJsd0x3Y0pqcFAvQ05MUXl2bUQ2MDJQZk9QKzlLK3hUU0VId1U4?= =?utf-8?B?ZEVrUnBaYmFDbkRwSzM3enlwU3dlZFd3L1Y4YlRZTEhoR09GMzQ0ZTVKa1Z3?= =?utf-8?B?K3NVNkRobFBVREVta1VrcWEzbmNnMDZLdldRQng5UFZDTHhxd1NWSHNRODdt?= =?utf-8?B?aHZpTHZWeU4wZStlc0xHb0JHbFRTYlpRenJQR2ttTWFqelpUVkJ1TnhSb24y?= =?utf-8?B?dUFYcFJGbEFSTGxMR0xTeU9DVFlxSXB6cXVLL1BmeUswaDBnZUpwTEFGQWo4?= =?utf-8?B?dW9tNkF3ZERZRHUrU3lOdGw0UVM5Uk81eXk1LzNMbnpuVU9RbG5OZDJkUEdi?= =?utf-8?B?Z0htQm9jVGxHaGVyaHBhVVY4WVg5ajdPQ2NOVzdhUEdmbWtXRzNkcng4Mm9z?= =?utf-8?B?SnIwMURIVFRwV3FmckFkWm9neVRBNWpxTTBKNXlXbms4RGtHRTY3MktMT0NW?= =?utf-8?Q?tjUUCoFLRszUe82XvZZ6MqfqnnLaXbXMVbZUKkX?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 473b1450-650a-485b-03c5-08d96be3aae8 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Aug 2021 18:26:22.1434 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1etvtAIEIayh2QFWPhfOjsgeexh5nOL4JxMyT4vGmrqc4aYHz+D8Okt1ds2a0GCqsscbBQU18mbDcKV8ePtnzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1514 Archived-At: Subject: [core] NomCom 2021-2022 Call for Nominations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 Aug 2021 18:26:37 -0000 --GQgw2jWLeiSwL4jXYrlhWPiFqOJw9IgCw Content-Type: multipart/mixed; boundary="ndofILDfJ8RiFBQzZeVysKFe9bWwYMVJs"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: NomCom 2021-2022 Call for Nominations References: <41AC2BA4-118A-4E56-A218-488E9ACEA85D@vigilsec.com> In-Reply-To: <41AC2BA4-118A-4E56-A218-488E9ACEA85D@vigilsec.com> --ndofILDfJ8RiFBQzZeVysKFe9bWwYMVJs Content-Type: multipart/mixed; boundary="------------2C9ED7628322DAE74CFA9E97" Content-Language: en-US This is a multi-part message in MIME format. --------------2C9ED7628322DAE74CFA9E97 Content-Type: multipart/alternative; boundary="------------54D73ECFB952AAA9B7BB0D88" --------------54D73ECFB952AAA9B7BB0D88 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, Please, see below the recent NomCom call for nominations. Best, /Marco > *From: *NomCom Chair 2021 > > *Subject: **NomCom 2021-2022 Call for Nominations* > *Date: *August 30, 2021 at 10:03:54 AM EDT > *To: *"IETF Announcement List" > > *Cc: *ietf@ietf.org > *Reply-To: *ietf@ietf.org > > Finally! The moment we've all been waiting for: > > =C2=A0=C2=A0C A L L =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0F O R =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0N O M I N A T I O N S =C2=A0! ! ! > > The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations > from now until Monday, October 11, 2021. > > The open positions and more information are found at the NomCom web sit= e: > > https://datatracker.ietf.org/nomcom/2021/=20 > =20 > > > They are also included below for convenience. > > Nominations may be made by selecting the Nominate link at the top of th= e > NomCom 2021 home page, or by visiting the following URL: > > https://datatracker.ietf.org/nomcom/2021/nominate/=20 > > > Self-nomination is welcome! > > Note: =C2=A0Nominations made using the web tool require an ietf.org=20 > =20 > datatracker > account. You can create a datatracker ietf.org=20 > =20 > account if you don't have one > already by visiting the following URL: > > https://datatracker.ietf.org/accounts/create/=20 > > > If you are unable to use the web form, nominations may instead be made = > by email > to nomcom-2021 at ietf dot org. If using email, please include the=20 > word "Nominate" > in the Subject and indicate in the email who is being nominated, their = > email > address (to confirm acceptance of the nomination), and the position=20 > for which you > are making the nomination. If you are nominating someone other than=20 > yourself, > please tell us if we may tell the nominee that you were the one who=20 > made the > nomination. If you wish to nominate someone via email for more than one= > position, please use separate emails to do so. > > Willing nominees will be asked to fill out a questionnaire specific to = > the position > for which they are nominated. The finalized questionnaires will be=20 > available no > later than Monday, September 6, 2021 (preliminary versions are already = > posted) > and have a submission deadline of Monday, October 18, 2021. > > NomCom 2021-22 will follow the policy for "Open Disclosure of Willing > Nominees" described in BCP 10/RFC 8713: "The list of > nominees willing to be considered for positions under review in the=20 > current > NomCom cycle is not confidential". Willing nominees for each position=20 > will be > listed in a publicly accessible way, e.g., anyone with a datatracker=20 > account may > access the lists. Additionally, the nomination form asks if we may=20 > share your own > name with the nominee. In all other ways, the confidentiality=20 > requirements of BCP > 10 remain in effect. All feedback and all NomCom deliberations will=20 > remain > confidential and will not be disclosed. > > There is a field on the form you can mark in order to allow the NomCom = > to tell > the nominee that you were the one who made the nomination. This=20 > defaults to > =E2=80=9Cno=E2=80=9D - so if you don't mark the field we won=E2=80=99t = tell. > > In order to ensure time to collect sufficient community feedback about = > each of > the willing nominees, nominations must be received by the NomCom on or = > before > Monday, October 11, 2021. > > Please submit your nominations as early as possible for the sake of you= r > nominees. Note that nominations should not wait for nominee management > permission, as it is easier to decline the nomination than put one in=20 > late. > > The NomCom appoints individuals to fill open slots on the IAB, IESG,=20 > the IETF > Trust and the LLC Board: > > ART AD: 1 position > INT AD: 1 position > OPS AD: 1 position > RTG AD: 1 position > SEC AD: 1 position > TSV AD: 1 position > IETF Trust: 1 position > IETF LLC: 1 position > IAB: 6 positions > > The list of people and posts whose terms end with the > March 2022 IETF meeting, and thus the positions for which this NomCom i= s > responsible, is: > > [An asterisk (*) next to a person's name indicates they do not intend=20 > to accept > renomination.] > > LLC Board (3-year term) > Jason Livingood > > IETF Trust (3-year term) > Kathleen Moriarty > > IAB (2-year term) > Ben Campbell * > Cullen Jennings > Mirja K=C3=BChlewind > Jared Mauch > Tommy Pauly > Jiankang Yao > > IESG (2-year term) > Murray Kucherawy, ART AD > Erik Kline, INT AD > Robert Wilton, OPS AD > Martin Vigoureux, RTG AD > Benjamin Kaduk, SEC AD * > Martin Duke, TSV AD > > Please be resourceful in identifying possible candidates for these=20 > positions, as > developing our talent is a very crucial requirement for the IETF, and=20 > also, please > consider accepting a nomination. You'll find extensive information=20 > about specific > positions, in individual tabs at: > > https://datatracker.ietf.org/nomcom/2021/requirements/ > > In addition to nominations, the NomCom seeks community input on the=20 > positions > themselves. We need and welcome the community's views and input on the = > jobs > within each organization. If you have ideas on the positions=E2=80=99=20 > responsibilities > (more, less, different), please let us know. > > Please send suggestions and feedback about this to nomcom-2021 at ietf = > dot org. > > Thank you for your help in identifying qualified nominees! > > Thanks, > > Gabriel Montenegro > IETF NomCom Chair 2021-22 > nomcom-chair-2021 at ietf dot org --------------54D73ECFB952AAA9B7BB0D88 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,

Please, see below the recent NomCom call for nominations.

Best,
/Marco

From: NomCom Chair 2021 <nomcom-chair-2021= @ietf.org>
Subject: = NomCom 2021-2022 Call for Nominations
Date: August 30, 202= 1 at 10:03:54 AM EDT
To: "IETF Announcement List" <ietf-announce@ietf.org&g= t;
Cc: ietf@ietf.org
Reply-To: ietf@ietf.org

Finally! The moment we've all been waitin= g for:

=C2=A0=C2=A0C A L L =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= F O R =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0N O M I N A T I O N S =C2=A0! != !

The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations
from now until Monday, October 11, 2021.

The open positions and more information are found at the NomCom web site:

https://datatrack= er.ietf.org/nomcom/2021/

They are also included below for convenience.

Nominations may be made by selecting the Nominate link at the top of the
NomCom 2021 home page, or by visiting the following URL:

https://datatrack= er.ietf.org/nomcom/2021/nominate/

Self-nomination is welcome!

Note: =C2=A0Nominations made using the web tool require= an ietf.org datatracker
account. You can create a datatracker ietf.org acco= unt if you don't have one
already by visiting the following URL:

https://datatrack= er.ietf.org/accounts/create/

If you are unable to use the web form, nominations may instead be made by email
to nomcom-2021 at ietf dot org. If using email, please include the word "Nominate"
in the Subject and indicate in the email who is being nominated, their email
address (to confirm acceptance of the nomination), and the position for which you
are making the nomination. If you are nominating someone other than yourself,
please tell us if we may tell the nominee that you were the one who made the
nomination. If you wish to nominate someone via email for more than one
position, please use separate emails to do so.

Willing nominees will be asked to fill out a questionnaire specific to the position
for which they are nominated. The finalized questionnaires will be available no
later than Monday, September 6, 2021 (preliminary versions are already posted)
and have a submission deadline of Monday, October 18, 2021.

NomCom 2021-22 will follow the policy for "Open Disclosure of Willing
Nominees" described in BCP 10/RFC 8713: "The list of nominees willing to be considered for positions under review in the current
NomCom cycle is not confidential". Willing nominees for each position will be
listed in a publicly accessible way, e.g., anyone with a datatracker account may
access the lists. Additionally, the nomination form asks if we may share your own
name with the nominee. In all other ways, the confidentiality requirements of BCP
10 remain in effect. All feedback and all NomCom deliberations will remain
confidential and will not be disclosed.

There is a field on the form you can mark in order to allow the NomCom to tell
the nominee that you were the one who made the nomination. This defaults to
=E2=80=9Cno=E2=80=9D - so if you don't mark the field w= e won=E2=80=99t tell.

In order to ensure time to collect sufficient community feedback about each of
the willing nominees, nominations must be received by the NomCom on or before
Monday, October 11, 2021.

Please submit your nominations as early as possible for the sake of your
nominees. Note that nominations should not wait for nominee management
permission, as it is easier to decline the nomination than put one in late.

The NomCom appoints individuals to fill open slots on the IAB, IESG, the IETF
Trust and the LLC Board:

ART AD: 1 position
INT AD: 1 position
OPS AD: 1 position
RTG AD: 1 position
SEC AD: 1 position
TSV AD: 1 position
IETF Trust: 1 position
IETF LLC: 1 position
IAB: 6 positions

The list of people and posts whose terms end with the
March 2022 IETF meeting, and thus the positions for which this NomCom is
responsible, is:

[An asterisk (*) next to a person's name indicates they do not intend to accept
renomination.]

LLC Board (3-year term)
Jason Livingood

IETF Trust (3-year term)
Kathleen Moriarty

IAB (2-year term)
Ben Campbell *
Cullen Jennings
Mirja K=C3=BChlewind
Jared Mauch
Tommy Pauly
Jiankang Yao

IESG (2-year term)
Murray Kucherawy, ART AD
Erik Kline, INT AD
Robert Wilton, OPS AD
Martin Vigoureux, RTG AD
Benjamin Kaduk, SEC AD *
Martin Duke, TSV AD

Please be resourceful in identifying possible candidates for these positions, as
developing our talent is a very crucial requirement for the IETF, and also, please
consider accepting a nomination. You'll find extensive information about specific
positions, in individual tabs at:

https://datatracker.ietf.org/= nomcom/2021/requirements/

In addition to nominations, the NomCom seeks community input on the positions
themselves. We need and welcome the community's views and input on the jobs
within each organization. If you have ideas on the positions=E2=80=99 responsibilities
(more, less, different), please let us know.

Please send suggestions and feedback about this to nomcom-2021 at ietf dot org.

Thank you for your help in identifying qualified nominees!

Thanks,

Gabriel Montenegro
IETF NomCom Chair 2021-22
nomcom-chair-2021 at ietf dot org

--------------54D73ECFB952AAA9B7BB0D88-- --------------2C9ED7628322DAE74CFA9E97 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3VpdCBt YWlsaW5nIGxpc3QKU3VpdEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N1aXQKCg== --------------2C9ED7628322DAE74CFA9E97-- --ndofILDfJ8RiFBQzZeVysKFe9bWwYMVJs-- --GQgw2jWLeiSwL4jXYrlhWPiFqOJw9IgCw Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmEtIssFAwAAAAAACgkQ7iZktA5Y2kOs TAf/Qy3khvFOiLaKgJrQaPVce8njnrxrWCvE0Nt8LJCf8PTXdE5+XEmVG1J46RNQufly+l9YOrZe DwrB5YX8fbcg+hZcGiD7CRr4UM3TDd7aEO3ONPNQw+2qruJ9/5dTOjIooygt7vgOBk3r5TAobOWV fgGB8HE3VikUcUp6QIc9+Fh5NkyQ6E0469bpCY39aKlYquPbCmdo9RIUQZXk7wS75T52HOsnyr3/ sNA35fsfRqNo4nqxBJw6ZdrOAenRE29jQuXd8icUM1ZbAFuqEW0Xqxk2TvGuK1hrXekbPprgosC3 wOHlla9i1OVEw9eEf3JLc6yfM9KB61GlOAeynXZV0Q== =igWI -----END PGP SIGNATURE----- --GQgw2jWLeiSwL4jXYrlhWPiFqOJw9IgCw--