Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT)
Christian Amsüss <christian@amsuess.com> Sun, 07 March 2021 17:00 UTC
Return-Path: <christian@amsuess.com>
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, 07 Mar 2021 18:00:43 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Carsten Bormann <cabo@tzi.org>, Jaime Jiménez <jaime.jimenez@ericsson.com>, core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, The IESG <iesg@ietf.org>, core@ietf.org
Message-ID: <YEUGuw5ZuAcfOhCW@hephaistos.amsuess.com>
References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> <YDkUiTAo0YlEOMfw@hephaistos.amsuess.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: <https://mailarchive.ietf.org/arch/msg/core/m2SRK3FTVawyUVO3CZAoEJS5c9k>
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" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2021 17:00:52 -0000
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 > > > > 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. > > 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 :) > > 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=yes is an assertion on which the ultimate authority is with the entity defining the security policies. * An attribute like <...>;rt="...: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 "</res/fw>" 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 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [core] Benjamin Kaduk's No Objection on draft… Christian M. Amsüss
- Re: [core] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [core] Benjamin Kaduk's No Objection on draft… Carsten Bormann
- Re: [core] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [core] Benjamin Kaduk's No Objection on draft… Christian Amsüss
- Re: [core] Benjamin Kaduk's No Objection on draft… Carsten Bormann
- Re: [core] Benjamin Kaduk's No Objection on draft… Christian M. Amsüss