Re: [Last-Call] [Gen-art] [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

worley@ariadne.com Tue, 17 November 2020 03:16 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE4A3A0659 for <last-call@ietfa.amsl.com>; Mon, 16 Nov 2020 19:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.983
X-Spam-Level:
X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 YSTL_H68XDci for <last-call@ietfa.amsl.com>; Mon, 16 Nov 2020 19:16:44 -0800 (PST)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 0357B3A0656 for <last-call@ietf.org>; Mon, 16 Nov 2020 19:16:43 -0800 (PST)
Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id erKekFLtXYiElerU2kfJhg; Tue, 17 Nov 2020 03:16:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1605583002; bh=NdIV1m5jwJK0+TklFo4TvQB3jpPmruUxm6rKKiD+34Q=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=DC0EZTzG3upozM80RaWwD0+HVrRvMr5noY9FcCceHPOttr3D/fxgru61oCQ3t+sym VMP6lq6rVeAsyLs24a3xocpdxnRgO3IlkCAxSKaedvW0BGLnsn69b5IguWcHZL2b1v 8SbEWrwvjaYL5Rm6XuQO4CPm+VKc3Sp/csbNKq5TFm4fDl8rWzn0cm2nyGoskWkIR2 c9xzYcabkG3hwQQC7t3u/7d4i5vG+YdMNJo3Q3O9hknpGjJGq6Fyqkjy+RyxFzr2sP /UOnub6DdS4TrdqnJuUczz/TmeNXl8hpXOnHjoRSdzld3O3nfvEzjOK5F4SVX/kTpv K6SYcsQfEqY6A==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with ESMTPA id erU0kEeT2BuUOerU1kDLyX; Tue, 17 Nov 2020 03:16:42 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0AH3GeTR008694; Mon, 16 Nov 2020 22:16:40 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0AH3GdSv008687; Mon, 16 Nov 2020 22:16:39 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: scott@kitterman.com, last-call@ietf.org, dmarc@ietf.org, gen-art@ietf.org, draft-ietf-dmarc-psd.all@ietf.org
In-Reply-To: <CADyWQ+Fb93SkiAnL4cuCfxC5Wi1ERLeKhguWqAp3j8YEa6JBSA@mail.gmail.com> (tjw.ietf@gmail.com)
Sender: worley@ariadne.com
Date: Mon, 16 Nov 2020 22:16:39 -0500
Message-ID: <87ima4wu3s.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/aPCJX4z4YdmPCH69e-9b4xgj-WI>
Subject: Re: [Last-Call] [Gen-art] [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2020 03:16:46 -0000

Tim Wicinski <tjw.ietf@gmail.com> writes:
> Apologies for the delay on the PSD updates.  I sat down with Scott and went
> through your review and made lots of edits
> related to your comments.  I actually attached the reply to your email as
> it's been sitting in my editor buffer for a few months too long.
>
> One normative change that I want your assistance on is the descriptions of
> the Experiments.  I updated them and pulled them apart, to make them more
> understandable to folks looking at this for the first time.  I'm not still
> 100% on them.
>
> I want to go back through your opening Nits/editorial comments to make sure
> I'm not missing anything.
>
> Here's the link to the diff.
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09

My apologies for not tending to this promptly.

In regard to the description of the experiments, the result criteria are
rather subjective, but I don't see that as a problem.  It does seem to
me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
too narrow, as only the 3rd experiment seems to be about privacy
issues.  A title as generic as "PSD DMARC Experiments" would be fine.

Looking at the diffs, I notice that I find the new sections 2.3 through
2.6 straightforward.  Oddly, they aren't much different than what is in
the -08, which I found confusing.  It's not clear why ...  Perhaps it is
because the -09 version starts with attention on "organizational
domain", which one has an intuitive understanding of, and defines the
other terms from there, whereas the -08 seems to focus on "PSD".

Although I note that even the -09 does not define "PSD", only "longest
PSD", even though "PSD" is used in section 2.5.  I suspect that PSD is
equal to "PSO Controlled Domain Name", though, or rather to some related
set of them.  That needs to be cleaned up in some way.

In section 3.5 and later there is the phrase "[this document] longest
PSD".  I'm not sure, but I think this is supposed to be "longest PSD
([this document] section NN.NN)".

I believe that my strongest critique was that section 1 is difficult to
understand if one does not already understand DMARC, and it does not
seem that the section has been revised.  Re-reading it, I notice that it
says "DMARC leverages public suffix lists to determine which domains are
organizational domains."  Ignoring that I dislike this use of
"leverage", a critical point is that it takes the existence of public
suffix lists a priori -- indeed, this use of "leverage" generally means
that the leveraged thing already exists and one is now extracting
additional benefit from that.  Whereas I've never heard of public suffix
lists and would naively expect that they are difficult to create and
maintain.  It might be better to say "DMARC uses public suffix lists to
determine which domains are organizational domains.  Public suffix lists
are obtained/maintained/distributed by ..."

Looking at the second paragraph of section 1, I notice that despite all
the special terms for classifying domain names in section 2, the example
in this section does not describe which of the domain names that it
mentions fall into which of these classes.  E.g. "tax.gov.example" is
said to be registered, but it looks like it is also the organizational
domain, and "gov.example" is its longest PSD.  It would also help to
mention that "tax.gov.example" is "registered at" "gov.example" to
introduce the details of the usage "registered at".

    Suppose there exists a domain "tax.gov.example" (registered at
    "gov.example") ...

Dale