Re: bozoproofing the net, was The Value of Reputation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]