On 15 April 2014 01:11, Murray S. Kucherawy <superuser(_at_)gmail(_dot_)com>
wrote:
On Mon, Apr 14, 2014 at 3:02 PM, Dave Cridland <dave(_at_)cridland(_dot_)net>
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.