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

[Ian Levy <[e-mail]>]

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

I believe I represent one of those participants and I’m happy with Murray’s caution. Experiments will give us data that helps us make better solutions in the future. If those solutions look like the current draft then great. If they don’t then we’ll be changing them based on data and experience.

Surely that’s a good outcome for all??

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
[e-mail]

Staff officer : Tracy, [e-mail] or 07468 837625
Assistant : Rose, [e-mail]

Pronouns : he/him
(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)
________________________________
From: dmarc <[e-mail]> on behalf of Murray S. Kucherawy <[e-mail]>
Sent: Monday, February 3, 2020 6:47:45 PM
To: Dave Crocker <[e-mail]>
Cc: IETF DMARC WG <[e-mail]>; Alexey Melnikov <[e-mail]>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <[e-mail]<mailto:[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
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [e-mail]. All material is UK Crown Copyright ©