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

[Scott Kitterman <[e-mail]>]

On Monday, February 3, 2020 1:47:45 PM EST 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.

Personally, I think Dave is wrong.  I think he's given an assertion, but 
nothing beyond that.  Given that DMARC has been successfully deployed at scale 
depending on a list (PSL), I believe that's an adequate existence proof that 
Dave's assertion that anything depending on a list can't scale is not correct.

Dave's claim that the IETF hasn't done anything depending on a list may or may 
not be correct, I don't know, but that's not a technical point.  If the IETF 
was stopped by "we haven't done this before", we wouldn't have much of an 
Internet today.

That isn't to argue using the PSL to find the org domain is a technically clean 
solution.  It's not.  It's only less horrible than the alternatives.

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

I think the IETF tells external organizations not to use I-Ds [1], so I don't 
really understand this point, but I don't think it affects consensus much.
> 
> 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).

It won't surprise you to find that I support publishing the draft substantially 
as is.  I believe there are some open questions described in the experimental 
portions of the draft that will take some operational experience to evaluate 
and having a stable reference will be useful for that purpose.

As a side note, I don't think this is anywhere near the most extreme 
experimental document that IETF has considered for publication.  The Sender ID 
RFCs conflicted with current Internet Standards and were still published even 
after an appeal on that point.  Having just re-read the IAB response to that 
appeal [2], particularly Section 3, I'm even more convinced that the DMARC PSD 
draft is well within the realm of what's appropriate for an experimental RFC.

Scott K


[1] https://ietf.org/standards/ids/
[2] https://www.iab.org/appeals/2006-2/iab-response-to-appeal-from-julian-mehnle-2-march-2006/