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

["J. Trent Adams" <[e-mail]>]

On 4/15/13 9:58 PM, Scott Kitterman wrote:
> On Monday, April 15, 2013 08:36:20 PM Dave Crocker wrote:
>> 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
>>> definition, 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.
>>
>>
>> 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 details
>> 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 review,
>> 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 is
>> 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 points
>> 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 will
>> 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, and
>> b) possibly sour the folk considering deployment.  It typically at least
>> 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 to
>> a few folk, the new draft charter removes the base spec from the current
>> equation.  When deployment settles down and initial investment costs
>> have been recovered, it will make sense to review the status of the base
>> specification.
>>
>>
>> d/
>>
>> ps.  I'm merely speaking for myself, of course, and not on behalf of the
>> DMARC consortium.
> In this case it's more like announcing a lockout when the initial offer from 
> management isn't accepted without modification by the union rather than 
> determining a meeting of the minds cannot be achieved after good faith 
> negotiations.
>
> 1.  How about this?
> 2.  Not quite, here are some alternatives we could discuss.
> 1.  I quit.
>
> that's hardly a negotiation.
>
> Your argument against a working group is that it will be hard to get people 
> who have adopted DMARC already to implement interoperability improvements 
> because they just implemented it.  Are you suggesting that it will be easier, 
> later, when there is more deployment and the current pattern is better 
> established?

Yes, in this case it's likely that will occur. I can't speak to
everyone's development pipeline, of course, but in my experience
moderate to large enterprises require months and years of planning. The
most reasonable architects I've known include upgrade paths during
initial planning which address exactly what I think you're describing.
They'll be planning their solution based on current knowledge (ie the
existing spec) with a mind toward something like a two-year upgrade to
whatever the extensions (or possible revision) may be.

Another way to look at it is that since there's real value seen in
deployment today, there's a counter-incentive to wait an indeterminate
time for a possible revision. Each day that passes is another day that
customers are being phished... and, sadly, each phishing attack is yet
another opportunity for a cascading set of casualties (think: spear
phishing a whale).

I'm pretty sure we all agree that perfection can be the enemy of the
good. Getting a stable, useful, though possibly sub-perfect, solution
running is a reasonable path toward iterative improvement. Yes, it'll
take time to correct the ship under full sail, but it's possible (and
likely).

I'm all for learning as we go. Let's buckle down, explore some of the
key focus areas identified as possible (non-disruptive) extensions for
now and see how they play. Through that journey we will also learn what
needs to be done to improve the base and be the stronger for it.

Hoping for a brighter future,
Trent

>
> Scott K
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams