From nobody Mon Apr 26 18:12:33 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 CE9833A08DE for ; Mon, 26 Apr 2021 18:12:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 6L6Ex_ff95Rg for ; Mon, 26 Apr 2021 18:12:26 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 8F5E13A08E4 for ; Mon, 26 Apr 2021 18:12:26 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id v123so6860275ioe.10 for ; Mon, 26 Apr 2021 18:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iqj9Gfu0iwdvfcnJ8lpOqZcDAOpLcR1FgU86KN0vdRs=; b=r23Vb9ckPSNhz6RF7xNzDVtSLHeF08JiSQtYNixdJUxJqQjKJc+Bm2kfjaW3AJLzvh R0lVgJE+jtAt7FRXRdPZCxZFzmG73yzoZdpFAYUV47VnQBrwPgHA3ov1DXwNOaAA++jh xSyRUlCYlrvzCWPx5WoRETINpKHY3e7nM/M358WjgF7RDSeji78J6fIRz+uUKTM2mzNn V0HAy/y6vqDgDJQWgiGNjXq+g1DmruN+Io6CYumMOT/c5ExWN2K13w5JdJFeqpLiG+gu /7NWOxLpbluP5nnJbrRncXe4p4kWz8q59Gvl99TqZSXcViL9pcV24lha/BWxwYOAeewL sdHA== 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; bh=iqj9Gfu0iwdvfcnJ8lpOqZcDAOpLcR1FgU86KN0vdRs=; b=NwmT9CyHF2e3DJwsRucbbt2XNKlmR5YEQzsDunndH2Q7rIcCjouQgOCrQdgmSivIyM Pfm9JyYQUPvfrv69Ww7MZw0oVhHJQBQX+pRH9MGpQanHH+hHbmam08KR4/X/5V93vJWV aolxINnN+s1nYO5Di3cTpwQ96ffA6CEM47JcL12qYyVwVB5POyMJvalz66WMwAlsmBc5 SaqZMTsMAjdonByGqrm4iTdXcJT0lp7czqTudvoSHc8t/tyP6BuYtAhpdQNXj5iKvVJb I6VR+lYzS/kvA6GFFcMBj5Dz+Wg6OTm1hioooBTOjkjfH8oKUzu0R8kUJC2N35Ik5veH q99w== X-Gm-Message-State: AOAM533ZsFiAeATkWsU5Uadd5yil3ZiTmwDXVwZRObWJgOCHREaJ1nwE MV07cA2JnRgV4ki7I/gZ1eirReLNWSa1BdEdrmBE5w== X-Google-Smtp-Source: ABdhPJyn/PA09SBov0IRDY783AbyiRD6VFWzi4M4DSxLeqqxwkkCx69zUiAmGmZNKR8ruMzvUvbPGjSNHGQQ0Nv2uXI= X-Received: by 2002:a05:6602:122a:: with SMTP id z10mr9765324iot.60.1619485944489; Mon, 26 Apr 2021 18:12:24 -0700 (PDT) MIME-Version: 1.0 References: <121ae494-d7f0-37da-cf53-44f75df2fa75@innovationslab.net> <51ecd372-c178-14ff-5168-81e2e87350e9@innovationslab.net> In-Reply-To: <51ecd372-c178-14ff-5168-81e2e87350e9@innovationslab.net> From: Eric Rescorla Date: Mon, 26 Apr 2021 18:11:48 -0700 Message-ID: To: Brian Haberman Cc: "dns-privacy@ietf.org" Content-Type: multipart/alternative; boundary="00000000000070c1dc05c0e9f4a6" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 01:12:31 -0000 --00000000000070c1dc05c0e9f4a6 Content-Type: text/plain; charset="UTF-8" I also prefer #4. On Mon, Apr 26, 2021 at 12:45 PM 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 > > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > --00000000000070c1dc05c0e9f4a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also prefer #4.

=
On Mon, Apr 26, 2021 at 12:45 PM Bria= n Haberman <brian@innovation= slab.net> wrote:
Does anyone else have an opinion on this?

On 4/19/21 5:13 PM, Brian Haberman wrote:
> All,
>=C2=A0 =C2=A0 =C2=A0 As was raised on the thread discussing suggestions= for the
> requirements draft, there is some question on how the WG wants to use<= br> > draft-ietf-dprive-phase2-requirements in progressing our
> recursive-to-authoritative privacy work item. The draft currently has<= br> > one sub-section that describes requirements (5.1) and another section<= br> > that describes optional features (5.2), albeit with 2119 SHOULDs.
>
>=C2=A0 =C2=A0 =C2=A0 My question to the WG is how do we want to use thi= s 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 th= e
> WG determines have to be supported by any solutions draft.
>
> 2. Strictly design considerations - these would be functional areas th= at
> 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 wha= t
> updates are needed/necessary.
>
> Regards,
> Brian
>

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.= org
https://www.ietf.org/mailman/listinfo/dns-privacy
--00000000000070c1dc05c0e9f4a6--