Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin

[Barry Leiba <[e-mail]>]

Scott, I'm clumping bits from a few of your messages in this thread
into one reply; I think it'll make it easier.

>> An initial version of the draft was posted as an I-D.  The sponsoring AD
>> has pressed for a number of reviews to be done.  An initial set were
>> done and came back calling for some significant editorial changes, but
>> no technical changes, essentially to make the document better to read.
>>
>> Let me repeat:  better writing; no technical changes.
>
> I disagree.  I've been saying repeatedly that I think that the policy
> overrides are a layering violation that should be removed.  They are bad
> design.

Repeatedly?  I've just re-read every message you've posted to this
mailing list, and I see none in which you've said this, none in which
you've done a review of the dmarc base spec document, and several in
which you've said that you're using dmarc and are supportive of it.

I'm sure you think there are things that should be changed.  The best
way to suggest that is to do a review of the document, to post it
here, and to be specific about what you want to see changed.

> I'll add to that that having watched senders try to interpret XML reports they
> receive from different providers and understand the subtleties between them
> that while the mechanics of the XML schema are there, the semantics are not
> clear enough to provide for interoperable implementations.  Even among
> implementers who have worked together in dmarc.org to develop the schema,
> there are inconsistencies.
>
> I don't think there is anything in the two issues about that would force
> existing implementers to make changes, but I think that they are not purely
> editorial either.

Excellent; put an expansion of that into a review, making sure that
it's clear about what the problem is and what, specifically, you want
to change.

> Personally, I'm getting tired of investing time in it.  It seems like the only
> response to comments amounts to "La La La La, I can't hear you".

This and statements like it don't seem to be fair: I see no evidence
that anyone is unwilling to listen to comments (from you or anyone
else).  Responses might disagree with you, and people might think that
changes you want made should not happen... but that's technical
disagreement, not refusal to listen.

In any case, I haven't see any real opportunity to discuss what issues
you might have with the dmarc protocol, because I haven't seen you lay
those issues out clearly so they can be discussed.  Please do that.

Really: please do that.  Please don't get tired; get specific.

> I agree that it seems the needed changes are unlikely to affect the installed
> base.  My concern is that the plan appears to be an AD sponsored base
> specification with maybe a working group to address the BCP and potentially
> other things.

Whether the base spec is AD-sponsored or handled by a working group
isn't going to affect the quality or depth of review that I'm going to
insist on.  The dmarc spec will not become an IETF Standards Track
document without a good deal of thorough review, discussion and
changes where that's necessary, and significant support for putting it
on the Standards Track.

The path of AD sponsorship is happening because there was difficulty
in converging on a charter that included the base spec (see the
discussion on the apps-discuss list about that).  Such a working group
is still not out of the question, but the level of technical work that
appears to be needed for the base spec is very low -- that's what
makes it reasonable to AD-sponsor it if the community gets behind it
with review and discussion.

In this post: http://www.ietf.org/mail-archive/web/dmarc/current/msg00184.html
...you say this:

> I'm not certain what the best answer is, but I think that at least getting the
> spec to say you can publish p=none and not affect existing behavior is very
> important.  Unfortunately, there's no venue to discuss updating the base spec.

*This* is the venue to discuss updating the base spec.  Clearly, those
who have deployments of dmarc don't want to see changes that will
affect their deployments.  That said, there's no restriction on what
aspects of dmarc can be discussed on this list.  You want to propose
changes, do as I said above: post a review of the document and be
specific about what you want to see changed and why.  And then
participate in the discussion that ensues.  Scattered comments in
other threads that give very brief mention to issues you have are hard
to follow, hard to get into real discussion of, and hard for editors
to track.

Barry, Applications AD