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

[Scott Kitterman <[e-mail]>]

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?

Scott K