On 15 April 2014 01:11, Murray S. Kucherawy <superuser@xxxxxxxxx> wrote:
On Mon, Apr 14, 2014 at 3:02 PM, Dave Cridland <dave@xxxxxxxxxxxx> 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/DMARCRight, 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.