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

[Dave Crocker <[e-mail]>]

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.
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net