Re: [Add] My principles for discovery

Vittorio Bertola <vittorio.bertola@open-xchange.com> Fri, 27 March 2020 11:10 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8853F3A07C3 for <add@ietfa.amsl.com>; Fri, 27 Mar 2020 04:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 wJuV3HTbwBnV for <add@ietfa.amsl.com>; Fri, 27 Mar 2020 04:10:32 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 BDDBA3A07AB for <add@ietf.org>; Fri, 27 Mar 2020 04:10:31 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id CDD466A28C; Fri, 27 Mar 2020 12:10:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1585307427; bh=cU80gda7rhawq6qF+7vFMKFjkzq/TLlaGvdKIiw4E44=; h=Date:From:To:In-Reply-To:References:Subject:From; b=V0xaCN3v+PBEWAkB5aRlikRFkUqAXBsQkLUYBvANu7CL6zXEDO+3rsMlSO5/4Ncf5 tVFw0p/jsf9+SYn4MCoDyAsuFl9digZJ2z+0dtFAsYyNQ/wRp8OhMP0LDcDJ8tWwHU ms/doZ25Uu4pkqBSgpLLPtHvfRaYelhnErSVjvN6a6q50gAsOdCumGRkaiOzQc+Btw ePq2Ny8irIWpl+LufrnYM1rQk+GBvLdz1POgQUR4hRP37ShHVjyqxXzrBw7miIftQj DnURxohJorhUur+rzFSI9gMMweI+Vlo54rUzu0I9YTYfrPvLrfVjhnDu1BrjOWI4SC hDkyX09xfqQbA==
Received: from appsuite-dev-gw2.open-xchange.com (appsuite-dev-gw2.open-xchange.com [10.20.30.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id C02813C029C; Fri, 27 Mar 2020 12:10:27 +0100 (CET)
Date: Fri, 27 Mar 2020 12:10:27 +0100 (CET)
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Martin Thomson <mt@lowentropy.net>, add@ietf.org
Message-ID: <1900124394.3218.1585307427695@appsuite-dev-gw2.open-xchange.com>
In-Reply-To: <08c407f3-e0bc-46c2-9864-c7d4c347811b@www.fastmail.com>
References: <aec5404a-99eb-4aa7-9020-1e7b4f51b5ca@www.fastmail.com> <93585501.473.1585121577118@appsuite-dev-gw1.open-xchange.com> <08c407f3-e0bc-46c2-9864-c7d4c347811b@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.4-Rev0
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/imSSZ4Oc3-OEPWCB7VgEseGz2eo>
Subject: Re: [Add] My principles for discovery
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2020 11:10:35 -0000


> Il 27/03/2020 01:44 Martin Thomson <mt@lowentropy.net> ha scritto:
> 
> See, I think that this line of argumentation is firmly out of scope for this group.  I think that it is fine to express your opinions about what policies a client might consider as valid, and to factor those things you identify into how those opinions are formed, but this group is setup specifically not to contemplate that.  Finding ways to express how those opinions manifest within the scope of this group's charter is what we need to try to do.  Which is awkward, but thank you for doing that here:

I don't disagree, but the problem is that discovery mechanisms are a tool to implement deployment models, which shape their requirements. But deployment models have policy consequences, some intended and some not, which once understood lead to adding features and fixes to them, which in turn need to be supported by the discovery mechanism.

So the logical order to proceed would be to imagine a deployment model, to discuss collectively its policy implications, to come to reasonable bottom-up agreement (or final disagreement) on possible mitigations, and then to design and implement a discovery mechanism that supports all that. But we cannot do that because we don't have a venue for policy discussions, and even if we had it, the discussion would take much longer than agreeing on technical specs, and could fail altogether.

So, I agree that this is not the right venue for that, but I do think that some policy discussion now, even if hard, would save us much bigger arguments later, especially with people outside of this process.

Also, we might think that we may solve the issue by designing such an open, general and extensible discovery mechanism that it can support each and every conceivable deployment model. However, that could just be wishful thinking, and it might also set the group for a very long technical odyssey before getting anywhere.

> That's the careful balance this group has: we can't talk about policies because we know we don't all agree.  But we really need to understand whether there is some motivation for doing the work that is at least plausible.
> 
> This is likely a question for chairs, but if we want to avoid the policy discussions, maybe they would prefer to say that as long as there is sufficient interest then work might proceed rather than trying to avoid objections.  Or at least avoiding objections on policy grounds, because there are objections that are in scope and derive from things outside of the contested policy questions.

A "live and let live" principle could be good: different sub-groups could work on different discovery mechanisms that suit different deployment models, which will all be standardized provided that they are technically sound.

However, I do see a problem: can you really tell technical objections from policy objections? People that don't like other people's deployment models might start to claim that their objection is technical and thus in scope. The first example I can think of: there are people that would like to just add a new option to DHCP and advertise their DoH/DoT resolver there, as they think that the level of security provided today by DHCP is sufficient; others think that this would be too insecure, and object to that mechanism on those grounds. Is that a technical or a policy objection?

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy