(What follows makes no comment on the appropriateness or efficacy of the
recent expansion of DMARC usage. Rather, what follows comments on the
discussion within the IETF about it.)
One of the problems with reactive policy development is that is tends to
be driven more by emotion than actual principle. Rationales tend to be
convenient, rather than careful.
What results starts to look more like Procrustean, religious dogma,
rather than pragmatic technical consideration. As a community
developing technical details, the IETF has a good track record. As a
religion, no to much.
So we are seeing some odd claims...
(2) I believe it is unacceptable for a new protocol or
capability to impose costs on operators of other systems in the
absence of clear and broad consensus about why the changes are
needed and appropriate.
1. Protocols do not impose costs. Some /uses/ of them might, which
is the choice of those deploying them to that effect.
Used in the original scenario for which it was developed, DMARC
only imposes costs on those choosing to adopt it. That largely remains
true even for the expanded application we've just seen. Those most
affected are users of operators choosing to expand the usage of DMARC.
2. There is nothing that requires mailing lists to make adjustment.
Arguably, it is better for mailing lists NOT to make adjustments, so
that those affected users can consider the efficacy of their current
account.
3. The discussion here is consistently confusing the difference
between the protocol, DMARC, versus some recent applications of it, and
confuses the work of dmarc.org with the independent decisions of
specific email operators.
Further, note that the problems with the recent uses were
extremely well-understood beforehand. In other words, those making the
recent usage choices did so aware of the implications. The IETF has no
obvious leverage over operational organizations that make such decisions.
So? Perhaps we should be focusing more on strategies that
weaken DMARC to the degree necessary
This postulates a power struggle between the IETF, versus those deemed
by the IETF to be misbehaving. It's difficult to imagine the IETF being
effective with such an approach.
DMARC did not
emerge, full formed, out of the void. It's the logical
evolution of ADSP, a standards-track IETF protocol.
A standards-track IETF protocol that was deprecated by a process
that claimed it was unused and harmful. If it had been the
intent to replace ADSP with an IETF-developed DMARC, that would
properly have been handled by submitting the DMARC specification
Perhaps folk should review Thaler's RFC 5218, What Makes for a
Successful Protocol? In effect, it documents that (at least recent)
IETF successes primarily come from efforts that began outside the IETF.
So the DMARC effort derives from significant prior IETF work and, by the
way, was subject to an effort to bring it into the IETF.
The core problem with the considerable effort made at bringing DMARC
into the IETF was that, in spite of repeated efforts in multiple venues,
there was no consensus developed in the IETF about technical work to do.
Also note that a draft BCP was posted, has been repeatedly referenced,
and yet folk seem more intent on complaining about DMARC than working on
practical documentations like the BCP.
I don't recall saying anything about "out of the blue". All
I've asserted is that DMARC itself was not developed within the
IETF, using an open process, was not approved via an IETF
consensus process, and that the IETF does not have change
control over its evolution.
Now, if dmarc.org wanted to turn the protocol over to the IETF,
give IETF change control, and propose it for the standards
track, we would be having a different discussion.
What a wonderfully revisionistic assertion, given that such an effort
was made, over a six month period.
And to anticipate the inevitable fault-finding responses, please
consider whether it really is unreasonable for operators having made
recent and substantial investments in deploying a new technology to
resist a demand that they encourage a de-stabilizing change process that
imposes no constraints on what can be changed or why.
Further revisionism happens when it is claimed that the IETF doesn't
accept new technology that comes with constraints on changes permitted
for the initial IETF work on the technology.
That sounds like yet another instance of the not-invented-here
syndrome. FWIW, much the same solutions were put forward for
ADSP. IETF or non-IETF, the difference seems to be that DMARC
currently has more traction and deployment than ADSP ever had.
No, it is not NIH. It is that the IETF has no change control
over DMARC and hence does not have the option of controlling the
damage by withdrawing or adjusting the protocol itself.
The curious premise to this claim is that the IETF's 'withdrawing' a
protocol carries leverage that will cause major operators to stop using
it, independent of those operators' own assessment of efficacy.
There's also the ironic theme running through this thread that the IETF
doesn't do normative work relating to specifications it does not
directly control.
The irony within this thread, of course, is unicode. Other examples
about, but that one is particularly amusing.
Let me make explicit it is not consensus on DMARC we're
talking about. It is consensus on the workaround and the
demonstration.
And I am suggesting that, if you want to initiate a proposal for
work on damage control wrt DMARC, nothing prevents you from
proposing that as a work item for some existing WG or a new WG.
+1
Except that that point seems to contract some of the others made in this
thread, by the same speaker and possibly even in the same posting...
Again, from my perspective, the question is whether the IETF
actually has responsibility for protocols for which there has
been no effort to obtain IETF consensus
Again, that's not correct.
There's real technical work to be done in this space. It's probably not
as much fun as complaining about the situation, but it would be quite a
bit more useful for the community.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net