Re: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-bcp-op-10: (with DISCUSS)

Sara Dickinson <sara@sinodun.com> Wed, 01 July 2020 09:00 UTC

Return-Path: <sara@sinodun.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 C0E3D3A0C5D; Wed, 1 Jul 2020 02:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_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=sinodun.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 rWpefFDGSABc; Wed, 1 Jul 2020 02:00:52 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 D88EC3A0C5B; Wed, 1 Jul 2020 02:00:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=meyZVsNFk3Ih4A29PL2UoLkNHm/BHmvovBWPwrc1W1I=; b=FIo9Uf28aWeqGaKmbOCAcQhfBP vLRk4+q2wQJWT0Yfn156W020kdpy/zQVcEWEjGpJy0Ucp6cCrPan1C3ynCmID13HUfRXoIivN2ypN Q5eY10AhvtsvFJ+9s8SU+J1OPA1SHdmcyrWgA5uGUmJNleAR+tmhxWFpu2pIZ8EBVe18QPZ9+qz5t jDdvTNHQ7MTUVxW/h/hvyjm+9DEtWp0BwvgDrLZrUn2kgiSklcy397ijKW62OhZqMi+Udjm2lRDH6 gLGgEAJjTtbah5nl1aT3xm7xiNWf/Kntq9P34AWTi3WwpC2uxIjHvjPsvIdl8DnZvNC1CVeRFOXJq IXqBRfcA==;
Received: from [2a02:8010:6126:0:e1d4:15cc:815f:b90d] (port=58714) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1jqYbm-0005Zs-3p; Wed, 01 Jul 2020 10:00:50 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <159336986640.29578.8552307310998923775@ietfa.amsl.com>
Date: Wed, 01 Jul 2020 10:00:38 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-bcp-op@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <20DBE6EE-1ACF-4BD9-A9BD-88605F57393A@sinodun.com>
References: <159336986640.29578.8552307310998923775@ietfa.amsl.com>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/_4Kw0IsXIg4SOtaUO1cYgRHc14I>
Subject: Re: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-bcp-op-10: (with DISCUSS)
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: Wed, 01 Jul 2020 09:00:54 -0000


> On 28 Jun 2020, at 19:44, Alissa Cooper via Datatracker <noreply@ietf.org> wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-dprive-bcp-op-10: Discuss
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Trimmed to the one outstanding point from my original DISCUSS:
> 
> I do not think item #5 in Section 6.1.2 belongs in this document. I don't see
> how it is within scope for the IETF to be specifying these sorts of best
> practices, which are not technical or operational in nature but focus on legal
> matters and likely require the involvement of lots of lawyers in order to get
> the provisions written. This section implies that the DROP documents would
> become legal/compliance documents by nature, which may or may not be a good
> choice but is not within the remit of the IETF to specify. Also, I think what
> this section asks for is not the norm today and therefore it seems odd for the
> IETF to specify a best practice that operators may not have any chance of being
> able to comply with (e.g., listing specific law enforcement agencies, privacy
> laws, or countries where data centers will reside and the data will never move
> from them).

After discussion amongst the authors, we are very keen to at least retain a placeholder within the DROP statement so that readers can easily access any complimentary documents that do deal with such matters. We would like to propose replacing item 5 with the following text: 

“5. Data Processing. This section can optionally communicate links to and the high level contents of any separate statements the operator has published which cover applicable data processing legislation or agreements with regard to the location(s) of service provision. "

Best regards

Sara.