On Monday, January 02, 2006 08:51:20 PM -0800 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
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.
If that's true (and I'm not expressing any opinion as to whether it is),
that doesn't make it a virtue.
Note the change that Russ is making to the charter.
I think a lot of people might be missing a key point about how our process
works. In fact, it's looked that way to me for a while, and so since you
bring it up, I'll try to clear things up for anyone who might be confused.
Please don't think I'm singling you out...
RFC2418 says:
The formation of a working group requires a charter which is
primarily negotiated between a prospective working group Chair and
the relevant Area Director(s), although final approval is made by the
IESG with advice from the Internet Architecture Board (IAB). A
charter is a contract between a working group and the IETF to perform
a set of tasks.
According to my reading of that document, it is up to the IESG whether to
approve a charter, and with what language. Announcement to ietf-announce
and new-work is required; discussion on the IETF list is not. The content
of a charter is determined by the IESG, not by a consensus of the group
wishing to be chartered.
In other words, Russ is within his rights to make changes to the charter he
is willing to bring to the IESG -- especially in a case such as this where
the proposed charter has been discussed so publicly that the rest of the
IESG cannot possibly be deceived into thinking the charter Russ brings them
is exactly the one the DKIM proponents proposed.
This ability to determine what work will be done and under what terms is a
fundamental part of what it means to "steer"; without it, the IESG would
not be much of a "steering group".
In this case, particularly given the comments I've seen from a number of
DKIM's proponents, I feel it is appropriate to constrain the group to
produce a specification for attempting to address a particular aspect of
the spam problem using a particular approach. It's beneficial to apply
constraints like only considering solutions with domain-level granularity,
or only addressing how to _provide_ identity information and not what to do
with it. Particularly given the IETF's previous experience with attempted
anti-spam work, I think such constraints are necessary to narrow the
problem space to one for which a working group will produce something in a
finite time.
Besides being necessary, those constraints are also acceptable because
while they limit _this_ working group to solving one piece of the problem,
there is no implication that other working groups will not be chartered to
work on other pieces. And, while _this_ working group is constrained to a
particular approach, there is no implication that other approaches might
not also be tried. In fact, there seems to be the idea that multiple
approaches could be deployed simultaneously, that doing so would likely be
beneficial rather than harmful, and that developing one approach is likely
to enable or at least benefit work on other parts of the problem.
So far, so good, I think. I'm assuming you agree with me that constraints
such as the one I've described are reasonable; please let me know if that's
incorrect.
What I do _not_ think is reasonable is a demand that the working group be
constrained to produce exactly the protocol proposed, making changes only
if absolutely necessary. If it is to produce a standards-track-quality
protocol, the working group must have the freedom to correct flaws it
identifies and to make improvements, even if not "absolutely necessary".
Of course, it is reasonable to instruct the working group to start with an
existing proposal. It's reasonable to require it to maintain
interoperability with an existing standard, or even to exclude changes to
an existing standard from its scope. But even that must be done with care;
often a good solution involves an extension to one or more existing
protocols.
Note that the XMPP case is somewhat different from this one. In that case,
a working group was formed to "adopt" an existing technology from another
process, and develop an Internet standard. High value was placed on
compatibility with the existing widely-deployed protocol, which is
appropriate and the same treatment we'd give to our own existing standards,
or expect other SDO's to give them.
As I understand it, DKIM is _not_ a widely-deployed protocol developed by
another SDO; it is a proposal developed by a design team with the specific
intent of bringing it to the IETF. There is absolutely nothing wrong with
that approach. However, the normal next step is to bring the design team
output back to a working group, or to the IETF as a whole, and ask for
comments and/or consensus to use the design team's output as input to the
next step in the process.
In this case, it appears that instead of doing that, the design team is
asking the _IESG_ to make the decision that the design team's work will be
used for the next step in the process, without the benefit of working group
or unconstrained consensus. I must confess that I find that behavior
shocking, given how bitterly some of the people involved have complained
about IETF management rushing things through without benefit of community
consensus.
Is there some concern among the proponents of this working group that
without a tight constraint to make only minimal changes to the proposal,
the WG will throw it away and start over from scratch? I understand that
doing so would be a huge waste of time, but given constraints on both the
scope of the problem and the range of solutions, why is a tighter
constraint necessary to prevent the disaster?
Dave, I confess I haven't read to the end of your message, but it's getting
late and I'd like to get up _before_ noon, for a change. Tomorrow I will
finish reading, and perhaps comment on the rest...
-- Jeff
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf