--On Sunday, 01 January, 2006 19:20 -0800 Dave Crocker
<dhc2(_at_)dcrocker(_dot_)net> wrote:
If such agreement cannot be reached, then I think
DKIM has much more serious problems about applicability and
the definition of the problems being solved than whether or
not this is required.
John,
Unfortunately what you appear to be saying is that you are
certain of serious problems, and are happy to assert them as
a barrier to progress -- after all, you want to insist that a
requirement for dealing with your fears be included as a
chartered deliverable -- but you do not feel compelled to
provide a solid basis for these fears.
Before imposing requirements on an IETF effort, one should
make a pragmatic case for it. At base, the case you have so
far made is that the reasonable mechanism of DKIM might get
mis-used, just as any other reasonable mechanism might be.
Dave,
We seem to have reached a fundamental disconnect about how we
think consensus decisions are reached in the IETF and, for that
matter, in other situations. I'm going to try to avoid
characterizing your position, or even what it looks like to me,
because you could quite legitimately complain that I had no way
to understand your internal thought processes. But I can, and I
think should, explain mine.
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. If we can't do so, then we can't.
Then we need to figure out how "rough" a consensus we are
willing to tolerate and either move forward or give up. I don't
believe we have ever turned "winning by exhaustion" or "winning
by intimidation" into virtues, even though those techniques are
sometimes demonstrably effective. 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.
We have both seen, and I believe we have both objected to,
situations in which a WG has said, in essence, "you approved our
charter, and we have done all this work, so you are obligated to
approve our result". I don't like seeing the IETF get into that
position and have proposed remedies for it --including quicker
chartering, aggressive monitoring, and rapid termination of
groups that have gotten off course-- but those ideas haven't
gotten very much traction. So we live with what we have, which
is the notion that conditions that should be imposed on a WG
(along with special freedoms that are to be given to it) must be
in the charter.
Now this proposed WG has asked for something exceptional, which
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
community, the decision-making to this point remains vested in
that closed design team). I think that the use of the design
team to develop a competent and consistent proposal is a
wonderful idea but, 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
don't think the design team, or some of its members, get to say
"we have proposed this exceptional procedure and we are entitled
to use it unless someone can _prove_, to our satisfaction, that
it is harmful". 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.
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"
questions. Those questions are, I believe, asked fairly
regularly of other proposed WGs although the presence of the
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".
You keep implying that it is somehow a mysterious and big deal
to have a voluntary, validated identity associated with
message transit.
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. If those issues were security ones, I
think there would be absolutely no doubt that explanations were
required. But, to the extent that we understand the boundary
between "security issues" and other types of side effects, these
issues are on the other side of that line. But the IESG has
always, at least as long as I can remember such things, had the
right to require an applicability statement for a protocol being
proposed for standardization and to require that applicability
statement cover either or both of the "what problem is being
solved?" question and the "what are the side-effects?" ones.
Those of us who believe that sort of statement should be
required of a proposed WG have three choices:
(i) we can ask that it be made a charter requirement, or
(ii) we can try to get into the WG and argue that it is
a critical piece of work and that that protocol proposal
isn't complete without it, or
(iii) we can wait until Last Call and, if the statement
doesn't appear, argue that the protocol should not be
approved until the A/S is provided.
Taking these in reverse order, the latter would almost certainly
be treated by the WG as the worst sort of "late surprise",
perhaps especially if it came from the community rather than,
e.g., an IESG member who had been suggesting it informally for
some time. The second, it appears to me, could too easily be
blocked by a possibly-reasonable interpretation of the notion
that the existing documents determine the WG's scope.
Assurances by several potential participant-leaders of the WG
that such discussions would not be blocked seem to be to be
somewhat countered by aggressively-taken positions during the
charter discussions that anyone raising any procedurals issues
at all must either prove harm or demonstrate serious technical
flaws in the technical proposal. And that leaves us with the
first option.
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
consequences of applying it in some situations in which it is
not applicable. If the work is worth doing, that should not be
hard. I don't believe that it would be unreasonable for the
community to take a stronger step and require that those
statements be prepared and reach consensus pre-charter but, in
the spirit of trying to let the work go forward, I'm not asking
for that... only that the applicability materials be prepared as
part of generating a proposed standard. If the charter draft
didn't contain an apparent request for a restriction of WG scope
to the content of the materials prepared by the design team, I
would be happy with a strong suggestion now and arguing for the
importance of the applicability materials in the WG after
chartering. But I am concerned that the exclusion might
preclude this entire discussion. I can't _prove_ that would
happen, but I don't believe I am under any obligation to do so,
no matter how many times you repeat that demand or its
variation: if you want this exceptional restriction in the
charter, then I believe it is your obligation to demonstrate
that it is safe and that all relevant issues will be dealt with
openly and appropriately rather than, e.g., having their
proponents shouted or verbally bludgeoned into submission.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf