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

Dave Crocker <dhc@dcrocker.net> Tue, 02 April 2013 19:14 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299A421F8C10 for <apps-discuss@ietfa.amsl.com>; Tue, 2 Apr 2013 12:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwOYW8AJ0PHp for <apps-discuss@ietfa.amsl.com>; Tue, 2 Apr 2013 12:14:51 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D54321F87C3 for <apps-discuss@ietf.org>; Tue, 2 Apr 2013 12:14:51 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r32JEcqZ004050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 12:14:39 -0700
Message-ID: <515B2E1D.4050102@dcrocker.net>
Date: Tue, 02 Apr 2013 12:14:37 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie>
In-Reply-To: <515A2464.8090401@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 02 Apr 2013 12:14:39 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 19:14:52 -0000

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.


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


>> 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
> dmarc.org 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?


> But in any case since that dmarc.org 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.

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.

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


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



d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net