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

Dave Crocker <> Fri, 17 January 2020 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93232120018 for <>; Fri, 17 Jan 2020 08:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 f0lNpcOdPdHj for <>; Fri, 17 Jan 2020 08:44:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D38DD120043 for <>; Fri, 17 Jan 2020 08:44:29 -0800 (PST)
Received: by with SMTP id r27so23037811otc.8 for <>; Fri, 17 Jan 2020 08:44:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=WY0tpEPOqs8lEXjOnA5q/pH2cuRT46/ChymCVO9Eyek=; b=fRUMRBPGhs1D+fe1nCVet8XfeGwHNlZFKVtao6MCGNf2GwVZFW8ZPjpaXG0sHNHHHs g5kIz6YjWVmb0YwriSm4kYGD2/dz3yx+LdINohL79ro//a2IVmmZOfuUtkhQlFtm2sAa mnnX6btIUJHirLJa06APSad0gfEPg3Y9IZQMZ5nHpv1ZhbFMC1b28cLuZpRizKqlcKH6 x4tdwJW9FP7aIz+wEoevc0x92iVfNcSEOAVWqpDUBb0fqih/M/8IfpTqpAw0CA3o45re ZWgom5I5lx0lSQZk9+bFv0gP1uK3m+r9HIFhNVq7dm3ApMxCuEHPB3v9uJJYoP4MZ/nL ZCBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=WY0tpEPOqs8lEXjOnA5q/pH2cuRT46/ChymCVO9Eyek=; b=G7MgjBomrDV9IBupoRVIKbCWrYiKO1btgz2oowbDo/3/LgsQosW3FWqc9HSMHV48Tb yGmESm6v+Qbf4pGf8zIoN1KbJ8+zN2VuhHeX2Y70alu96OtLvLCd4IrBBQiNapriqvpH pQ0x6AF10PpB99D0b1Uy4zuhT+QnGmXqDPcNDznn7T4s6w6xMr1IS1qDF1dS6V3phH6R 7EXYXVO90x3ZkunxO7SR57dGjuRKg2jrxeQvrndoayR7zbxjrVR5MIZ4iW+RdHqKfbLW 89m6mHMt6TbLeN4KVvwmMOd5XclRoF9UPzqjpLd39XS4CPQDCBscwOpWvZUfsw8CW47k NL7g==
X-Gm-Message-State: APjAAAWATdMN9Q4TGtyVszW6ruxNdbYojPd/NwEuEZNd3bGoIIjqYFk+ vunSMhxtna+jXD92PUijRzE+w/kj
X-Google-Smtp-Source: APXvYqzfxTwuzc4rCAknrbT7uaJR8tLmRvQuEQ5Ov4BF/6iNTaG/bqbrRp1mKZ5NKAOGliioUjUFIg==
X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr6622717otr.82.1579279468923; Fri, 17 Jan 2020 08:44:28 -0800 (PST)
Received: from ?IPv6:2600:1700:a3a0:4c80:649c:3df8:f4d6:1f10? ([2600:1700:a3a0:4c80:649c:3df8:f4d6:1f10]) by with ESMTPSA id q25sm9113171otf.45.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jan 2020 08:44:28 -0800 (PST)
To: "Murray S. Kucherawy" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Dave Crocker <>
Message-ID: <>
Date: Fri, 17 Jan 2020 08:44:25 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------4D264ECD60FDB3CF8CE454AC"
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: Fri, 17 Jan 2020 16:44:37 -0000

On 1/17/2020 12:06 AM, Murray S. Kucherawy wrote:
> 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.

As a standalone bit of thinking that sounds reasonable, but it does not 
match my sense of IETF history, nor my sense of application of that 
model in the case of X-.  What you describe makes sense for something 
out of the IRTF, not IETF.

As for IETF history, while there certainly have been IETF Experimental 
RFCs that have failed, I don't recall their being /expected/ to fail.  
(I'm counting inability to scale as failure. If anyone has a different 
view of inability to scale, there needs to be a separate discussion...)

For the latter:  X- was an email header field construct design to make 
an explicit statement that something was /not/ a standard header field. 
I was added to the RFC 822 spec, though I do not remember who first 
suggested it, other than it wasn't me.  I thought it a fine and 
reasonable idea, as did many others.  Note that it was eventually 
deprecated. Because it did not work as intended:  People using X- fields 
came to rely on them, creating defacto standards.

That's the danger with an IETF stream RFC, especially one coming out of 
a working group: Those implementing and using an IETF published 
specification tend to come to rely on continuing to use it.

> Nothing I've worked on at the IETF with such a label is something I 
> would necessarily stand behind as Internet-scalable.

Such as?

> But I would probably expect something at Informational probably to 
> scale, and anything with "Standard" in it certainly to scale.

Laying any general expectation on an IETF Informational RFC would be a 
mistake, because there is so much variety in their content and intent.

>     > 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.

I don't understand how you see benefit in citing a reasonable idea that 
failed -- obs- did not serve its intended purpose and was in a standards 
track specification: The obs- rules both weren't deprecated from later 
work and continue to be relied on. If anything, it validates my concern 
about entrenched use.

>     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,

If it is known that it can't scale, that's inherent failure for IETF work.

> but its mechanism is not (as far as I can tell) intended to be 
> permanent, nor could it become so.

You keep making statements that warrant this as IRTF work, not IETF work.

> 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.

Sounds like a fine idea, to me.

> 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.

That should raise some very bold, very large red flags about publishing 
this as an IETF stream RFC.

> 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?

I'm pretty sure I've raised fundamental concerns about this work and 
that those concerns have not been addressed.  The simple summary is that 
the way to restructure this work is to go back to first principles.  But 
there doesn't seem to be any interest in having that sort of discussion.

>     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.

My sense is -- as has become common in the IETF -- an extremely small 
core of folk interesting in promoting this work, rather than extensive 
community interest.

Extensive community interest is what generates serious demonstration of 
utility at scale.


Dave Crocker
Brandenburg InternetWorking