Re: bozoproofing the net, was The Value of Reputation

> We seem to have reached a fundamental disconnect about how we
> think consensus decisions are reached in the IETF ...
John, that's not the disconnect.


> I think we find consensus around the IETF by giving plausible
> objections the benefit of the doubt and trying to find middle
> grounds to accommodate them. 
*That* is one of the major disconnects.

We have different views of the word "plausible".

I think the person raising the objection has significant responsibilities to 
make careful and precise statements, including careful and precise 
substantiation.  In other words, they need to make their case and they need to 
participate constructively in a dialogue about their concerns.
Of course, is also considered good taste for them to try to include a proposed 
fix.
I also think that "plausible" needs to be balanced against the risk of stopping 
forward progress, since there is always an infinite array of 
apparently-plausible objections one can make, if one insists on perfection.
Your use of the term seems to be wildly at variance with all of this.



>     I don't
> believe we have ever turned "winning by exhaustion" or "winning
> by intimidation" into virtues, even though those techniques are
Actually we have.

It is used with some regularity by various folk in IETF management, in lieu of 
honoring the requirements of "plausible" that I provided above.  Note the change 
that Russ is making to the charter.

>    I also believe it is far more
> useful to the IETF for us to struggle, together, to find,
> understand, and, if appropriate, adjust to, a sincere concern or
> objection, rather than to simply attack either the objection or
> the objector.
I believe this, too.


> Now this proposed WG has asked for something exceptional, which
I have repeatedly pointed out that the issue is far less exceptional than you 
represent it.
So far, you have never responded to those points.


> is the right to confine its discussions to a particular range of
> alternatives determined by a self-selected design team (no
> matter how much that design team consists of experienced IETF
> folks and has asked for review within the broader IETF
1. Although it is infrequent, there are multiple times that a group has brought 
existing technology to the IETF.  You appear intent on ignoring the pattern of 
choices made to handle such cases.  Instead you seem to insist on invoking the 
"start everything from scratch model" no matter how inappropriate and even 
destructive it might be to the technical work and the group momentum.
2. You express concern that a constrained charter might restrict choice, but 
feel no obligation to give examples of the choice.  Yet a charter is a contract 
and a contract is very much about restricting choice.
3. The "design team" for DKIM now numbers about 25 organizations. Note that this 
"design team" evolved version THREE of an effort that began with Yahoo and that 
that evolution was a full-group effort.  Again, you seem intent on ignoring this 
substantial history of evolution and community involvement.  Better still is 
that you are not proposing any other solution, merely complaining about this one.
4. Any IETF effort can benefit from random input from random folk, but it also 
can suffer from it.  The core of any serious effort has a constituency that is 
vigorously trying to solve a real problem, in a timely fashion.  A requirement 
for the IETF is to *facilitate* this work, rather than to throw up arbitrary 
barriers along the way.  Facilitation might well incur delays, when real and 
significant problems are uncovered.  But the burden of elucidating such problems 
lies with the person raising them.  You seem intent on making vague claims and 
no case to support them, regarding DKIM, and are not responding to the multiple 
people who observe that the problems you cite either do not exist or exist in a 
broad class of technologies that have already been standardized.
4. It has been fascinating to watch some folks attack the DKIM effort with false 
claims that DKIM folk (e.g., me) are unwilling to accept any criticisms or 
variations.  This is so grossly untrue that the assertion seems to require 
willfully pretending that the real record of open-participation DKIM discussions 
on its mailing list does not exist.

> community, the decision-making to this point remains vested in
> that closed design team). 
Wow.

You really have not tracked any of the work done on the open mailing list, have 
you?


>     when the design team then shows up and says
> what appears (at least to me) to be "charter the WG but confine
> to working on our solution, presumably as we define it" then I
> believe that the burden is on the design team to demonstrate
> that approach is safe and consistent with IETF principles.  I
An industry group brings existing technology to the IETF and seeks to have it 
evolved and standardized in the IETF.
Pursuing other solutions might well be a good and appropriate thing to do, but 
it has nothing to do with evolving an existing technology.  Again, you seem 
unable to make the distinction, even though there is plenty of precedent in the 
IETF.
If you want to pursue other solutions, then by all means do.  But please do not 
insist that a coherent and active constituency that is seeking to evolve an 
existing solution be coerced into your (different) effort.
If in fact, you think that DKIM should not be pursued by the IETF, then please 
say so and develop community support for rejecting it.  I'm sure the 
constituency of folk working on DKIM will be quite willing to pursue the work 
elsewhere.

>  Your views, obviously, may differ but, to me,
> the very essence of asking for an exceptional procedure is that
> you justify and demonstrate the safety and appropriateness of
> the exceptions, not that others be forced to prove that they are
> harmful.
Apparently you have not looked at the DKIM spec or the comments from others 
about it.
DKIM uses a collection of extremely well-understood techniques.  The amount of 
real innovation, involving core bits of mechanism, are somewhere between few and 
nil.  DKIM's innovation is in assembling these pieces into a useful whole.
Perhaps you have noticed that a number of other folk -- who happen to have 
little or nothing to do with DKIM -- have also taken exception to your peculiar 
fears about DKIM.
Feel free to respond to their specifics, even if you are not willing to respond 
to mine.

> It seems to me that the IETF also has the right to ask a whole
> range of "what problem does this solve" and, especially given
> the requested constraint, "what value does an IETF WG add"
What part of "I agreed that the original threats analysis work was needed" did 
you not understand?

> questions.  Those questions are, I believe, asked fairly
> regularly of other proposed WGs although the presence of the
Please point out the other working groups that have been required to produce a 
threat analysis before being chartered.

> constraint request has caused them to be asked somewhat more
> intensively this time than usual.   And, again, I suggest that
> it is our precedent that the proposers of the WG need to respond
> to those questions rather than saying, e.g., "unless you can
> identify a technical flaw in our proposal, we are entitled to a
> charter and provisions of our own choosing".  
Please stop raising entirely false claims, John.

Please try to include at least a modicum of reality in your claims.

What you have just described here simply never happened.


> No, I keep "implying" (I've actually tried to be fairly
> explicit) that it is not well-understood what problems this
> proposed protocol solves and what operational side-effects its
> deployment might cause. 
Since the threat analysis document addresses your first concern, you must 
disagree with its contents.  Please provide an explanation.
Since DKIM uses components of technology that are extremely well-understood, and 
since the few usage variations that the DKIM "service" might produce have been 
discussed extensively on the open mailing list, you appear to be unsatisfied 
with results.  Please provide an explanation.

> Again, all I'm asking for here is that the charter include
> requirements for an explicit statement of the problems to which
> the proposed protocol is applicable and for some analysis of the
1. That's not what you have been asking for.

2. Why are you not satisfied with the threat analysis document?

d/
--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf