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

Alessandro Vesely <vesely@tana.it> Tue, 04 February 2020 18:27 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172A3120856; Tue, 4 Feb 2020 10:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 5VF8VjcvXiCH; Tue, 4 Feb 2020 10:27:28 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 B7F8E120877; Tue, 4 Feb 2020 10:27:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1580840838; bh=2YTq9WeQhz0w+PEcl84TBEvvDrRSz3z7xCYEdZxs/VA=; l=3726; h=To:References:From:Date:In-Reply-To; b=DYarfcofV5pS00L8KXKfEvMHbRsku7qApeygtg0ev9kUcS+aozUCoSzRDXyseGZ3y iSP7HIM9Vu/dqZ5xRGmdA0vrdlojKoq5fCNtW8sewKWgBMy+1Nyk1B8/SiifYJB7TO V3DlZ9UzmgaMunPqAGEIatWh17t4H5Lfm9g2cQgckKORvA4YxjMQNG6ct8kUs
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005E39B786.00003F23; Tue, 04 Feb 2020 19:27:18 +0100
To: dmarc@ietf.org, dmarc-ads@ietf.org
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwacbAT04tckpPcRcnOt=1QByOBeJ7uDf6rNK6NRwtxZYg@mail.gmail.com> <ffa2bf72-3024-237b-86ae-9cc04babeec6@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <CAL0qLwbp2hNrgF_xxhKRRODQ6HP=U5_K-r3Wtm1wJZOZcKup3g@mail.gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <CADyWQ+GSP0K=Ci22ouE6AvdqCDGgUAg3jZHBOg3EwCmw=QG84A@mail.gmail.com> <CABuGu1obn55Y2=CuEYRYCEO3TYYNhYTsdkesQ67O61jRyfO=wA@mail.gmail.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <CAL0qLwZnomZJTbFB=dfFdw2vWg7B0ObRuoage3pcWaYmP9Kp4A@mail.gmail.com> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <CAL0qLwZjd2qhejctNK0BM7j=SscaE45Mm7U9iWJNvO-GuhEKQA@mail.gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> <CAL0qLwY-v-VS-Wai-aqGRPOj1i8HxqMrYybzsNJGzN2dTHvG9w@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <01e149da-3ff6-7e91-d815-d79316f53d58@tana.it>
Date: Tue, 4 Feb 2020 19:27:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwY-v-VS-Wai-aqGRPOj1i8HxqMrYybzsNJGzN2dTHvG9w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1g-HRlSNSvXAmyTNjlgs4jzN-To>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2020 18:27:31 -0000

On Mon 03/Feb/2020 19:47:45 +0100 Murray S. Kucherawy wrote:
> 
> Now, to the working group as a whole:
> 
> The chairs note that we have a duly and properly completed WGLC in hand. 
> Still, Dave's concerns have validity, so they need to be considered by the
> working group.  Since we need to do *something*, we are now putting the
> question back to the working group, and we need to see some answers.  The
> chairs will not accept hearsay replies or opinions, or expressions of needing
> this work but not knowing how to engage; you either give your feedback on the
> list or privately to the chairs or Area Directors, or you are along for
> whatever ride results.  Please indicate, as soon as possible, where your
> support lies given the above.  We're not going to let this go additional months
> (probably not even weeks) without progress in some direction.


I support publishing draft-ietf-dmarc-psd as is.

As I wrote already, I appreciate Dave's narration and think it can lead to a
better overall statement of DMARC.  However, I don't think it suggests any
practical software technique that may improve [PSD]DMARC implementations in the
short term.


> I will also say for the record that we don't find compelling the assertion that
> resources will not be dedicated to the experiment absent a document in the RFC
> Editor queue.  That constraint is fully external to the IETF, and it will carry
> no weight in the decision made here.  It should indeed be possible to run an
> experiment based on a document in any state at all.  We're entertaining
> publication not because it must happen, but because that action (currently) has
> consensus, and it's our job to act on consensus.


There are a number of ICANN liaisons mentioned in IETF website[*].  I think it
is their, or at least some of them's, duty to inform the relevant ICANN
authority about the experiment, so that they can allow it to proceed, as soon
as draft-ietf-dmarc-psd enters the RFC Editor queue.  Will Area Directors
please advise them?

NOTE: The provision to publish _dmarc resource records, or whatever selection
of registered underscored node names[†], under selected global TLDs is *not* to
be considered ephemeral.


[*] https://ietf.org/about/liaisons/
[†]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names


> Dave also made an additional observation, that experiments expected to fail are
> not generally what the IETF produces.  I would quibble some with that wording:
> The working group doesn't expect the experiment to "fail", but rather expects
> it to be ephemeral.  Were we to refer to chapter-and-verse, there's nothing in
> RFC2026 (which defines "Experimental" as a document status) that precludes what
> the working group appears to be trying to do here.  As for whether the IETF
> generally should produce an Experimental document describing something
> ephemeral, I would claim that a working group or its chairs are below the pay
> grade where authoritative claims like those are made; it's the kind of thing
> about which the IESG makes proclamations.  Accordingly, I've Cc'd our current
> Area Director to see what he thinks might happen if we were to send this up,
> and give him a chance to provide guidance in case that's the decision (but we
> won't wait long for that either).


I don't expect the experiment to fail.

What seems to me to be ephemeral is its providing for three different
services[‡] to determine which TLDs deserve an extra DNS lookup.  The
experiment will hopefully determine which one(s) are fit.


[‡] https://psddmarc.org/



Best
Ale
--