Re: [dns-privacy] [Ext] How do we want to use draft-ietf-dprive-phase2-requirements?

Peter van Dijk <peter.van.dijk@powerdns.com> Thu, 22 April 2021 15:27 UTC

Return-Path: <peter.van.dijk@powerdns.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B345D3A13EC for <dns-privacy@ietfa.amsl.com>; Thu, 22 Apr 2021 08:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 NtylZplJG6R4 for <dns-privacy@ietfa.amsl.com>; Thu, 22 Apr 2021 08:27:41 -0700 (PDT)
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 B4CD93A13EB for <dns-privacy@ietf.org>; Thu, 22 Apr 2021 08:27:41 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPSA id D00356A0CE; Thu, 22 Apr 2021 17:27:38 +0200 (CEST)
Received: from plato ([84.81.54.175]) by imap.open-xchange.com with ESMTPSA id bTQiMuqVgWAxPgAA3c6Kzw (envelope-from <peter.van.dijk@powerdns.com>); Thu, 22 Apr 2021 17:27:38 +0200
Message-ID: <a2310393fccf6eb8edf2299df69a842889a6c1a5.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Date: Thu, 22 Apr 2021 17:27:38 +0200
In-Reply-To: <E3EDCE70-5796-4F24-B10C-D951F48D3665@icann.org>
References: <121ae494-d7f0-37da-cf53-44f75df2fa75@innovationslab.net> <E3EDCE70-5796-4F24-B10C-D951F48D3665@icann.org>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/kr_GZQMYDAXd23N7rV7KwU-Wb3s>
Subject: Re: [dns-privacy] [Ext] How do we want to use draft-ietf-dprive-phase2-requirements?
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2021 15:27:47 -0000

On Tue, 2021-04-20 at 16:59 +0000, Paul Hoffman wrote:
> On Apr 19, 2021, at 2:13 PM, Brian Haberman <brian@innovationslab.net> wrote:
> >     My question to the WG is how do we want to use this draft? I see
> > four possible approaches, but I am sure someone will point out others.
> > 
> > 1. Strictly requirements - these would be MUST-level functions that the
> > WG determines have to be supported by any solutions draft.
> > 
> > 2. Strictly design considerations - these would be functional areas that
> > the WG determines need to be considered, but not necessarily included,
> > by any solutions draft.
> > 
> > 3. Requirements & design considerations - This is generally where the
> > current draft sits IMO.
> > 
> > 4. Drop the draft and let the solutions flow.
> 
> As a document author, I prefer #4 but with a modification: every solution document must have an honest, readable Security Considerations section that covers the design considerations. By "honest", I mean that the text there needs to have WG consensus, including of the people who have a different preferred solution. 
> 
> My rationale for no longer needing a separate document is that the WG discussion of adopting the opportunistic/unauthenticated draft, and the possible adoption of the fully-authenticated draft, has pretty much fully brought out all the requirements and design considerations for both proposals. 

This makes sense to me. The explored solution space (which is way
bigger than the viable solution space!) has covered so much ground,
we've basically already seen it all. So, it is better to judge each
proposal on its own, honestly stated indeed, merits (and demerits).

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/