Re: [Add] Updated charter proposal for ADD

Vittorio Bertola <vittorio.bertola@open-xchange.com> Fri, 17 January 2020 09:13 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 705B8120803 for <add@ietfa.amsl.com>; Fri, 17 Jan 2020 01:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 bEHR8APG3T38 for <add@ietfa.amsl.com>; Fri, 17 Jan 2020 01:13:06 -0800 (PST)
Received: from mx4.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 1AFBB120273 for <add@ietf.org>; Fri, 17 Jan 2020 01:13:06 -0800 (PST)
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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id EDA106A266; Fri, 17 Jan 2020 10:13:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1579252384; bh=EPP9Uh+3GVXq8cJdEGZIdIvc5eWb167pqoG6YXiLmTs=; h=Date:From:To:In-Reply-To:References:Subject:From; b=YW8XJwEiMor8e6jGxVDf3zMGDIYRgXbEwlJKPLSHmOihz1AxKsKv/RlOVta/hmgtX ajX9njOcLDznSjAfJF0WJTLhgBcfyVJkJhI2f8lO60A/w4HjmiZKYq+68QYqSwsFAy tRdzysDIunYxZJ/1qZmmrW7dr1zO7nWSZ47KV2aIe6OTjRKHYpRKHklCELXMwEu8TF k0oPnvkFPRixGKSol/rX0m8TIHVs/Yda3/KqcXlVbSa4uRKl4mBKTZQwKIWwLomdMQ jmTUFWNYcaIxBFFuWBkXu7JMKAvthH5tuftB6VxcH6+DaaOONcIrTG9/0ObHq4Fw7E PguUVTgyoAdrA==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 E20D33C0301; Fri, 17 Jan 2020 10:13:03 +0100 (CET)
Date: Fri, 17 Jan 2020 10:13:03 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>
Message-ID: <223011059.41195.1579252383830@appsuite-gw1.open-xchange.com>
In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com>
References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.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.3-Rev3
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/fV_19eAiavJ-d8m3ucY7Q9vfkws>
Subject: Re: [Add] Updated charter proposal for ADD
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, 17 Jan 2020 09:13:07 -0000


> Il 14/01/2020 23:38 Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> ha scritto:
> 
>  
> Hi all,
> 
> I wanted to share an updated proposal for an ADD charter, based on the feedback and discussion on the list in the past several weeks.

I am fine with this charter after removal of the "security properties" paragraph. I'm saying removal rather than rewriting because the attempts to rewrite it seem to be diverging rather than converging; if we absolutely want to write something, I'd suggest that we limit ourselves to stating that opportunistic solutions are also in scope (and that their security properties and possible use cases are to be documented, but AFAIK this is already required of any IETF document). Anything else will just reopen arguments, as it will be seen as an attempt to preempt the results of the discussion.

I'm also fine with Jari's second addition if people like it.

Personally, I would like to stress that in the end we want the user to be in control of DNS queries, as long as the user thinks to be technically savvy enough for it. Perhaps the third deliverable (the "informational document") should start from there, and describe how "users, client applications and systems" can manage their selections. But this is a minor edit, so I can also live without it.

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