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