Subject: RE: improving WG operation

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 7 May 2005 18:56:43 -0700

> Behalf Of Keith Moore

> > So, if there is indeed the IETF community expectation that 
> the WG gets 
> > to pick at least some of its own chairs, then rfc3710 needs to be 
> > revised to reflect this.
> 
> not necessarily.  a significant part of the community can 
> expect something 
> and there still not be rough consensus about it.

I think it is time to redefine consensus.

What we need for a standard is a group of people with a reasonable
degree of skill in the art who agree on a common plan.

That is not necessarily the same as 'working group consensus'.

For example if there is a protocol where there is a divergence of
opinion on the correct way to proceed and one group can agrree on a
coherent plan then it goes forward.

If there are two groups with coherent plans then the way forward depends
on whether we are talking about an infrastructure protocol such as BGP
or DNS or an application protocol.

If we are talking about infrastructure protocols then I think that is a
case where the IESG needs to step in sooner rather than later. 

If we are talking about application protocols let the market decide.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sun, 8 May 2005 01:31:46 -0400

> degree of skill in the art who agree on a common plan.

no.  the protocol doesn't just affect those "with a reasonable degree  
of skill in the art".
(as if one could define "which art" were relevant...)

> coherent plan then it goes forward.

no.  at least, not with the expectation that the work will ever be  
found acceptable.  if there is a divergence of opinion it is highly  
likely (though not certain) that there is a fundamental lack of  
understanding on both sides that needs to be resolved before real  
progress can be made.  any work done without that understanding is  
likely to be flawed and the investment in that work likely to be wasted.

> If we are talking about application protocols let the market decide.

it's not that cut-and-dried.  it can be very costly to users to let  
the market decide.  sometimes the market doesn't decide, it just  
fragments.  users either don't end up with a coherent solution or  
they end up with an overly complex solution that doesn't interoperate  
well - IM is a good example.

that and the argument of "let the market decide" is constantly used  
by market leaders as a way to try to derail standards that might  
compete with their (usually poor) proprietary solutions.   it should  
be taken as a sign of weakness on the part of those who say it.

what you appear to be trying to do is to increase the number of ways  
in which people can derail the process.

Keith

---

From: Tom Lord <[email-masked]>
Date: Sat, 7 May 2005 22:50:39 -0700 (PDT)

> in which people can derail the process.

And more power to him.  IETF was a great success.  It's reaching
end-of-life.

  > fragments.

So?

-t

---

From: Keith Moore <[email-masked]>
Date: Sun, 8 May 2005 01:55:14 -0400

>> in which people can derail the process
>

people still seem to find its work useful, at least in some areas.
if you don't feel it's worth your time, you are free to spend your  
time elsewhere.

>> it's not that cut-and-dried.  it can be very costly to users to  
>> let the market decide.  sometimes the market doesn't decide, it  
>> just  fragments.
>
> So?

so "let the market decide" is a lousy rule.  there's no justification  
for it.  it's just the sort of thing that someone says when he fears  
competition from a better product.

---

From: Tom Lord <[email-masked]>
Date: Sat, 7 May 2005 23:11:55 -0700 (PDT)

The original focus of IETF was to create and firm-up the Internet.  That
war was won.

You're complaining that some application-layer stuff like IM isn't as orderly
as you'd like.

I don't see the connection between your complaint and the original
focus.

Now, refining a few core protocols -- that'd be great.  Trying to be
the government of all protocols -- huh?  The SRFI process, in the world
of Scheme programming, seems to me the more utilitarian approach to 
working on higher-level protocols: there's nearly nothing to fight over
in that process.

-t

---

From: Tom Lord <[email-masked]>
Date: Sat, 7 May 2005 23:24:27 -0700 (PDT)

for it.

People should generally reject religious fundamentalism, including
what you said there.  If you have an a priori case for this or that,
fine, but you seem to be making a mystical argument for a wildly
generalized claim.

-t

---

From: Keith Moore <[email-masked]>
Date: Sun, 8 May 2005 08:55:48 -0400

> I don't see the connection between your complaint and the original

Even if that was the original focus, I don't think it is relevant any  
longer.
I've been around IETF for 15 years and that has never been IETF's  
focus within that time.
That doesn't mean the organization is nearing end-of-life, it means  
that as the Internet has changed, so has IETF.

> the government of all protocols -- huh?

The IETF never has tried to be the government of all protocols.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 8 May 2005 09:18:13 -0400

> fine, but you seem to be making a mystical argument for a wildly

for some, "let the market decide" is a religious statement.  it's  
generally based on an unexamined faith in market conditions as an  
effective way of making a good choice among competing technologies.   
there are cases where letting the market decide makes sense - but  
it's easy to find several cases where this is not so, and difficult  
to generally outline the set of cases where the rule does apply.   
there's no justification for citing "let the market decide" as a  
general rule, not even for applications, because there are too many  
cases where application functionality is severely compromised by poor  
market decisions.

(which design shall we use for a bridge to cross the river between  
these cities?  let's let the market decide!)

the other justification for "let the market decide" is when the  
speaker believes that his financial interests will be better served  
by letting the market decide than in the absence of input from IETF,  
than by letting the market take such input into account.  ultimately,  
the market decides in either case.  the real intent of "let the  
market decide" within IETF is to try to keep individuals within IETF  
from influencing the market.  the speaker presumably believes that  
the market will make a more favorable decision (for him) without  
IETF's input than with IETF's input.   the speaker may hope that by  
exploiting some people's misguided faith in market conditions, and  
exploiting the tendency of the market to make poor decisions, he can  
silence those who would propose a better way to do it.

---

From: Tom Lord <[email-masked]>
Date: Sun, 8 May 2005 16:23:08 -0700 (PDT)

From: Keith Moore <[email-masked]>

For some it may be so (I agree) but apparently not you are I.

All I mean is that, for higher level protocols, letting people do what
they will ("the market decides") seems to me to be the best option.
Yes, using your example, IM protocols fragment, interop suffers,
there's lots of crap --- so what?  It looks like it will probably sort
out.  Fretting over how best to impose governance over the situation
doesn't obviously accomplish anything.  There are faster, better,
cheaper ways I think to get universally adapted standards in motion
than wrangling with committees.

The main practical utility of standards very high in the stack is that
they are written clearly, widely reviewed, and generally agreeable to
people.  One doesn't need a complicated government to support the
development of standards with that utility: a few mailing lists and
archives do most of the trick.  Processes in which there is nothing
available to fight over seem like the most efficient to me.  That this
kind of anti-process process is even an option is a tribute to the
historical success of IETF but it would be weird to postulate a need
for IETF to do much more than what's already been done, imo, other
than to maintain the lower layers.

Surely there are grey areas but those don't strike me as obviously IETF's
business.  For example, since IM is used in life-critical applications,
regulation may be in order -- but that's not a good role for IETF either.
It's swell to have leading experts advise regulation but having that occur
via IETF adds no value (and costs efficiency).

   the speaker may hope that by exploiting some people's misguided
   faith in market conditions, and exploiting the tendency of the
   market to make poor decisions, he can silence those who would
   propose a better way to do it.

You are absolutely right, imo, that jerks regularly try the trick that
you describe and that that's a serious problem that deserves
attention.  It's the conclusions you draw from that that I don't quite
get.

Anyway, thank you for the uptake and I am starting to feel overextended
on my justification for posting to this list so, while I'm not against 
replying further -- I'll be tending to return to my seat now.

-t

---

From: Sam Hartman <[email-masked]>
Date: Sun, 08 May 2005 20:44:01 -0400

>>>>> "Tom" == Tom Lord <[email-masked]> writes:

    Tom> All I mean is that, for higher level protocols, letting
    Tom> people do what they will ("the market decides") seems to me
    Tom> to be the best option.  Yes, using your example, IM protocols
    Tom> fragment, interop suffers, there's lots of crap --- so what?

I think our concern is that we have finite resources here in the IETF.
If you want a market decides standards, go set up an industry
consortium or go to a market decides standards body.

The IETF works best when people bringing technologies to it buy into
the idea of building rough consensus.

So, if you want the market to decide, and you don't have a
particularly good reason for being at the IETF, perhaps we're not the
best place for you to do your work.

One obvious question to ask is whether the IETF still has work to do
and is still the right place for anything.  My answer is simple: let
the market decide;)

---

From: "Keith Moore" <[email-masked]>
Date: Mon, 9 May 2005 00:24:24 -0400 (EDT)

> they will ("the market decides") seems to me to be the best option.

there are cases when this is true.  I don't think the cases are as simply
described as  "higher level protocols" or "applications".  it depends, for
example, on whether competing apps interfere with each other or with other
valuable network facilities, whether particular solutions will do harm to
networks and/or end systems when deployed (say, due to poor security), and
on the size of the market for a single solution vs. the size of markets
for fragmented solutions.

it's a bit like an argument that there shouldn't be any standards for
automobiles.  which leads to more pollution, higher accident rates, higher
casualties, higher insurance rates and/or more expensive vehicles for
everyone.   there are corrective mechanisms for some of these (as in,
people will tend to favor cars that have lower insurance rates) but some
of an individual's risks due to automobiles aren't influenced by his own
decisions so much as others' decisions.

> doesn't obviously accomplish anything.

well, nobody is talking about governance, since we don't have any
enforcement mechanisms.

> There are faster, better,

it's pretty difficult to build something that works well in the diverse
environments in the Internet without extensive discussions among
experienced people with a wide variety of interests.  to the extent that
it happens, it's either luck (rare) or genius (even rarer).

> archives do most of the trick.

again, nobody is talking about a government.  we're talking about a
mechanism to support engineering work among diverse and often-competing
participants, that will produce results in which users/customers can have
a high degree of confidence.

> Processes in which there is nothing
> available to fight over seem like the most efficient to me.

that's because you aren't considering the cost _after_ that process.

Keith

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 09 May 2005 08:44:46 +0200

At 06:24 09/05/2005, Keith Moore wrote:
>described as  "higher level protocols" or "applications".

Unfortunately never true with IANA. Once a registry is set-up it prevents a 
better one to address the same topic, even if disregarded by most of the 
users it will be used by some and will stay around. That will make 
up-grading its legacy a huge amount of convincing and probably years of 
delays for the market.
jfc

---

From: Dean Anderson <[email-masked]>
Date: Mon, 9 May 2005 18:32:47 -0400 (EDT)

>    competition from a better product.

I agree with Keith. But how about:

  "So...  We all work very hard to create standards using a 
   vendor-neutral, open process that work for many parties, not
   just a single vendor"

> The original focus of IETF was to create and firm-up the Internet.  
> That war was won.

The internet evolves. New standards are created. Old standards are 
modified.  That process doesn't stop.

But if you aren't interested, why are you here?  What's your interest? I
don't understand your point.  Are you here to convince the rest of us that
the IETF is irrelevant?  The IETF will "end" when people lose interest in
its works.

> You're complaining that some application-layer stuff like IM isn't as orderly

Disorder isn't good for the users, either. Its not just a personal view of
orderliness. And it isn't good for the market to have such unnecessary and
gratuitous disorder. That's why standards of any form exist.

> The SRFI process, in the world of Scheme programming, seems to me the
> more utilitarian approach to working on higher-level protocols: there's
> nearly nothing to fight over in that process.

I suspect that the architecture of Scheme and Lisp has a lot to do with
this.  You have a few core language constructs and everything else is
built on top of that. Try to take away CAR or CDR and you'd have big
problems with consensus, I suspect.  Better examples is the Common
Lisp/Scheme schism.  There can easily be many languages, but its harder to
say there will be multiple BGP or TCP variants.  Some order, beyond the
"you're welcome to create a code fork" is necessary when you have
different pieces of hardware that have to interoperate.  A program only
needs its particular runtime, and we can easilly have many runtimes for
different languages.  If you were making scheme/lisp hardware, there would
be more concern about the compatibility of language primitives. (Didn't we
already have this battle with LMI and Symbolics?)  So I don't think the 
Scheme programming analogy works.

But I agree that the "consensus" is a vague term.  Most of the people who
don't like it are the ones where the consensus didn't go their way.  In
any specific case, its hard to tell whether they have a valid complaint or
not. I agree that's a problem. And partly because the definition and
determination of "consensus" is so vague, there is sometimes genuine cause
for suspicions about motives, politics, and such. However, putting
together a simple voting process won't work either.  Like democracy, its
just about the worst thing there is, except for the alternatives. So I
think collective judgement by the WG chairs and the IAB is the only way.  
I think trustworthy and honest WG chairs and IAB members are critically
important, and a fair complaint resolution process is also important.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Mon, 9 May 2005 18:33:30 -0400 (EDT)

> consortium or go to a market decides standards body.

The market always decides.  And people will always "do what they will".  
If you want different standards, you can always go to another standards
body. There are many to choose from.

However, before the market can decide, standards must be chosen, and put
forth. Standardizing what the big vendors want isn't really
"standardization". That's just rubber-stamping a big vendor.  Since the
big vendors can create their own defacto standards without the need for
rubber stamps, such groups tend not to last too long.

There may indeed be improvements to the IETF process, but the fundamental
ideas have worked reasonably well, and radical divergence isn't necessary.  
It is sign of good health that people are seeking improvements.

		--Dean

---

From: Tom Lord <[email-masked]>
Date: Tue, 10 May 2005 00:41:30 -0700 (PDT)

> the IETF is irrelevant?

Absolutely not.  Nearly the opposite.  I hope that if you look back at
some of my other messages in this thread that's clear.

  >> You're complaining that some application-layer stuff like IM
  >> isn't as orderly as you'd like.

  > Disorder isn't good for the users, either. Its not just a personal
  > view of orderliness. And it isn't good for the market to have such
  > unnecessary and gratuitous disorder. That's why standards of any
  > form exist.

I'm not so sure IETF can help user's other than by producing very
good, easily accessed documents with available reference
implementations.  An endorsement/trust-based system for calling
attention to good standards seems like all you've ultimately got --
why not institutionalize *that*?  Why *isn't* the rest of the
governance simply noise?  Why *isn't* the rest of the governance
simply a game a professional organization has agreed to play that will
ultimately turn it into just another consortium?  Isn't the
rule-mongering just a very indirect attempt to find rules that
coincidentally create the effects an endorsement/trust system would
render in a more naked form?  What's the "value add" of anything beyond 
an endorsement/trust system?  My answers to those questions are clear
and that's why I say: strike while the iron is hot -- while there are
still recognizable names who roughly essentially deserve trust?

-t

---

From: Dean Anderson <[email-masked]>
Date: Tue, 10 May 2005 16:45:32 -0400 (EDT)

On Tue, 10 May 2005, Tom Lord wrote:

> implementations. 

The IETF doesn't produce documents that are meant to be accessible to
users. Nor does it produce reference implementations. IETF documents are
meant to be accessible to engineers and operators, creating and running
interoperable services of various types. One and possibly two
implementations are usually required for a standard to be acceptable. The
point of this is to require that specifications be both implementable and
complete.

> An endorsement/trust-based system for calling attention to good
> standards seems like all you've ultimately got -- why not
> institutionalize *that*?

The trust-based system we have has a track record of obtaining good
specifications.  We have institutionalized that, vaguely though it might
be.  This doesn't mean this process can't be improved, nor that it
shouldn't be critically examined.  But I don't see that this has anything
to do with calling attention to good standards.

The IETF has no marketing or promotion department to call attention to
anything it does. It is all through word of mouth and the interaction with
participants.  I don't think such a department is necessary. 

> Why *isn't* the rest of the governance simply noise?  Why *isn't* the
> rest of the governance simply a game a professional organization has
> agreed to play that will ultimately turn it into just another
> consortium?  Isn't the rule-mongering just a very indirect attempt to
> find rules that coincidentally create the effects an endorsement/trust
> system would render in a more naked form?  What's the "value add" of
> anything beyond an endorsement/trust system?  My answers to those
> questions are clear and that's why I say: strike while the iron is hot
> -- while there are still recognizable names who roughly essentially
> deserve trust?

I'd offer one point: Name recognition has nothing to do with trust. In the
past few years, we've seen some very recognizable and previously highly
trusted names turn out to be untrustworthy in a number fields, endeavors,
and organizations. Whether someone is still trustworthy is also something
that needs to be critically examined now and again.  An organization's
trust assets only remain assets if they remain trustworthy.  Trusted staff
isn't the only thing going for the IETF, but it is a critical component.
But untrustworthy staff can be replaced without damage so long as they are
replaced promptly.  It is usually delay in replacement of trusted staff
that creates the most damage for organizations that depend on trust.

So far as "striking while the iron is hot", well, "urgency" is usually and
historically a sign of weak technical arguments that won't hold up to
careful and critical scrutiny.  There is nothing here that needs attention
so urgently we can't analyze the problem and the proposed solutions. So
far as I am aware, in _every_ case where "urgency" was cited as a reason
for foregoing analysis, it has been found both that there wasn't any
urgency, and that the proposal was seriously flawed.

		--Dean

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 10 May 2005 23:41:22 +0200

>point of this is to require that specifications be both implementable and

Dean,
the IETF users are the ones who use the IETF deliverables. And the Internet 
is made of the adherence to these deliverable (which do not make the best 
documentation around). So, you cannot know or decide who will be the users. 
(may be you refer in your mind to "end users"? There are none on the 
Internet because it is not a centralised network.

Just remember that Internet users have designed P2P, VoIP, NATs, etc. for 
some and that others have more processing and communication powers than the 
whole AT&T 20 years ago) and you never know who will need what (even if 
99.99% will never read an RFC, they will all read RFC quotes and they must 
be clear and consistent with what their consultant, their ISP, their 
operator will tell them). What I mean is there is no Internet "gnosis", 
there should only be an Internet "gospel".

There is no shame in it, but the IETF mechanic seems to be more:

- a user comes with a working project
- IETF starts maintaining it and documenting it what helps its integration 
and scalability
- if the whole common thing is accepted and works it can become a standard.

jfc

---

From: Tom Lord <[email-masked]>
Date: Tue, 10 May 2005 18:58:37 -0700 (PDT)

From: Dean Anderson <[email-masked]>

   The IETF doesn't produce documents that are meant to be accessible to
   users. Nor does it produce reference implementations. IETF documents are
   meant to be accessible to engineers and operators, creating and running
   interoperable services of various types.

(a) please don't be so classist.

(b) please don't put words in my mouth, even by implication of your reply.

Thanks,
-t

   > -- while there are still recognizable names who roughly essentially

   I'd offer one point: Name recognition has nothing to do with trust.

Right.  Trust has only a role in drawing attention.  People still have 
to think for themselves.