Plenary decision?
Hallam-Baker, Phillip
pbaker at verisign.com
Fri Jul 11 10:24:52 CEST 2003
Oops, sorry, I suddenly realize that I had misread the start of Ted's post
to be the opposite of what he intended.
My appologies.
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso at mit.edu]
> Sent: Friday, July 11, 2003 10:36 AM
> To: Hallam-Baker, Phillip
> Cc: 'problem-statement at alvestrand.no'
> Subject: Re: Plenary decision?
>
>
> On Fri, Jul 11, 2003 at 05:32:38AM -0700, Hallam-Baker, Phillip wrote:
> > I seem to recall raising the issue in a plenary. At no time was I
> > aware that the plenary was the decision maker for the issue in
> > question.
> >
> > This was I believe because of your reply 'There is a process", I
> > remember that part of the reply because you neglected to say what
> > the process was.
> >
> > So here we are in this forum and I find out that oh, the
> plenary was the
> > decision making body!
>
> Phill,
>
> First of all, thank you writing a much calmer and much more thoughtful
> e-mail.
>
> It may very well be that that the IETF has grown too large for our
> earlier, more informal mechanisms of governance. Just as in working
> group chairs have the power to determine rough consensus, and are
> charged with making good decisions about when there is rough
> conensensus, and when people are raising technical objections of the
> form, "it can't possibly work", versus "there are engineering
> tradeoffs here, and I happen to strongly prefer door A over door B"
> (where objections of the first kind must be taken care of as opposed
> to objections of the second, which you try to reduce but ultimately is
> not reduced down to zero because "rough consensus" doesn't mean
> unanimity), at least in my view of the world, that's what the IESG is
> charged with doing, on a larger scale for the entire IETF.
>
> This should be nothing new; it's in the TAO of the IETF, and in the
> newcomer's briefing, but since you seem to be have some doubts about
> what the process is, I thought it would be put it out explicitly.
>
> For questions like whether or not we use non-ASCII documents
> exclusively, currently, the process is the RFC Editor decides, with
> strong input/direction coming from the IAB and the IESG. On the other
> hand, if they don't respect the community consensus, there are many
> checks and balances, including (a) throwing the bums out, (b) the
> appeals process, (c) simply going to other standards bodies.
>
> That being said, the topic of non-ASCII RFC's comes up every couple of
> years, and at every IETF plenary that I can remember, the number of
> people who come up to mike who bring up advantages of ASCII and
> disadvantages of other formats generally run about four or five to one
> in favor of ASCII. So I would argue that given the current decision
> making process, the IESG did absolutely right thing. Furthermore,
> even if we believed that democracy was a magic wand that automatically
> produced technically superior standards, it seems pretty clear that
> ASCII would probably win out.
>
> > If the plenary is a decision making body as you are
> implying then why does
> > it keep no minutes?
> >
> > It is possible that Harald is correct in his assertion, but
> I find no
> > record in the minutes because there arn't any.
>
> It is not a decision making body, but it is the best way of measuring
> the general consensus of the community. Currently, we don't take
> minutes, but rely on memories and the IESG to judge that consensus.
>
> Your complaints about the IETF's about process, and who are the
> decision-making bodies, and your accusations of ruling cliques I think
> goes to the heart of the matter, which is fundamentally one about how
> we govern ourselves, and whether we should be using a very formal
> process, or an informal one.
>
> I view this as an engineering tradeoff. There are certainly
> advantages in using a very formal, structured meeting format where
> decisions are made via votes and minutes and Robert's Rule of Order.
> There are also advantages to using a system of judging rough consensus
> and an appeals process as a check and balance. Both schemes also have
> their disadvantages.
>
> Some people feel much more comfortable with standards bodies that use
> a very formal process. Others have noted that in the past, bodies
> that have gone down this past have sometimes gotten mired in
> bureaucracies, and result in people (and large corporations) who are
> really good at manipulated said process, but who are not necessarily
> good at producing good technical results. Certainly there was a time
> when our lightweight decision-making process was compared favorably to
> the process used by ISO and more formal standards making bodies. It
> is therefore ironic that one of the reasons why we're engaging in this
> problem-statement process is because we seem to be falling prey to
> many of the problems that we once caused a certain feeling of
> superiority over these more formal standards bodies.
>
> Is the answer to become more like these formal standards bodies? That
> seems to be what some people are suggesting. I am hoping though that
> there is something about our process of rough consensus and running
> code which is unique and better than a heavy-weight system based on
> process and votes. That is, I hope that while we are fixing some very
> real problems, that we don't end up throwing out the baby with the
> bathwater.
>
> On the other hand, it may be that that real problem is that smaller
> bodies are just naturally more lightweight (regardless of what scheme
> of polity they use), and that growth inevitably causes problems. In
> that case, the fact that some groups are trying out new standards
> organizations might not necessarily be such a terrible thing.
>
> - Ted
>
More information about the Problem-statement
mailing list