Re: bozoproofing the net, was The Value of Reputation

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

 





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

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