Re: [apps-discuss] DMARC working group charter proposal

[Barry Leiba <[e-mail]>]

My sense is that this conversation's gotten too heated to shed much
light on things, so I want to try to pull it back into what the issues
are, and away from any sort of attack/defense mode.

I believe that Stephen's issue with the charter involves the
restrictions on what the working group would not be allowed to do with
the proposed DMARC spec.  So let me pick out a few quotes from the
proposed charter (
http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC ) and try to
address that, giving my own opinions on the points:

> DMARC already has achieved significant production deployment. Consequently,
> any changes to the specification that create software or operations incompatibilities
> with the installed base need to be considered carefully.

I think this states a requirement clearly, and it seems to me not to
be very controversial.  It doesn't forbid any types of changes to the
spec.  It does say that some sorts of changes "need to be considered
carefully."  Given that there's significant deployment at this point,
that seems wise.

> The strong preference is for the working group to preserve existing software
> and procedures.

Again, nothing forbidden, but it's clear that we have running code,
and requiring those deployments to roll out new core or new
operational parameters would be disruptive.  It's our *preference* not
to do that, so, again, we need to consider carefully.

> For changes likely to affect the installed base, the working group will seek
> review and advice, beyond working group participants, to include other
> developers and operators of DMARC-based mechanisms.

We have a lot of evidence that comes from development and refinement
of application-layer protocols that, while some implementors and
operators will be here participating, many will not: they have a ship
to run.  They understand that disruptive changes aren't likely, and
they're off doing what pays their bills.

This sentence is saying that if we start seriously considering a
disruptive change, we'll explicitly reach out to such operators, alert
them to what we're considering, and bring them in, asking for their
review and comment.  I think that's an acceptable approach.

> However discussion, debate and resolution of issues that target revision
> of the specification are out of scope for this working group.

This is the only sentence that I have difficulty with, for a couple of reasons:

1. The word "revision" is too broad and vague.  On the surface, it
could mean that *any* change to the specification is out of scope.
There's no point in asking the IETF to work on something for which
that's the case.

2. It puts *discussion* out of scope.  That would arguably include
discussion that could lead to the identification of a major fault or
serious omission in the spec -- a fault or omission that the vast
majority of participants might consider it critical to fix.  If we
can't discuss it, we can't determine whether it's something that rough
consensus is against, something that's a good idea that can be dealt
with later, or a critical problem that needs to be addressed now.

I understand that this is meant to prevent the working group from
becoming bogged down in repeated requests for changes that could and
should be taken up later.  But until we discuss them, we don't know
what category they fall into.  This is why we have chairs, and I would
prefer to trust the chairs to manage the discussion -- and to
appropriately manage people who are bringing issues up for discussion
just to be disruptive.

I strongly suggest changing that sentence so that it gives a more
workable characterization of what's out of scope.


Now, to Stephen:

Again, let's step back and perhaps repeat, but in clearer focus, what
your issue(s) are.  Can you quote specific text from the proposed
charter that you have an issue with, say specifically what your issue
is, and say what you'd like done about it (with specific proposed text
if you can)?

If we state that clearly, and afresh, maybe we'll have a better chance
of moving forward.

Barry