Re: The IETF Mission

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

 



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



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