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

Stephen Farrell <> Tue, 02 April 2013 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFEBF21F8D2D for <>; Tue, 2 Apr 2013 13:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jogH7sQn0TkR for <>; Tue, 2 Apr 2013 13:31:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ADD4521F8D3C for <>; Tue, 2 Apr 2013 13:31:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED586BE25; Tue, 2 Apr 2013 21:31:25 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Si4HFF7CpeHp; Tue, 2 Apr 2013 21:31:24 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 2F918BE24; Tue, 2 Apr 2013 21:31:24 +0100 (IST)
Message-ID: <>
Date: Tue, 02 Apr 2013 21:31:23 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Apr 2013 20:31:49 -0000

On 04/02/2013 08:14 PM, Dave Crocker wrote:
> Stephen,
> On 4/1/2013 5:20 PM, Stephen Farrell wrote:
>> On 04/02/2013 12:17 AM, Dave Crocker wrote:
>>> DKIM had far less installed base on large operational services than
>>> DMARC now has.
>> Happy to hear that but I don't think it impacts on the
>> points below. (Its news to me btw, but then its not my area
>> so that's not surprising.)
> If affects the chartering issues fundamentally, as I've explained.

Sure. But not these specific issues IMO.

>> And to be clear: I do welcome folks bringing work to the
>> IETF, esp. where it is or will be widely deployed.
> Good to hear.  Perhaps you'll therefore consider being less terse,

Terse is good I've found when dealing with folks who might
misinterpret extraneous words.

> precipitous and simplistic in your responses then?
> Really, Stephen, the way to encourage folks is to encourage them, not to
> post initial responses that are as dire as you've done.
> Being encouraging doesn't mean saying yes to everything, but it does
> mean working to understand what they want to do and why and offering
> specific suggestions that go beyond "do it the way we've done it before
> or go away."

Precipitous, simplistic and dire seem to me to be purely
pejorative terms. I don't think they help.

>>> As for not knowing how to consult outside the working group, surely you
>>> jest.  We do it all the time.
>> Not with such vaguely characterised "others" and nor with
>> giving 'em anti-change-control that I can recall. Feel free
>> to point me at examples that do those things. If the text
>> isn't meant to severely constrain IETF change-control then
>> it needs a re-write 'cause it reads to me like that's the
>> intent.
> Ahh, so your concern is not what you originally stated, but is more
> nuanced.  Excellent.  That's worthy of discussion.
>> If the "others" are actually well-known and are really
>> members then saying that would seem to be
>> useful to start with.
> Clarifying who should be consulted and how could make complete sense.
> How is it that the existing draft text "other developers and operators
> of DMARC-based mechanisms" is not sufficient"?  What would you suggest
> as better?

Best is if those who want to influence WG consensus get involved
in the WG. I can buy that not everyone has time though, but not
that some WG participants are allowed get away with "I consulted
with my unspecified friends and they don't like this proposed
change, so the charter says you can't make that change." The
current text seems too close to the latter IMO.

Again, the approach that worked for DKIM and XMPP seems to me
like it'd be fine.

>> But in any case since that group apparently want
>> to cede change control then I think DKIM-like charter text
>> is really what'd work best.
> You (and SM) are confusing the difference between handing over change
> control, versus the permissible scope of work for the first effort, that
> is negotiated as part of the hand-over.
> This is a balancing act, every time work is brought into the IETF.

I agree its a balancing act, and disagree that I'm at all confused.

> It depends upon the maturity of the technology and the nature of its
> deployed based, as well as the list of work the community believes needs
> to be done.

"the community" could mean the existing or the putative
WG. It seems to me that the confusion (if any) is that those
are being conflated - they're clearly closely related but not
the same.

> For example, if you or anyone else has specific work to propose, then
> let's talk about it.  As part of the planning for bringing DMARC to the
> IETF, We did this within the group. We knew it's better to
> bring more 'interesting' work items to the initial round of effort in
> the IETF.  Unfortunately, we didn't see technical development tasks for
> the protocol that are needed right now.  Perhaps you or others do?
>> If really don't want to cede change control then
>> the ISE route would seen more appropriate than an IETF WG.
> You appear to think that ceding change control means that the working
> group charter must impose no constraints on the scope of what is
> permitted by the initial working group charter.  

Nope. The charter can describe any technical constraints and that's
perfectly reasonable, assuming the charter text gets agreed etc.
Doing new process innovations that change how WG consensus is judged
in the charter isn't the same thing. I think the current text seems
too close to the latter.

Yet again, what worked for DKIM and XMPP seems fine to me.

> That's not the history
> of charters for existing work that's (eventually) brought into the IETF.
>  The permitted types of changes -- and possible disruption to the
> installed base -- are an inherent part of that initial negotiation, each
> time.
>>> As for:
>>>> I don't know how the not-yet-formed WG can have a preference
>>> I don't know what you mean.
>> WG-doesn't-exist-yet => WG-can't-have-opinion. That ought be
>> trivial to fix, but is indicative of a possibly problematic
> I do not know what language your are reading that asserts preferences
> for the not-yet-formed WG.

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

>> conflation of the set of folks who drafted this text and the
>> set of folks that might participate in a future IETF WG, which
>> will include people who've never seen this draft for example.
> Huh?  Again, I don't know what you mean, and your terseness about a
> potentially serious point isn't helping.


> General request, Stephen:  Rather than tossing off this sort off terse,
> dire assertions, please invest some effort into explaining what you mean
> and what the basis is.

Terse != dire:-)


> d/