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