Working Group chartering

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

 



Jeffrey,

(I have changed the subject line, so that this discussion is explicitly NOT about any current IETF chartering activities. I hope folks will not take my comments as having any implication about any of those efforts or discussions about them...)


I think a lot of people might be missing a key point about how our process works.


What makes things particularly challenging is the difference between Procrustean attention to documented rules, versus applying them in an integrated manner with subjective assessment of the pragmatics of being productive. Any organization that strictly resolves disputes based on the letter of its laws quickly alienates is workforce.

When we wrote the rules regarding chartering, the intent was to have the cognizant AD conduct whatever discussion were needed to create a working group that would be productive. This is inherently a fuzzy process, so it was -- and remains -- important to avoid over-documenting the procedure.

For example, an AD who entirely ignores the concerns and desires of those who will do the bulk of the work risks having a working group without workers.

The pragmatics, therefore, require the AD to try to juggle various political, technical and project management concerns, and put forward a charter that they feel will offer the best chance at productive working group output.

Frequently -- maybe usually -- this is primarily through a private dialogue among those who will form the small core of the working group effort, including likely chairs. However it is not uncommon for a public dialogue to be conducted. For example, a BOF usually includes a review of candidate charter text. That the open group's consensus is not binding on the AD merely indicates the delicate nature of chartering, rather than the irrelevance of that consensus.


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".

Actually, this highlights why "steering group" is exactly the wrong term for the IETF process management team. They do not initiate work and they are not primary contributors to that work. Hence, they do not really "steer" anything. When the IESG tries to act like it does, they often find no workers and a mass of dissatsfaction.

The job of the IESG is to facilitate the initiatives of others and to ensure enforcement of useful quality assurance.


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.

all of the above is nicely said, as comments about a class of working group startup efforts.


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.

And here is where we have the major disconnect.

Working groups start from a wide variety of places. Some start with an idea. Some with a detailed proposal. Some with a detailed specification and some with existing and deployed technology. When a working group starts, it must make the strategic decision about how much prior work to preserve, versus how much new work to encourage or require.

There are obvious and significant trade-offs in this choice. What is essential is that the trade-offs get serious consideration and that the choice be appropriate to the particular situation. It absolutely is NOT true that all chartered working groups must be allowed to throw away any and all prior work. The loss of invested community effort and the loss of momentum would be disastrous.

At the least, an effort that seeks to use existing technology needs to explain clearly and convincingly what needs to be preserved. Equally, any efforts to deny the stability of re-using that work must make a compelling and concrete case for the changes that are needed.


Note that the XMPP case is somewhat different from this one.

Remembering that this new thread is about a general issue, rather than debating a particular working group effort, I'll comment on the particulars of your reference:

  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.

Jabber did not come from another SDO. Even if it had, I fail to see why that imparts special status. DKIM came from a substantial -- albeit informal -- industry initiative with quite a few organizations participating. Nothing about Jabber's or DKIM's origins automatically make the technical quality of the work good or bad, or necessarily of interest to the IETF.

(Well, ok, I'll indulge in a particular, in order to correct a factual error: Mis-statements about DKIM's deployed base have been corrected quite a few times. Suffice it to say that your understanding is incorrect.)


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.

(Damn. Have to correct another one: I have been boringly pedantic about citing the TWO rounds of OPEN, online consensus effort surrounding the draft charter. This was not a tiny cabal or even a larger, albeit closed, group or organizations. The draft charter text was produced by a highly open and responsive process over the course of months.)


d/
--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

_______________________________________________

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]