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

t.petch <> Tue, 16 April 2013 08:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7773E21F9680 for <>; Tue, 16 Apr 2013 01:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WGTaTgT66vlq for <>; Tue, 16 Apr 2013 01:29:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1577321F9677 for <>; Tue, 16 Apr 2013 01:29:30 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Tue, 16 Apr 2013 08:29:30 +0000
Received: from mail147-ch1 (localhost []) by (Postfix) with ESMTP id 434E42207BA; Tue, 16 Apr 2013 08:29:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zzbb2dI98dI9371I542I1432I1418Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dh8275chz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h)
Received: from mail147-ch1 (localhost.localdomain []) by mail147-ch1 (MessageSwitch) id 1366100967795039_28938; Tue, 16 Apr 2013 08:29:27 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id B53AC3601C0; Tue, 16 Apr 2013 08:29:27 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 16 Apr 2013 08:29:26 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 16 Apr 2013 08:29:22 +0000
Message-ID: <010901ce3a7b$d60eb6c0$>
From: "t.petch" <>
To:, Scott Kitterman <>
References: <><3121454.RJqk1xG6s9@scott-latitude-e6320><><8990489.xAljaCmULD@scott-latitude-e6320> <>
Date: Tue, 16 Apr 2013 09:24:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: []
X-FOPE-CRA-DRYRUN: 1207119;1
Subject: Re: [apps-discuss] Revised 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, 16 Apr 2013 08:29:32 -0000

----- Original Message -----
From: "Dave Crocker" <>
To: "Scott Kitterman" <>
Cc: <>
Sent: Tuesday, April 16, 2013 4:36 AM
> On 4/15/2013 6:35 PM, Scott Kitterman wrote:
> > I think that if a draft is submitted as a candidate working group
work item
> > and the sponsors don't like the result of the chartering discussion
and that
> > draft is suddenly an independent submission, that's pretty well, by
> > an end around the working group process.
> That's the same as saying that when one starts a negotiation, one is
> obligated to make a contract.
> The initial chartering process is a negotiation between those bringing
> the work into the IETF and the IETF community.  Either side is free to
> agree or disagree with whatever terms they wish.
> And free to walk away when there is not a sufficient meeting of the
> minds doing the negotiating.
> The IETF does not have a 'right' to the work that is brought to it.
> The ISE mechanism is for stuff that is relevant to the community, but
> isn't going through IETF or IRTF processing.  As a body of documents,
> the RFC series is larger than the IETF.

There is also the option of documenting existing practice, either via
the ISE or as an Individual submission, as an Informational RFC, with an
IETF Working Group later producing a Standards Track series of RFC of an
evolving specification.  (I have seen two examples of this).

Tom Petch

> Work that is brought to the IETF has different levels of completeness
> and maturity, and different timings for having achieved those levels.
> When the IETF charters a group and includes existing material, the
> charter can cast the role of that material in very different ways:
>       It can treat it as nor more than a set of ideas, to be used or
> ignored;
>       It can treat it as a basic design, with all of the actual
> still fluid;
>       It can treat it as a rough draft, to be massively revised;
>       It can treat it as a solid specification that merely needs
> refinement and maybe enhancement;
>       It can treat it as a deployed technology that should try to
> protect its installed base, but will tolerate some disruption;
>       It can treat it as a deployed technology that /must/ protect its
> installed base and must ensure that core interoperability is retained
> with that installed base.
> No doubt there are some other variations I've missed, but I hope this
> enough to make clear that the choice of language in a working group
> charter, to constrain or not constrain the working group can make an
> enormous difference.
> Equally, those bringing technology to the IETF do so at different
> in the maturity of their work.  Any of the above might make sense,
> depending upon that maturity, the extent of deployment, and the timing
> of the investment made by the installed base.
> When technology is brand new, with at most some prototypes done as
> proofs of concept, then significant changes to the spec won't
> necessarily add much to the development cost.  On the other extreme, a
> mature, deployed market can be almost cavalier about the freedom of a
> working group charter, because a working group that gets silly can be
> ignored: that is, the installed base is sufficiently well-established
> and unified in what it will accept, so that it's leverage is clear.
> However, immediately after the development investment is made -- and
> especially when there has been considerable initial deployment, but
> still room for quite a bit more -- the installed and potential base
> not take kindly to disruptive standards work; in fact such work can
> seriously damage adoption.
> DKIM had almost no deployed base.  Jabber had quite a bit of deployed
> and mature base.
> DMARC has a very large, newly-deployed base that just made the
> investment.  Making any changes that render the base not fully
> interoperable will a) piss of the folk who just made the investment,
> b) possibly sour the folk considering deployment.  It typically at
> causes the potential adopters to delay, sometime for years.
> The charter that was originally submitted was tuned to the reality of
> DMARC's maturity and deployment.  Since that caused so much heartache
> a few folk, the new draft charter removes the base spec from the
> equation.  When deployment settles down and initial investment costs
> have been recovered, it will make sense to review the status of the
> specification.
> d/
> ps.  I'm merely speaking for myself, of course, and not on behalf of
> DMARC consortium.
> --
>   Dave Crocker
>   Brandenburg InternetWorking
> _______________________________________________
> apps-discuss mailing list