IETF Logo Mail Archive

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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 20 April 2021 12:20 UTC

Return-Path: <shollenbeck@verisign.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 BFF9C3A205D for <dns-privacy@ietfa.amsl.com>; Tue, 20 Apr 2021 05:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=verisign.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 CLx-j9gssIZG for <dns-privacy@ietfa.amsl.com>; Tue, 20 Apr 2021 05:19:58 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 16DFD3A205C for <dns-privacy@ietf.org>; Tue, 20 Apr 2021 05:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2230; q=dns/txt; s=VRSN; t=1618921198; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=ykhdhZ+wjyTEqZLgsohuAjhOE4JyzWCeH3K/nGFDPos=; b=oJPc4RQPni2wzP3cnEcZw/ze1Wp2eGPIahgi/tH3o1eOX+BfgRzvEKEx BaDGFBU9MoozbVXhx3+55eHxZyl6VNubKLVxfmUSSEEEwMYJA3j+2AGh0 24dUGYDCoR5Ktg+v8l8IvcHsutPawW18m0SCPxS/dUpk9GhIrunmG+DlT oj15jlDBWVwBRYkrJEUKx0UVUD1h4dgmsSd0hBljRu4QCX46Sne88m+O7 5B6IFKix8LVaCTQ0pbCtfHNP0X4BU0etub/7jg+CZyybaONkVPAkID2cf tCpHTJfWMoaOtRe/AFvarnwPQytPNjv4eXRREHjjYOBzKpoFQkkhg3Eiy g==;
IronPort-SDR: 7AFxcyHW6uDk0MFwUO0+0sRAKTliHdJcmsgXUv53DXFPRXflaCMeCNPgx8XWhsblZChySQ9AIj KfYfbpO8xkS/Mxka2YPdVpu99DEAhg5lqDAlSVImk7mAVUGoiHPcFNWOR4Hut4wP56Zv9zPoCv OtjLFFCQTxCPPJtKwqswgYeyMjrFhqMTZWKG0rS9eae8T3f5+eeLLOprIfg5EvhwJlyx/4JbwR eL4tsM4LoT8erfm6BrZm04rz5tYBWUzFYBnDEZ263dYRe/oRB+oFQtCS4BRCcCD+l3US7AveeQ JvM=
IronPort-HdrOrdr: A9a23:/ag7JaiAZrQlONEGGsa9C5tvE3BQXk0ji2hD6mlwRA09T+Wzkc eykPMHkSLugDEKV3063fyGMq+MQXTTnKQFhLU5F7GkQQXgpS+UPJhvhLGSoQHINiXi+odmtZ tIXLN5DLTLY2RSqebfzE2GH807wN+BmZrGuc7kw31gTR5nZshbhm9EIzyGGU57ThQuP+tbKL Og4KN8xgaISDA4YsO2HXEZU+WGjM2jrv7bSC9DIxI88gGBgXeL5K6SKXKl9yZbdz9U278t/S z+jgrj6syY3s2T0BPGyGPJ1ZhQlebgztcrPqextvQ=
X-IronPort-AV: E=Sophos;i="5.82,236,1613451600"; d="scan'208";a="6706688"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 20 Apr 2021 08:19:56 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2242.008; Tue, 20 Apr 2021 08:19:56 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "brian@innovationslab.net" <brian@innovationslab.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [EXTERNAL] [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?
Thread-Index: AQHXNWDXNeWKVYu0REGuAnGRzqUKiaq9UwjA
Date: Tue, 20 Apr 2021 12:19:56 +0000
Message-ID: <3aca269d4fc64338aa0c32792ca831ff@verisign.com>
References: <121ae494-d7f0-37da-cf53-44f75df2fa75@innovationslab.net>
In-Reply-To: <121ae494-d7f0-37da-cf53-44f75df2fa75@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/a9U0Qe0vI7W_icJDDOGLWnwK_v0>
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: <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: Tue, 20 Apr 2021 12:20:03 -0000

> -----Original Message-----
> From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of Brian
> Haberman
> Sent: Monday, April 19, 2021 5:13 PM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] How do we want to use draft-ietf-dprive-
> phase2-requirements?
> 
> 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.

I prefer option #3, but with a change in order such that we describe design considerations first, followed by requirements that are derived from those considerations.

Scott

v2.30.2 | Report a Bug | By Email | System Status