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

Dave Crocker <> Mon, 11 November 2019 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C047A1201E0 for <>; Mon, 11 Nov 2019 14:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FZrVkT-vt2D4 for <>; Mon, 11 Nov 2019 14:21:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B665812010D for <>; Mon, 11 Nov 2019 14:21:21 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id xABMLj9A008065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2019 14:21:45 -0800
To: "Kurt Andersen (b)" <>, Tim Wicinski <>
Cc: IETF DMARC WG <>, Scott Kitterman <>
References: <> <> <> <> <> <> <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Mon, 11 Nov 2019 14:21:12 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------612D8FC2A5296B5AFC4D2BFD"
Content-Language: en-US
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: Mon, 11 Nov 2019 22:21:34 -0000

On 11/11/2019 7:46 AM, Kurt Andersen (b) wrote:
> I do have a problem with the conflation of the org domain with a 
> super-organizational "realm" (?) that may impose conditions upon 
> organizations that fall within their jurisdictional purview.

This goes to the essential challenge of a proposal like PSD.  It 
embodies a particular model, in the absence of clarity about the model 
or broad-based discussion of its appropriateness.  (Note, for example, 
that my review offered some discussion of that sort but got no comment 
on that discussion.)

In effect, it creates a strategic solution -- that is, a long-lived and 
embedded mechanism -- without a clear and broad understanding of the 
organizational space it is working in.

On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
> * add text to the PSD draft making it clear that what it's describing 
> is an experiment whose outcome will be taken only as feedback to the 
> revision of the standard (i.e., this is not intended to be the final 
> form of anything), and it is not intended to be deployed outside of 
> the experiment's participants;

Forgive me, but while everyone involved in this has extensive experience 
and is trying to solve a real and serious issue, this is an 
astonishingly naive view.

The IETF does standards, not experiments.  Not /real/ experiments.  What 
it calls an experiment mostly serves as market testing, with a smidgen 
of engineering tuning later.  For the most part, IETF experiments 
produce an accepted/failed/needs-small-revisions range of results.  What 
it does /not/ produce is results along the lines of "that was 
interesting, now let's start fresh and do the real standard."

Perhaps there are exampls of IETF experiments that have permitted 
entirely starting over, but mostly those only happen when there is a 
complete failure, and those typically are called experiments.


Dave Crocker
Brandenburg InternetWorking