From nobody Wed Jul 7 05:36:47 2021 Return-Path: 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 BF6023A1172 for ; Wed, 7 Jul 2021 05:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 NKSpGrjVq2Qi for ; Wed, 7 Jul 2021 05:36:40 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D463A116C for ; Wed, 7 Jul 2021 05:36:39 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id n14so3783825lfu.8 for ; Wed, 07 Jul 2021 05:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jGFHDei9mkG6TuYrc0Ok1yZdk0Oylcydp2MHQCEkspQ=; b=daPnCU48qqsyqRbeyRQNrvLC4d2N228Vc6fqcDoy8JfFI9bLKgdcBtLF1fNVOtNFjx RQ21AwBml8Nj9swe+M4/XaQaCZ7sZHW0ab/oU9R8Bslh4Jx1wDwZjrEmxk2UOAwiAscg gSCfRkkpKRKccp08jkaB2VFUTiXV8M4PDiyDSrr/dwzyXO9BfcFwqxfhRNs2wafSzCF3 6cgfkQ15Hci8H9skD3PcD5ZKGod21IRWqMSTW5lw/SnFI+ebVxK9BeRcSlW0re1Mo8W+ MHmffETzKiGCfmxK2ITMOtPGdpGqc46nDKINl5gYwu4rKzxNWQ1mHlFuYHvCYx1RCu4g hZDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jGFHDei9mkG6TuYrc0Ok1yZdk0Oylcydp2MHQCEkspQ=; b=efrB02wwM/mHEDHo0vY9Wxu/TsjRHTnRThS7h/mfKdLpuP5xIT5gOdXhWqhPpZ0gy/ yEzq9T06DBCfA9Nm/39vuPR+VMUrTlz1pX3g4asqgCKrgZhu8XO8AWtQwRSCMmuP6qOu tPN1uY1nwUz2ot9uAaiabP/jXSmn1UtDjXBWESFZc+0QNfigbjUgtJKRInXcnyB8fgk/ yjp02rhpikIPbutUjNYWZzg+QxB5S8bSnU9Dw5U32dIDHubNe9CwZ8vSQuiaoO67csgN NulvZrgaEa1PVrNfruTCYNyz3sY4LTsqK24s2ep4AycKVfHvCFQ3FAqzEChOrlYj7Ikq ak/g== X-Gm-Message-State: AOAM530ssVWUPY+nbPYKMK2s6QS/As92RX9R9Abr2FDblccaAy76TUpv L2f6XZQszsvOeU55LCoQwmK7mYBGJVkcfCmAGxE= X-Google-Smtp-Source: ABdhPJznAI2vymi/uPfZvt3ev4V0M58NsgpL2MirI+flvFvp9AArxCWdRrZuUPdNlcaPJvEwT+htHNHuiO/v3LL5Jmo= X-Received: by 2002:ac2:548a:: with SMTP id t10mr4587055lfk.247.1625661396570; Wed, 07 Jul 2021 05:36:36 -0700 (PDT) MIME-Version: 1.0 References: <121ae494-d7f0-37da-cf53-44f75df2fa75@innovationslab.net> <51ecd372-c178-14ff-5168-81e2e87350e9@innovationslab.net> In-Reply-To: From: Alexander Mayrhofer Date: Wed, 7 Jul 2021 14:36:25 +0200 Message-ID: To: Andrew Campling Cc: Brian Haberman , "dns-privacy@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dns-privacy] 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: Addition of privacy to the DNS protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 12:36:45 -0000 Picking up on this (speaking as an editor of the draft). I don't have any issues with option #4 (dropping the draft), and it has expired some time ago anyways. However, if we need a space to document operational concerns around any specific solution (for example, to avoid repeating the same concerns for each new solution space document), then i think the document could provide a useful contribution to the WG. Also, i do remember that we initially mulled never progressing the draft to an RFC anyways, so it seems its current fate pretty much fits that original intent. If we do want a space to collect "concerns", a document with "requirements" in its name would be slightly misleading, though - "design considerations" or similar would probably fit that purpose much better. We could also use a wiki page somewhere for that, but i think even an expired draft is a more stable resource, compared to a WG wiki page. Some of these "design considerations" i've heard / can think of over the last years would be: - Protocol should not require any probing by recursive servers - Protocol should require as little state as possible - Recursives would have a much larger set of open "upstream" connections than a stub resolver (obviously), so footprint of these sessions is critical - Auth servers would see a similar amount of open "downstream" connections, though that end is probably similar to what recursives see downstream - are there differences? - Quality / Level of authentication ("better than nothing" principle?) So, if we go for option #4, would it make sense to collect those (and similar) considerations somewhere? best, Alex On Tue, Apr 27, 2021 at 11:25 PM Andrew Campling wrote: > > On 26 April 2021 20:45, Brian Haberman wrote: > > > Does anyone else have an opinion on this? > > > On 4/19/21 5:13 PM, Brian Haberman wrote: > >> All, > >> As was raised on the thread discussing suggestions for the > >> requirements draft, there is some question on how the WG wants to use > >> draft-ietf-dprive-phase2-requirements in progressing our > >> recursive-to-authoritative privacy work item. The draft currently has > >> one sub-section that describes requirements (5.1) and another section > >> that describes optional features (5.2), albeit with 2119 SHOULDs. > >> > >> 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. > >> > >> Let's discuss the focus of the draft and then we can determine what > >> updates are needed/necessary. > >> > >> Regards, > >> Brian > >> > > Building on the Root Server Operators Statement on DNS Encryption, I thin= k there would be benefit in gaining input from TLD operators to establish w= hether they are interested in adopting encryption, as well as any insight i= nto deployment considerations, the relative attractiveness of potential sol= utions etc. Developing solutions without sufficient understanding of the r= equirements and operational concerns of the intended beneficiaries risks wa= sting a lot of effort pursuing the wrong solutions to the wrong problems. = Capturing this information would seem to fit within a requirements document= . > > Andrew > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy