Re: [core] Warren Kumari's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT)
Christian Amsüss <christian@amsuess.com> Tue, 03 November 2020 17:34 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 F18253A0DDD; Tue, 3 Nov 2020 09:34:10 -0800 (PST)
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 RXiQb4ATuaN3; Tue, 3 Nov 2020 09:34:09 -0800 (PST)
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 E96503A0D98; Tue, 3 Nov 2020 09:34:08 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 31AB340041; Tue, 3 Nov 2020 18:34:07 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5C5E0AB; Tue, 3 Nov 2020 18:34:06 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1B9C934; Tue, 3 Nov 2020 18:34:06 +0100 (CET)
Received: (nullmailer pid 55595 invoked by uid 1000); Tue, 03 Nov 2020 17:34:05 -0000
Date: Tue, 03 Nov 2020 18:34:05 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Warren Kumari <warren@kumari.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org
Message-ID: <20201103173405.GJ45088@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="dwWFXG4JqVa0wfCP"
Content-Disposition: inline
In-Reply-To: <159717402717.27772.14957520028083871786@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/sOf7yAocEuuNOTi0AlkX8dSZbTU>
Subject: Re: [core] Warren Kumari's No Objection on draft-ietf-core-resource-directory-25: (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: Tue, 03 Nov 2020 17:34:11 -0000
(This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at <https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>). As COMMENT: > Comments: > > 1: "These CTs are thought to act on behalf of endpoints too constrained, or > generally unable, to present that information themselves. " > > This reads very oddly - "thought to act on" sounds like we've seen some of > these in the wild, and only have a vague idea about how they work. Does > "These CTs act on behalf of endpoints too constrained, or generally unable, > to present that information themselves. " work? response: Yes that works. (Fixed in https://github.com/core-wg/resource-directory/pull/301). > 2: "From the system design point of view, the ambition is to design > horizontal solutions that can enable utilization of machines in different > applications depending on their current availability and capabilities as well > as application requirements, thus avoiding silo like solutions" - this is > very buzzwordy, and I have no idea what it is actually trying to say... response: What it was trying to say was that parts of the complete system should not be specific to an application. The sentence has been replaced with something that is less keyword oriented and more descriptive. (See https://github.com/core-wg/resource-directory/pull/302 for precise text). > 3: " A (re-)starting device may want to find one or more RDs for discovery > purposes." > > Either I don't understand what this sentence is trying to say, or "for > discovery purposes" should be dropped.... response: The intention here was to express that some host must be found before the further URI discovery steps can take place. Enhanced in https://github.com/core-wg/resource-directory/pull/301. > 4: "As some of the RD addresses obtained by the methods listed here are just > (more or less educated) guesses, endpoints MUST make use of any error > messages to very strictly rate-limit requests to candidate IP addresses that > don't work out. " What happens if device A discovers RD X, and device B > discovers RD Y? Surely there has to be some sort of deterministic method so > that one doesn't end up in a "split brain" type outcome? response: There are various approaches that can apply depending on the actual application: * In managed networks, care can be taken to not make multiple RDs discoverable. * In larger setups, multiple RDs may be available but set up for federation as it is being explored in draft-amsuess-core-rd-replication * RDs that are deployed without overarching coordination can opt for the Opportunistic Resource Directory approach that is being explored in draft-amsuess-core-resource-directory-extensions, where one RD yields to the other. The error handling steps in RD make that transition smooth. But long story short, this draft does not attempt to solve them. > Nits: > > 1: " The input to an RD is composed of links and the output is composed of > links constructed from the information stored in the RD." While true, this > sentence doesn't actually communicate anything useful to the reader -- I'd > suggest removing it from the Abstract (note that this is just a nit). response: There has been repeated confusion about what an RD stores, with people understanding it to store resources. This sentence serves to visibly emphasise that only links go in and out. > 2: "The RD is primarily a tool to make discovery operations more efficient > than querying /.well-known/core on all connected devices, or across > boundaries that would be limiting those operations." > > s/would be limiting those/that would limit those/ response: Fixed in https://github.com/core-wg/resource-directory/pull/253.
- [core] Warren Kumari's No Objection on draft-ietf… Warren Kumari via Datatracker
- Re: [core] Warren Kumari's No Objection on draft-… Christian Amsüss
- Re: [core] Warren Kumari's No Objection on draft-… Warren Kumari