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

["Murray S. Kucherawy" <[e-mail]>]

Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <[e-mail]> wrote:

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

RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment
that never even ran.  Implementations shipped, but its use on the open
Internet was never detected or reported.  And I had my doubts about the
scalability of the second DNS check that was added to it, but it didn't
seem like it could go forward without.

One that wasn't mine: RFC 6210, an experiment to prove how bad something
can be.

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

Why would the expectations for Experimental be higher than for
Informational?  LMTP is Informational, and it certainly needs to succeed.

> 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.
>
I thought we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of this
back to first principles and separate DMARC from the determination of
Organizational Domain (i.e., make them separate documents) before PSD can
proceed.  Since that will take months, I've proposed a compromise, because
I don't think that's strictly necessary to allow the data collection work
to proceed.  The proposed compromise, then, is to do the work in hand, then
rip the experiment down and apply whatever we learn from it to standards
track DMARC, which is the next milestone.  That will include the separation
of function you proposed, because we agree it's an improvement.  I believe
the set of likely participants in the experiment are present on the list,
and it can be made clear to them that they should have no expectation of
the mechanism it describes surviving past the termination of the
experiment.  So the path forward here comes down to whether the working
group achieves consensus on that compromise, or whether the asserted risk
of the experiment's structure leaking into the permanent deployed base
warrants shutting it down before it starts.

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

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


> 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.
>
That's probably true, but by that argument we should just terminate most of
the email-related working groups because the critical mass we can get today
is a fraction of what it used to be.

Those sorts of existential questions can't be answered at this level,
however.  I would claim the working group was chartered with the
understanding that the participation here won't be like it was for, say,
DKIM, or DRUMS, etc.  We're not in a position to fix that here.  We have a
job to do, and we need to get moving again.

-MSK