-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good grief.
I don't know that we're changing anything in what the IETF does. What is
happening is that the IETF is growing up and taking control of its own
destiny in a variety of ways, and trying to clean up its own processes. In
all the *other* problems it tries to solve, the IETF tries to say what
problem it is solving sometime before finishing solving it, if for no other
reason so that it can decide whether it did in fact solve it. Same here.
I can't speak for the others who took a crack at a mission statement, but
I'll bet that each would articulate what he was trying to do about the same
way that I do: I was trying to state in a few pithy words what I thought
was important about the IETF. The purpose of the mission statement is to
say what is core - what it is that is so important that if we screw it up
we screwed up. If we tried to describe "what Vernon does all day" and wound
up saying something about wearing a dress, my guess is that we could be
accused of screwing up. If we described "what Vernon does all day" in terms
of having ideas and articulating them, perhaps we hit closer. If we were
trying to figure out processes to ensure that Vernon succeeded in doing
what was important, processes that helped the latter might be more
valuable. Am I close? The same is true of the IETF; hence the question.
I proposed the wording that I did because to me, the most important things
the IETF does include
- discussion of engineering issues in the Internet,
- improvement of understanding of engineering issues in the Internet,
- creating white papers that embody that understanding of engineering
issues in the Internet, and
- creating specifications for protocols that improve the engineered
behavior of the Internet.
Some of the outcomes of the fourth bullet get labeled "standards", because
we agree to call them that and because we agree to implement them, but by
no means do all, and certainly the items on the third bullet don't. The
observation that of all documents that have RFC numbers about 2/7 (1014 out
of 3681) are Proposed Standards, Draft Standards, Full Standards, or Best
Current Practice documents is not a call for more documents. It is also not
a call to archive documents that are not felt to contribute valuable
insights to our community memory. It is an observation of fact. 2/3 of the
documents in the RFC series are *not* specifications. They are discussion
of problems, of architecture, of requirements, and so on. They are the
documents that a purely standards-oriented organization would never pursue,
but which improve our understanding of the subject at hand.
Once we have decided that we did in fact solve the problem before us, I
don't know that the bumper sticker gets us all that much further. But the
bumper sticker can be helpful when we are asking the questions "what are we
trying to accomplish?" and "are we accomplishing it?".
Dilbert may have something to say about it, but I personally am not a
management consultant...
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBQAxi7m4xHWxyLJtDEQK5kQCgkV7NOuJq0UOMu1k4AelJZe0x9bEAn3vD
dsQj42jIjZ4KbZgLRQKQyUGX
=ZcIY
-----END PGP SIGNATURE-----