Re: DMARC: perspectives from a listadmin of large open-source lists

[Dave Cridland <[e-mail]>]

On 15 April 2014 01:11, Murray S. Kucherawy <[e-mail]> wrote:

> On Mon, Apr 14, 2014 at 3:02 PM, Dave Cridland <[e-mail]> wrote:
>
>> One of the very specific items that was on the proposed charter was
>>> dealing with the question of how to integrate DMARC with mailing lists.
>>> This was called out very early on as an open issue, as were some other
>>> important ones:
>>>
>>> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC
>>>
>>
>> Right, but the WG was expected to make it work with mailing lists without
>> changing it. Tough ask.
>>
>
> Could it not have been done as an extension?  And as I recall, one of the
> proposed paths was to just record and publish DMARC as it is now, and then
> get a WG going to help revise it into something that also resolves the
> questions in the proposed charter, on the standards track.  This also
> failed to gain acceptance.
>

An "incremental and optional" extension which would not require changes to
the deployed software and operational practises. You want an optional
extension which would optionally allow DMARC to traverse mailing lists
usefully when it's optionally deployed? Good one. Can I base it off ACAP?

In fact, I can't find any evidence for willingness to let go of change
control. The closest I can find is a year and a day ago, when you said:

"I'm pretty sure the intent is to publish the current base draft through
the ISE, since it was developed outside the IETF, but if it changes (via
rechartering), move it to the IETF stream.  The latter can obsolete the
former if the timing warrants doing so.  Thus, if the working group is ever
actually cracking open the base draft, it's on the IETF stream."

Note, that's "via rechartering", so the WG was not initially chartered to
change the base spec. The actual proposed charter says it could recharter
in extremis, but that's after two paragraphs explaining why it shouldn't.


>
>
>> Sorry, but given the way in which IETF participants were asked to work on
>> DMARC, there is absolutely no way you could say that the "DMARC people came
>> to the IETF to [...] complete development" - it was more or less stated
>> that development was done and dusted - and the IETF didn't reject it on the
>> basis that no engineering work remained - the DMARC people rejected any
>> engineering work happening.
>>
>> It doesn't actually matter whether you think the reasons behind this were
>> valid; the fact is that you're putting one heck of a slant on recent
>> history, and it's not borne out by what's in the archives.
>>
>
> I remember what was said.  I'm not trying to be revisionist here.  Rather,
> I think I'm trying to remember all the details of a very chaotic
> negotiation.
>
>
Go read the archives. Refresh your memory.


> I can't say I blame the DMARC people, or anyone for that matter, for
> trying to insulate itself against its work being bogged down for months or
> longer rat-holing on things as has been the fate of so many past efforts in
> the same area.  (See the thread Wes George started this morning
> separately.)  Maybe they tried too hard and maybe I even contributed.  But
> I also think maybe the IETF needs to rethink its position on taking on work
> from outside organizations in the first place, which was one of several
> road blocks that came up.  Another is that it was too far along the
> deployment axis to be eligible for consideration as new IETF work,
> regardless of whether the main document was up for revision.  Yet another
> is that despite repeated requests, we couldn't even more than a couple of
> people (I can remember four) to submit substantive reviews of the current
> document; it seemed like the IETF wasn't interested regardless of the other
> "regulatory" issues.
>
>
It's hard to be interested in doing IETF work on something that wasn't
managed by IETF process, or IPR rules, and was actively marketed as being
done, deployed, and not subject to further change. "Please review our
specification so we can ignore your comments and rubber stamp the result"
is not a tremendously attractive proposition.

I suspect that had the IETF been involved considerably earlier, none of
this would have happened. I'm not really sure how this could have been
fixed, as I've noticed a strong tendency amongst organisations which
control large proportions of the deployed market to assume that minority
viewpoints do not count. The "60% of all mailboxes" fanfare is an example
of this. I've seen similar from browser vendors in WebSocket, and I've no
doubt that the major router vendors play the same card with BGP et al.

Some of this is understandable - expertise and experience do tend to pool
at such organisations - but increasingly I feel that we've lost sight,
somewhere, that - for example - because 60% of the world's mailboxes are
handled by the DMARC cabal, that still leaves 40% who may have somewhat
different needs and requirements from the protocol. Given the expense and
difficulty of IETF participation for smaller organisations and individuals,
it's hard for them to club together and stand up to the 8000lb gorillas.

DMARC is not an IETF standard - you know this, I realise - but there was no
sense from the messages exchanged a year ago that it ever would be an IETF
product in anything more than - perhaps - name.


> I don't have any idea how to retroactively fix all of that, and I suspect
> it would be another rat-hole to try.  What I'd really like to talk about is
> where we go from here.
>
>
It really depends on whether the 8000lb gorillas are open to letting go of
the change control or not. A year ago they clearly weren't.

Dave.