From nobody Sun Mar 7 09:00: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 781AA3A1949; Sun, 7 Mar 2021 09:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3RCiCgC5UH0T; Sun, 7 Mar 2021 09:00:48 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AA13A1910; Sun, 7 Mar 2021 09:00:48 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8B48740897; Sun, 7 Mar 2021 18:00:45 +0100 (CET) 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 0441ED3; Sun, 7 Mar 2021 18:00:44 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:73a1:128f:55bf:b6cf]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 909A210A; Sun, 7 Mar 2021 18:00:43 +0100 (CET) Received: (nullmailer pid 3219855 invoked by uid 1000); Sun, 07 Mar 2021 17:00:43 -0000 Date: Sun, 7 Mar 2021 18:00:43 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Benjamin Kaduk Cc: Carsten Bormann , Jaime =?iso-8859-1?Q?Jim=E9nez?= , core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, The IESG , core@ietf.org Message-ID: References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> <20210227205638.GJ21@kduck.mit.edu> <16D35A91-1919-44A7-97AB-16BF80CD85B9@tzi.org> <20210227213759.GN21@kduck.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TnqGgIUpo1AhH34/" Content-Disposition: inline In-Reply-To: <20210227213759.GN21@kduck.mit.edu> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (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: Sun, 07 Mar 2021 17:00:52 -0000 --TnqGgIUpo1AhH34/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ben, Carsten, On Sat, Feb 27, 2021 at 01:37:59PM -0800, Benjamin Kaduk wrote: > On Sat, Feb 27, 2021 at 10:01:35PM +0100, Carsten Bormann wrote: > > > use "authoritative" instead of > > > "authorized" in the couple places I indicated > >=20 > > Authoritative sounds like it is an intrinsic property of the source. > > Authorized means that the specific policies that apply to the consumer = authorize use of the source for the purpose at hand. > > So I think this substitution should not occur lightly. >=20 > When the data in question is "what resources are available at this host",= I > think authoritative is pretty intrinsically a property of the host itself= :) >=20 > Now, if the question was "what resources are supposed to be at this host > that I'm allowed to use?", your considerations become quite relevant. After several attempts to phrase the text to reflect that sentiment, I am now of the opinion that that getting this picture over in a fashion that is both comprehensible and correct takes more explanation than is helpful for understanding RD at large. Distinguishing between what a requires authorization and what is authoritative information implies making a call on what is factual information and what is an assertion on a resource, and these depend on the semantics of the individual attributes which can not be done universally: * A statement on a resoure like the attribute <...>;trustworthy=3Dyes is an assertion on which the ultimate authority is with the entity defining the security policies.=20 * An attribute like <...>;rt=3D"...:firmware" is factual in a sense (after all, what a malicious party hosts there is *some* firmware) but also the prime example of something that needs additional authorization to state. * A statement like the plain "" is factual and can thus authoritatively be claimed by the endpoint. Still, some applications (not those we define because we adhere to BCP190) may ascribe semantics to it that need more authorization than just relaying a factual statement. Pitting all those on the term "authorized" is admittedly pulling in aspects of authority, but plucking them apart would help neither the casual nor the careful reader. Hoping that this contributes to your satisfaction with the now-to-be-submitted -28 BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --TnqGgIUpo1AhH34/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmBFBrgACgkQOY0REtOk veE00Q/9Htezu4Ig10Kiz0pkLa0CKloCX9GD4w682Qp0h0q4h0jOX9BNn2apldy8 NO/HD9nSLrxRh955rLN3GSIGChjH0t39iZOwsXMW8ZmbmxF+F+tjoYgt1FaLx0VD xG94YdKWSSJ/3XDV8NhRqfRsqwiGZxT/3eki4klfDpNbiMhNuWTEJLxe1mlZBmHg yMpdQAJ/1KuUiE+HQjJzFC7ZDgFW0bG0pJ66TnNwUQEWNiPkRkAAlB6/THHGBfUS R/1opvCUTYhyX9I3zaqtNygKF8mGpUMOa4adbwzRuvMIsdAKcPAxgwgncg9A0Tnm PbFyUhUigc+7jgmNVj1Y2kqds06E7s+OIFS1u/pKKpI6EVT5ejZICnFFfWqzKuY7 GN1XP6SitB0jAPUd1U5Rk2QzR6/uFAPi6CyoccVRbBAHTyNKRBOzsrMC7X1KAh82 CXqx5ybjMN7Tjvr8MiQAgdAttwiFKkft6dvnAZNUdlarnPnVVArnDrIwaiqZowtS u84dixXLWJIA1MvTHz62FJK5aijEsNu02y0GXEPNofNWu5UNeVOBC88wXR37vSnK Tg8PRqXxyPp3tcGOThYaJZNQo4IKfCovAz1g0QpPApXRgt2C/lJSHrfrSuN/XhT6 4vQnSH6IH94bI25AlKHyTpWWcp4bNY/QDZTJIF3djNRIrlCVY0o= =vdlW -----END PGP SIGNATURE----- --TnqGgIUpo1AhH34/--