Re: bozoproofing the net, was The Value of Reputation

On Monday, January 02, 2006 08:51:20 PM -0800 Dave Crocker 
<dhc2(_at_)dcrocker(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf