Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

"Murray S. Kucherawy" <> Fri, 17 January 2020 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E07981207FC for <>; Fri, 17 Jan 2020 00:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p9S_BZreNxMJ for <>; Fri, 17 Jan 2020 00:06:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04F24120273 for <>; Fri, 17 Jan 2020 00:06:24 -0800 (PST)
Received: by with SMTP id x18so14343664vsq.4 for <>; Fri, 17 Jan 2020 00:06:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fyl1rH1TdGeq4hpj1lm7inX/fc68h4pbjFW62Qo0hHw=; b=GpUuxfPCeBDgkK3QoHTt3rcV7Locwkjsw+jSRE9J+JbDLkif/iBeM2F2M0SNVqsKRG z6nrdGu3omgfth/itG3lH2c5Syg5UqLNi+Y1pSVGlQyWM4Fa3K3dksLmRjX6XGDC8cRa BKHLPK1+p4bHn82hs0FeM9cP01XwSIOxTGs6Nb/rx83lwNOf2j9dE6LjrjbJuKA04xTG 8GtqHQ4oP4HWjENiJxNqwcBq96X38UvUsrkMXTHmkAfUeqt7oUMsbhkJgZ681OaGj1Wt FbDJNo89vprulZ56h/i4cH71Vp4aPqzO6RQumHC49wehm1oPsVgvOtbaH5wMGq8GPVnH Rkog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fyl1rH1TdGeq4hpj1lm7inX/fc68h4pbjFW62Qo0hHw=; b=L/gG+Lp4b0SFC3XqttmHcx5NFoHw1cTVGHZWhSEorW4TG5xWz003dfTiEHbdzFufOQ 3nQknxP1U/iyu05eaPa9wkYQv2fhg2OyY8z6ehgxC3oDQ0WxGPZPuBbcxEGosQPogvTL cGKsg3XHCcygUSSR4GnXB73QdksYBrS0hO2fAVHpQXSaRGyArAFCUIKJ1CN1Bh89wWfS Z9qFZig0XbuYJrwFzlt4SOYcQWk+o90fKRtDp0rZBqmXIgsuN8vNgaduUS20CyL64qRh SuQ5RXk5ySmDBufxeCnAtMm5SYaQylTopQ/gTHjRUbiqaImRzS6AAMMM6p2kL5RGgCdd 105g==
X-Gm-Message-State: APjAAAVd2mvP9wgO7UfQxuapDgakOKVRksn880NmgDmvVu9ZthTJ7aAW lonDQ7y1SnHuBtSktEZr6JGPKEZ6Te5/lKwO3ck=
X-Google-Smtp-Source: APXvYqzA3AI1dG0Qe144Lxm3GePpFO6aLgyVH4sjKNeIy8+OYK4msrIMzv+vHfp3bPCUlPOgmlWvI7KTe4zSo2vXJGI=
X-Received: by 2002:a67:ea87:: with SMTP id f7mr3878293vso.52.1579248382984; Fri, 17 Jan 2020 00:06:22 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Fri, 17 Jan 2020 00:06:11 -0800
Message-ID: <>
To: Dave Crocker <>
Content-Type: multipart/alternative; boundary="000000000000e148ae059c516a2a"
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jan 2020 08:06:31 -0000

On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker <> wrote:

> The IETF does not typically -- or, as far as I recall, ever -- promote
> specifications known not to scale.  (While I think of this concern as
> foundational to the IETF, it's a bit odd that nothing like it is

included in the IETF's "Mission and principles" statement.[1])

I'm not sure that I would reasonably expect anything labeled "Experimental"
to scale, especially if it were to make very explicit claims to the
contrary.  Nothing I've worked on at the IETF with such a label is
something I would necessarily stand behind as Internet-scalable.  But I
would probably expect something at Informational probably to scale, and
anything with "Standard" in it certainly to scale.

> > Comparing it to the "obs" grammars of days of yore, the PSD proposal
> > is much too expensive to become engrained as-is, whereas the old
> > grammars were relatively easy to carry forward.
> I don't quite grok the reference to "obs", and mostly think of the
> introduction of that construct in RFC 2822 as an interesting idea that,
> itself, failed.  (I see it as being instructive on the challenges of
> designing for transition from an installed base.)

That was indeed the intended reference.

All sorts of experimental specs fail.  But they aren't /expected/ to
> fail.  And they aren't expected to be unable to scale.

This one isn't expected to fail, but its mechanism is not (as far as I can
tell) intended to be permanent, nor could it become so.  In terms of
meeting its stated goal, we don't know the outcome yet.  We have a guess,
but we need data to confirm it, and everyone participating needs to agree
on how to participate.  That seems to me to be what an Experimental
specification is for.  The non-scalable component is part of the means by
which participants agree on the operation of the test itself.

Mostly, IETF/Experimental is used to check whether a spec is
> operationally viable -- it's expected to be but the community isn't
> quite sure -- or to check for community interest.  The latter
> constitutes market research, not technical research.

I would claim it's clear that this is the former.  We're trying to assess
whether this extended logic is a reasonable change to the accuracy of
DMARC.  Some of the supporting mechanism added in the experiment is
ancillary to that goal, and is discardable.  Nothing to do with market

A pointedly friendly reading of the relevant Guidelines might seem to
> support the publication under IETF/Experimental being proposed here, but
> a more critical one probably doesn't and I think that this use of the
> label doesn't really match common practice.[2]

The status chosen most closely reflects the intent and quality of the work,
certainly as compared to something aiming for the standards track.  And
there's consensus to move forward, or was when WGLC ended.  Quite a bit of
time has now passed since then and we are no closer to getting the answers
the working group needs to make progress on the core issues it's facing.
Rightly, there's now a lot of grumbling going on.

Since one of your core assertions is that the IETF shouldn't publish things
like this, I have suggested that, as a compromise, interested parties
proceed with the experiment using the document in its draft state.
Unfortunately I am also regularly reminded that there are organizations
wishing to participate in this experiment and related work but which simply
cannot, by reason of policy, do so without this document being first
approved for publication.  I personally find that position peculiar -- many
things from DKIM up to QUIC are implemented experimentally by very large
operators during development, without an approved document -- and it's not
really the IETF's responsibility to acquiesce, but nevertheless it results
in some urgency for this community to find a way forward here.

So: Can you propose any sort of specific restructuring of the document or
the experiment that achieves the same goal as the current version while
also resolving your concerns?

The real challenge for most IETF specs is community engagement, not
> engineering adequacy.

Interestingly I would claim we have clearly achieved the former here,
though obviously not the latter.

Also, any suggestion to rely on a published list ignores the history of
> problems with such lists, as well as at least requiring a careful
> specification for the list and a basis for believing it will be
> maintained well.

The list, as I understand its use in the specification, amounts to a list
of who's participating in the experiment.  When the experiment is done, the
list goes away, and the concerns of its maintenance would go with it.