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

[Stephen Farrell <[e-mail]>]

Hiya,

On 04/05/2013 05:15 PM, Barry Leiba wrote:
> 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.  

Yep.

> 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.

Considered carefully seem entirely reasonable. But I think following
the template from dkim/xmpp here would however better characterise
when changes would be ok. To repeat from PSA's mail the xmpp text
was:

   Although not encouraged, non-backwards-compatible changes to the
   basis specifications will be acceptable if the working group
   determines that the changes are required to meet the group's
   technical objectives and the group clearly documents the reasons
   for making them.

Incorporating the above might mean more wordsmiting than a simple
replacement but shouldn't be hard.

>> 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.

I quibble with the above. There's no working group that exists to
have such a preference and the above text seems to me to indicate
a lack of distinction between the proponents of this draft charter
and an eventual WG which will inevitably involve people that are
not currently involved in dmarc. The text however should be easily
fixed, e.g. replacing the above with something like:

"Preserving existing software and procedures is preferable."

But I think the dkim/xmpp template does that already and better.

However, I could live with the current text if the other changes,
or equivalents, are made and nobody else has a problem with this
part.

>> 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.

I'm uncomfortable with the above text but fine with the sentiment.
The problem with the text is that it seems to allow a WG participant
to say "I've asked someone I know who deploys DMARC but is too busy
to be here and they say you're wrong." Having that as a winning
argument according to the charter seems to me to be problematic.
I'd suggest something like:

"For changes likely to affect the installed base, the working group
need to carefully consider the views of developers and operators of
DMARC-based mechanisms."

But yet again the dkim/xmpp template text seems better to me.

>> 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.

I agree with Barry's comments on this part. I think that sentence
would be better deleted with no replacement.

> 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.

I hope that that's clear from the above.

S.


> 
> Barry
>