Re: [dns-privacy] Roman Danyliw's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Wed, 04 March 2020 13:30 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 0A0B03A0EF1; Wed, 4 Mar 2020 05:30:56 -0800 (PST)
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 90wjls14prku; Wed, 4 Mar 2020 05:30:54 -0800 (PST)
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 0E1BA3A0EF0; Wed, 4 Mar 2020 05:30:54 -0800 (PST)
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=mXxE4JatLQjaUA0sXaRJ+8Ie3amFzmL0U1ymcMMenJg=; b=NZxTfMsRqTjOA/nbH1exuWvh5h QJlLc4imUnRLQ8oyiCpcYyGt7jzdjMqAtNyfQ+7+dpLibeT6Oc1jW9RHEzxCdW8R6Wo9VnKXslhda xhcen9HyCX3xwy5Oc1I7g8czU3QhDKbgHDS1zxoi3Rag2S/azzDFqNlpTOiPk3r9wQYy+DoddsaRA Oll18UbsQyG3NDywXccpb429SaW4+QuYdIBRlhyDZ9/Mjt+rKjj8AtUIWmASz6k5L+3AMXDiOLS9/ g9eHy2W/sx08g+c3Wy0N0zs20eDyBpF5pdkujnYUvXq6IXVnmUtN4KL4zLRko4RV3m9WNS3I1lQca b/OujPxw==;
Received: from [2001:b98:204:102:fffa::2] (port=63226) 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 1j9U6p-0001Dt-Qk; Wed, 04 Mar 2020 13:30:51 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <158086850303.15764.11037418418570151550.idtracker@ietfa.amsl.com>
Date: Wed, 4 Mar 2020 13:30:44 +0000
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-bcp-op@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E891BAF9-67BF-49CF-AC78-467D9DFDEA28@sinodun.com>
References: <158086850303.15764.11037418418570151550.idtracker@ietfa.amsl.com>
To: Roman Danyliw <rdd@cert.org>, Vittorio Bertola <vittorio.bertola@open-xchange.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/D-8kRpky3Cw7wcT1OPsts0jMLrA>
Subject: Re: [dns-privacy] Roman Danyliw's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)
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, 04 Mar 2020 13:30:56 -0000


> On 5 Feb 2020, at 02:08, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-dprive-bcp-op-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Per 6.1.1.  Item 2.  Per “Data Collection and sharing … and in each case
> whether it is aggregated, pseudonymized, or anonymized and the conditions of
> data transfer”, would be useful to also have the policy describe the technique
> used to realize this minimization?

Yes - that seems a good idea where possible. Suggest adding the following sentance at the end of point 2:

“Where possible provide details of the techniques used for the above data minimizations. "

> 
> ** Section 6.1.2.  Item 5.  Per “Jurisdiction.  This section should communicate
> the applicable jurisdictions and law enforcement regimes …”, what’s a “law
> enforcement regime” (and why is that different than a “jurisdiction”)?

Note that whole of Item 5 is the subject of a DISCUSS raised by Alissa and may be removed...

I’m no lawyer so happy to have further clarification on this but my understanding is jurisdictions are the legal body with the power to apply a given law but a law enforcement regime is enacted by a specific body tasked with actually enforcing a given law. For example in Europe there may be e.g. a competition law that applies to the EU as a jurisdiction but I know that individual countries have their own law enforcement bodies to investigate and prosecute that law locally. 

I’ve cc’ed Vittorio who helped develop this text in case he wants to comment further….

> 
> ** Section 6.2.1.  Per item 5.4.  Why restrict disclosure to “law enforcement
> agencies, or other public and private parties dealing with security and
> intelligence”, and not request disclosure of all parties who get access with
> “Specify whether the operator has any agreement in place with public or private
> parties to give them access to the server and/or to the data”?  One party’s
> assessment of an entity as “security” (captured in the current text) is
> another’s “public safety” (not captured in the current text but captured the
> recommend text)

That seems reasonable although keeping a specific mention of law enforcement agencies seems a helpful clarification?

“Specify whether the operator has any agreement in place with law enforcement agencies, or other public and private parties, to give them access to the servers and/or to the data."

> 
> ** Editorial Nits
> -- Section 6.1.2.  Typo. s/section Section 5/Section 5/g
> 
> -- Section 6.1.2  Editorial Nit. Per item 5.2, “… and how to contact the
> operator to enforce them”, it is more appropriate to say “exercise them”, e.g.,
> a user contacts the operator to exercise their “right to be forgotten” (not
> enforce their right to be forgotten).

Ack. 

Best regards

Sara.