Subject: RE: imparting clues to the trade press...and PR departments

From: Ian King <[email-masked]>
Date: Fri, 27 Aug 1999 11:33:22 -0700

How about 'withoutaclue.org'?  

-----Original Message-----
From: Dan Kohn [mailto:[email-masked]]
Sent: Friday, August 27, 1999 9:18 AM
To: [email-masked]
Cc: Paul Hoffman (E-mail)
Subject: RE: imparting clues to the trade press...and PR departments 

Keith, I think this is an excellent idea that could have a real effect over
several months.  "Shaming" is a very effective technique in most communities
and can work in on-line ones too.  Very few reporters (whether they're
clueless or not) want to be publicly humiliated as not knowing what they're
doing.

Is there any chance that Paul Hoffman would be willing to create a mailing
list where we could discuss the concept, including some examples of the kind
of errors that Keith has privately replied to in the past?

I would be more than happy to register something like ietfhallofshame.org
and serve as initial webmaster, but I agree that we don't want people to
think it's an official IETF activity, so maybe that's not the best name.

		- dan
--
Daniel Kohn <mailto:[email-masked]>
+1-425-519-7968 (voice)   602-6223 (fax)
http://www.dankohn.com

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Friday, 1999-08-27 08:07
To: Richard Shockey
Cc: [email-masked]; 'Keith Moore'; [email-masked]
Subject: Re: imparting clues to the trade press...and PR departments 

maybe we need a mailing-list/web page called "stupid press tricks"
where we post examples of Internet-related mis/dis-information 
foisted on the unsuspecting masses by the press.

(not as an IETF activity, of course)

---

From: Carl Malamud <[email-masked]>
Date: Fri, 27 Aug 1999 16:32:44 -0400 (EDT)

I'm sorry folks, this is getting really old, really quickly.

When you are a teacher and your students don't understand what
you are saying, whose fault is it?

If the press doesn't have a clear message from you, may I suggest
you look internally and understand what you are doing wrong?  If
there is something fundamentally broken here it is the way the
IETF adapts to change and deals with the outside world.  And,
may I respectfully submit, blaming the outside world is not
going to be a scalable solution to your communications problems.

Carl Malamud

---

From: Carl Malamud <[email-masked]>
Date: Fri, 27 Aug 1999 16:32:44 -0400 (EDT)

Carl Malamud

---

From: [email-masked]
Date: Fri, 27 Aug 1999 17:41:21 -0400

> you are saying, whose fault is it?

If I explain something once, and it's not understood, I conclude it was
my fault.  If somebody else tries explaining it as well, in a different way,
I conclude the problem is at the recipient's end.

And I suspect that some of the people have been instructed PLENTY of times.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: [email-masked]
Date: Fri, 27 Aug 1999 17:41:21 -0400

---

From: Pete Loshin <[email-masked]>
Date: Fri, 27 Aug 1999 19:45:39 -0400

At 04:32 PM 8/27/99 -0400, Carl Malamud wrote:
...
>going to be a scalable solution to your communications problems.

Well said. Most of the trade rag editors are overworked, underpaid (at
least relative to most people in this industry), and rarely have any
significant technical education. They are under constant barrage by
vendors--that is, the same companies that employ the people who write RFCs.
And those vendors don't just email, or even telephone, editors. They fly
out to meet with editors, spending many thousands of dollars a year just to
fill editors' ears with the information they want to see in print.

If you want editors to get your side of the story, you've got two choices:

- Educate them yourself. Book flights to Framingham, San Mateo, and New
York City, and schedule meetings with editors at the IDG, Ziff Davis, and
Miller Freeman publications, and then figure out where all the other
publishers are located and get in touch with them. Then, work up a
presentation that gets your point across. Oh, and by the way, make sure you
don't schedule your tour to overlap with any important shows. And one more
thing, you'll have to come up with some reason why they, and their readers,
need to know this stuff--in other words, why is it newsworthy?

- Educate the people who sell your company. Product managers and public
relations people are often even more clueless than the most clueless trade
rag editor. I've encountered messaging server product managers who not only
don't know what USEFOR and DRUMS are, they don't even know what an RFC is
let alone the difference between an I-D and an RFC.

There's a third option, but it might be a little scary: talk directly to
the press yourselves. I've had RFC authors refuse to talk to me about their
IETF work because their company's policy forbade them from talking to the
press. (Which, IMHO tends to give the lie to claims about the IETF work
being done by individuals, not by vendors.)

If you want to keep reading crap in PC Week and Network Magazine, then
leave the important business of explaining your work to people who don't
even know that you exist.

I know that this thread has been beaten to death already, but I take a lot
of this personally. It's very easy to throw stones. The fact is, computer
and network trade publication editors are usually talented people who do
very good work under enormous pressure. You may think they don't do a good
job, but remember that they have to put out a complete revision of their
product every [month|week|day], and there's no question about missing a
ship date. You'll never see one of those magazines with blank pages because
someone couldn't get their article in on time.

my $0.02, of course.
-pl

---

From: Pete Loshin <[email-masked]>
Date: Fri, 27 Aug 1999 19:45:39 -0400

my $0.02, of course.
-pl

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Aug 1999 21:09:34 -0400

> you look internally and understand what you are doing wrong? 

you may suggest it, but it's quite possible that what we are doing
wrong is expecting that it's even possible to give the press a
significant clue boost....thus we are wasting our energy by trying.

> If there is something fundamentally broken here it is the way the
> IETF adapts to change and deals with the outside world. 

doesn't follow.  we have ample evidence, for instance, that the press 
frequently doesn't bother to verify information given to them about 
IETF by vendors, even when such information is easily verifible, and 
even when we've repeatedly told reporters and editors at these
publications how they could easily verify the information.  (hint:
they can always get quick answers and compentent redirection from 
the IETF secretariat.) that, it seems to me, is pretty reasonable 
evidence of fundamental brokenness from some other source than IETF.

now of course IETF can't force them to change, and there's a limited
amount of effort that we should expend in trying to do so.  and there
are certainly other things about IETF that could be improved, and it's
quite possible that there are ways in which IETF needs to do a bit 
of adapting to change.

but trying to give the press a clue looks more and more like a fool's
errand.

I will say that most of the journalists I've talked to really seem to
want to do a good job.  as far as I can tell they're faced with an
impossible task - they're trying to make a reasonably balanced 
assessment of a highly technological and often highly political 
undertaking, from a great distance, without a lot of technical 
insight, with an editorial need to not displease advertisers, and 
heavily biased by vendor press releases that are full of lies
...given all this try to do a reasonable job, but at any rate,
get the story done by 3pm.   under those conditions it's no wonder
that the noise-to-signal ratio is so high.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Aug 1999 21:09:34 -0400

Keith

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Aug 1999 18:16:03 -0700

>going to be a scalable solution to your communications problems.

Carl,

It ni always fair and reasonable to suggest some introspection and I'll 
second your suggestion for IETF review of its approach to press 
relations.  Many IETF participants have contact with the press.  I'm less 
clear whether we will find a clear set of policies and procedures (the 
meat; I don't care about the formalities) of IETF Press Relations.

Perhaps there are some simple things we can do to help the press, though I 
am unclear what.  Most of the information I'd guess they need is readily 
and widely available.  Would it help to assemble some of it into a 
(virtual, web) press kit? Perhaps.

That said, it's important to realize just how bad much of the trade 
reporting is.  As Pete Loshin noted, there are lots of reasons, including 
lousy pay for reporters, as well as the fact that reporters are not 
engineers.  As noted, however, is frequently true that a reporter has an 
agenda, or is unable to understand or is unable/unwilling to do due diligence.

There's nothing we can do about that.  There has been a sea change in 
journalism and carefulness is no longer a prime directive for most 
publications; it is only the occasional reporter with the intelligence, 
integrity and orneriness to go against this change.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Aug 1999 18:16:03 -0700

Carl,

d/

---

From: "John W. Noerenberg" <[email-masked]>
Date: Fri, 27 Aug 1999 19:49:14 -0700

At 6:16 PM -0700 8/27/99, Dave Crocker wrote:
>
>There's nothing we can do about that.  There has been a sea change 
>in journalism and carefulness is no longer a prime directive for 
>most publications; it is only the occasional reporter with the 
>intelligence, integrity and orneriness to go against this change.

Then we have to think about defending the reputation of the IETF 
against their lack of care.  If the sailors don't react, the sea 
change swamps the ship.

---

From: "John W. Noerenberg" <[email-masked]>
Date: Fri, 27 Aug 1999 19:49:14 -0700

---

From: Ned Freed <[email-masked]>
Date: Sat, 28 Aug 1999 11:59:26 -0700 (PDT)

> you are saying, whose fault is it?

Carl, speaking as a former college professor who consistently earned the
highest "grade" from student feedback forms in my entire deparatment, and whose
students were consistently the best prepared for subsequence courses, I can say
with some authority that "it depends".

Most successful teachers quickly realize that triage is their only option: Some
students that will get it no matter whay they do, some students who won't get
it no matter what anyone does, and some will only get it if the teacher works
like hell to impart clues in every manner possible.

The trick is to identify and focus on the last group. And this is the *real*
problem with the present discussion -- it is focusing on the first group.

We are at fault only to the extent that we've assumed that all journalists fall
into the uneducatable category. Although Dave Crocker is absolutely right when
he points to a sea change in journalism that has swelled the ranks of this
group tremendously, there are still people left in the other groups that we can
work with. We just have to expend the effort to find and work with them.

But you appear to be blaming the IETF for our inability to, in the words of Rex
Stout, put sense into a fool's brain. And I'm sorry, while you spun your
message very nicely, it is no more productive to blame the IETF for not being
able to do this than it is to assume all journalists are fools.

> going to be a scalable solution to your communications problems.

Again speaking from experience, trying to teach them all isn't scalable either.
(This is the essentially the reason why I'm no longer a professor.) In fact I
remain to be convinced that there is a scalable solution to this problem. But I
agree we can do more than we're doing now, and that should help -- for a while,
anyway.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 28 Aug 1999 11:59:26 -0700 (PDT)

Ned

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 28 Aug 1999 19:18:36 -0400

Date: Sat, 28 Aug 1999 11:59:26 -0700 (PDT)
   From: Ned Freed <[email-masked]>

   Again speaking from experience, trying to teach them all isn't
   scalable either.  (This is the essentially the reason why I'm no
   longer a professor.) In fact I remain to be convinced that there is a
   scalable solution to this problem. But I agree we can do more than
   we're doing now, and that should help -- for a while, anyway.

Exactly.  We can't teach them all, and so perhaps we should take a
lesson from industrial designers of consumer goods.  You can't assume
consumers will be intelligent, so you dumb-down the interface so they
can't hurt themselves too badly.

Instead of trying to get journalists and pointed-haired bosses to
understand the fine semantics of different kinds of RFC's, maybe we need
to either (a) use different labels for informational and experimental
documents, or (b) let the IESG be far more strict about what kind of
documents can be published as informational RFC's.  (i.e., change the
default from publish in two weeks unless the IESG objects, to publish
only if the IESG agrees to let it be published.)

Either way, there are things we can do that would decrease the chances
of wily marketing departments issueing PR's that take advantage of
reputation associated with a document being an "RFC" --- things that
don't require educating every single journalist or every single reader
of trade rags about the details of our processes.

							- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 28 Aug 1999 19:18:36 -0400

- Ted

---

From: Carl Malamud <[email-masked]>
Date: Sat, 28 Aug 1999 22:03:42 -0400 (EDT)

> can't hurt themselves too badly.

Folks, this is highly insulting to journalists, the general public
*and* the members of the IETF.  Ted goes on to suggest some useful 
things (see below), but the whole tenor of this conversation is really 
demeaning to a professional organization like the IETF.

For every "dumb journalist" you show me, I'll show you an equally
clueless engineer.  Tarring an entire profession just doesn't
cut it.  If we want to have a conversation about how the standards
of professionalism across all fields has diminished, I'd be willing
to consider that (though I'd argue the opposite), but this paranoid,
arrogant view that IETF members are clueful and the press isn't
just doesn't cut with reality.

The reason to fix the IETF is not that journalists (or any other
profession) have "got it wrong."  The reason to fix the IETF is
that the process has evolved into a highly broken one that
members of the press *AND* long-time members of the IETF have
a great deal of difficulty interpreting.  This conversation about
the press is really about how the IETF has managed to look into a 
mirror yet seems to think it is a window.

Carl

---

From: Carl Malamud <[email-masked]>
Date: Sat, 28 Aug 1999 22:03:42 -0400 (EDT)

Carl

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 28 Aug 1999 20:19:02 -0700

At 10:03 PM 8/28/1999 -0400, Carl Malamud wrote:
>clueless engineer.

Absolutely right. I believe I have had to explain the difference between an 
RFC and a standard to more engineers than I have to press or PR folk. And, 
I've definitely had to re-explain it to more engineering types than to the 
press.

I believe that an RFC that summarizes the IETF process, gives examples of 
errors that have been made in press releases and articles in the past, and 
shows what they should have said, will go a long way to reducing the 
problem. Instead of us going off on endless threads on this mailing list, 
someone could send a short document to the person who made the error and 
ask them to correct their mistake.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 28 Aug 1999 20:19:02 -0700

--Paul Hoffman, Director

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Aug 1999 02:56:56 -0400

> For every "dumb journalist" you show me, I'll show you an equally

No doubt about that.  My list of complaints about implementors
who can't be bothered to read protocol specifications is a lot
longer then my list of complaints about journalists who can't
be bothered to make a phone call or check a web page to verify
information about ietf.  But this whole conversation was about 
ietf mis-information in the trade press, not whether engineers
or journalists had the greater clue density.

(if all we wanted to do was pick on somebody, we could just bash
marketing people, who really are completely clueless.  :)
 
> a great deal of difficulty interpreting.

No, I don't think so.  No matter what process the ietf had, there
would still be standards track and non-standards-track documents.
There would still be groups that hadn't been chartered yet, claiming
that they had support and backing and charter from ietf which they
didn't have.  There would still be vendors claiming to be working
with ietf on a particular topic, in the absence of any actual work 
being done, or any agreement from ietf officials to do any such work.
There would still (hopefully!) be individuals using their best
engineering judgement and representing their own technical opinions 
rather than parroting the public positions of their employers.

I can understand when a reporter gets confused about the difference
between an internet-draft and a draft standard, or the difference
between the applications area and the transport area.  I can even
understand it when they believe that technical standards development
is driven by media hype, so they think that (e.g.) the recent media war
over instant messaging will help speed up development of that standard.
I happen to disagree, but I understand that they're in a different 
world, and occasionally the world of hype really does have a significant 
(and perhaps even positive) effect on technical developments.   So who 
knows, maybe they're right and I'm wrong about this one.

What really bugs me is when they blindly print information about ietf
as if it were true, from sources known to be unreliable or heavily 
biased, without bothering to verify that information, and when the 
effort involved in doing so amounts to a single phone call or web 
page lookup.  I suppose it is arrogant and insulting of me to assume 
that this is due to incompetence, or cluelessness, or laziness, or malice,
on the part of the reporter...and in fact I don't want to believe it is 
any of these.  But regardless of its source, the problem of misinformation 
remains.
 
None of which is to say that the IETF process doesn't have its problems.  
But in my experience the biggest problem that the trade press has in 
understanding IETF, (aside from its failure to verify information 
from unreliable sources before reporting it as fact) has very little 
to do with the IETF process subtleties and everything to do with the 
fact that, in general, the activity of the IETF and the technical 
development of the Internet in general, are almost completely unrelated 
to whatever is currently being hyped by product vendors.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Aug 1999 02:56:56 -0400

Keith

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sun, 29 Aug 1999 14:37:15 -0400

From: Carl Malamud <[email-masked]>
   Date: Sat, 28 Aug 1999 22:03:42 -0400 (EDT)

I wasn't intending to tar the entire profession; I'm sure there are
quite a few, if not many, clueful professionals out there.  And as a
whole, I'm sure journalists not to do the right thing.  But they are
trained professionally to write articles, and not to be engineers or to
understand the subtle distinctions between RFC's, or the rest of our
processes.

I'm not insulted when lawnmowers have tags that say "warning: lawn
mowers aren't intended to trim hedges".  The reality is that someone
stupid did that once, cut off his foot, and managed to sue the lawnmower
company for it, and now there are all sorts of warnings and safety
devices to stop people from hurting themselves.  Are safety devices that
prevent manufacturer's liabilities an insult to everyone's intelligence?
(But the reality is that there *are* stupid people out there, and it's
better to protect them from themselves, even when it's annoying because
it means that lawnmowers shutdown and have to be restarted if you remove
your hands from the dummy bar.)

Similarly, if there are things we can do that make it harder for people
(including journalists) to be misled by marketeers, we should consider
them, and not lament about how stupid they are to not understand our
"peculiar ways", or to blame ourselves for not successfully educating
them.  Sometimes, it's better to put in the safety devices than to try
to educate everyone.

   Somewhat More Constructive Comments:
   > documents can be published as informational RFC's.  

And that was in fact the point of my whole e-mail.  I'm sorry if you
thought that I was implying that the entire profession of journalists
are clueless.  That was certainly not my intent.  At the same time,
there are more of them than there are of us, and saying that we should
somehow train them all is IMO a pointless task.  Keith said that he's
been trying that for years, with no demonstrable effect.  Maybe that
should be a hint.

						- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sun, 29 Aug 1999 14:37:15 -0400

- Ted

---

From: Einar Stefferud <[email-masked]>
Date: Sun, 29 Aug 1999 14:25:57 -0700

Collectively, I think that Carl Malamud, John Curran, Tim Kehres, Ned
Freed, and Theodore Y. Ts'o (in order of apperance) have captured the
essential issues and aspects of this thread, though they do not
entirely agree on things.

Per Carl, clearly it is the responibility of the IETF to explain
itself, or remain misunderstood.  This responsibility cannot be fobbed
off to others.  It is something close to an axiom of communications.

	If you are not being understood; and you want to be
        understood; as the speaker, it is your problem to solve!

Ned's observation that even then you might not succeed is of course
valid, but this does not shift the burden of responsibility.  

Now, in the book "SystemAntics" by John Gall, I found a very appropo
Meta Concept: Meta Strategy Number V. (page 195), to wit:

	IF YOUR PROBLEM SEEMS UNS0LVABLE, 
	CONSIDER THAT IT MIGHT BE A META-PROBLEM.

Of course, this strategy requires some thought about what are meta
problems and what specific meta problem might be present here.

To my thinking, a meta problem is one which spawns other problems
which behave as mere symptoms of the meta problem.  We have two
alternatives here:  We can build a problem trap so as to catch and
deal with each spawned problem, or we can turn off the problem
generator by solving the meta problem.

I claim no authority, but I do posit this hypothesis:

To wit:

	The RFC meta problem is mainly in the overloading (a good IETF
	word) of the name RFC, which means "Request For Comment".  

It does not mean "STANDARD" or anything like it, so it is misleading
from the very beginning, and now you are upset that the press (and
corporate press release artists) do not avoid being misled by you.

As such, the RFC series is a rather poor place to stash serious stuff
like IETF STANDARDS, and giving them all a second more obscure and
generally unused name like STD does nothing to solve the meta problem.

I realize that by attacking your mode of use of the sacred name "RFC"
I am flying against one of the longest standing legendary traditions
of the IETF, but I submit that hanging tough on the overloaded use of
the RFC name is at the root of your current specific problem, and
until you resolve this meta problem, you are only fighting over how to
solve a rather large number of symptoms.  This is OK if the effort is
a labor of love;-)...

Further, I am certain that Steve Crocker who authored RFC-1 will not
mind seeing his beloved creation grow up to mature adulthood;-)...
And somehow I feel that Jon Postel would be very pleased to see all
this resolved.

One suggestion is to simply rename and republish under their new
names, all IETF STANDARDS (Proposed, Draft, and "full"), and all otehr
stuff like BCPs, and leave the RFC series for what it is "Requests For
Comment".  In fact, all "full" standards already have a new name, so
it only requires changing your conventions to actually use the
carefuly chosen new name of STD.

BTW, this will be my only contribution to this thread, take it or
leave it, as it is all I have to contribute.  During the past year, I
have decided to retire from active ITEF involvement, though I do read
some threads from time to time when someone alerts me to an
interesting topic.

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Sun, 29 Aug 1999 14:25:57 -0700

To wit:

Cheers...\Stef

---

From: Pete Loshin <[email-masked]>
Date: Mon, 30 Aug 1999 00:53:03 -0400

This topic obviously hits a nerve with a lot of people one way or another,
so I'd say that makes it newsworthy. Rather than prolonging this thread
even further, I'd like to request everyone with specific examples of
articles or other coverage that reflects inaccurate reporting related to
IETF issues to please contact me directly (not through the list) with
details (make the subject line read "IETF CLUES"). All I want are:

- the publication
- the title (and author, if there was a byline)
- the date of the article
- URL of the article in question
- what was misrepresented
- what you would do to make the report correct

You don't have to get too involved in explanations, I'm up to speed on most
of the relevant issues; if I don't understand something and can't figure it
out, I'll just follow up with my questions.

OK? I will take the results, contact as many of the culprits as I can (PR
departments as well as editors), and turn it into a news article. And then
submit it to whatever publication or publications seem most appropriate.
And if no one wants to publish it, I'll publish it myself on my own web
site (though I'm sure that I'll find at least one taker if not many).

Based on all the traffic to the list, there should be plenty of examples.

Does that make any sense? I mean, instead of arguing about whether or not
journalists are educable, or how much a company should be spending on
public relations?

BTW, check out my paper on RFCs and IETF standards at
http://www.loshin.com/standards.html and feel free to pass along comments
if you feel it is necessary.

-pl

---

From: Pete Loshin <[email-masked]>
Date: Mon, 30 Aug 1999 00:53:03 -0400

- the publication

-pl

---

From: "John W. Noerenberg" <[email-masked]>
Date: Mon, 30 Aug 1999 08:51:51 -0700

>demeaning to a professional organization like the IETF.

An old friend reminds me from time to time, that in IETF 
conversations, it is wise to have a thick skin and a civil tongue.

---

From: "John W. Noerenberg" <[email-masked]>
Date: Mon, 30 Aug 1999 08:51:51 -0700

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Aug 1999 09:26:00 -0700

At 08:51 AM 8/30/99 , John  W. Noerenberg wrote:
>An old friend reminds me from time to time, that in IETF conversations, it 
>is wise to have a thick skin and a civil tongue.

Unfortunately by the end of IETF week, many people tend towards having 
thick tongues and UNcivil skin...

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Aug 1999 09:26:00 -0700

d/

---

From: Peter Deutsch <[email-masked]>
Date: Mon, 30 Aug 1999 13:27:24 -0400

g'day,

> conversations, it is wise to have a thick skin and a civil tongue.

As the old joke goes "'Doctor, it hurts when I do this.'
... 'Well, sir - don't do that.'"

While it is true that:

	if(MAX_ENDURED_TEMP < kitchen_temp) goto OUTSIDE_KITCHEN;

The issue appears to be that, probably because of the acclaim it
received for some of its past successes and aided by just a touch of
naive insularity, some participants in the IETF have started believing
it's okay to be rude and arrogant to people *outside* the IETF. Yeah,
right.

If you're going to discuss how to change the way journalists (for
example) perceive the IETF, this former card-carrying journalist would
politely suggest that an aggressive "'dem bozos ain't got no rights"
attitude isn't going to do your cause one smidgen of good. It's *their*
sandbox, and so you'd better think a bit about the value of using
*their* rules.

As for the original thread that got us here, I personally believe that
this whole episode has done the IETF more harm than good. Over the past
week or two I've seen cheap shots at journalists, "marketing types", the
motives of the author of an informational draft documenting existing
practice and those who dared offer their company's support for that
draft (to name just a few). To put it bluntly, you people are taking
yourselves *way* too seriously.

The whole tone of this debate suggests that a fair number of people on
this list are actually starting to believe that the IETF really has the
power to make or break Internet technology. I diagnose this as Hubris,
pure and simple. Think Winston Churchill and democracy, please.

Given the progress of this debate I wouldn't be surprised to observe in
the future that someone wanting to document existing practice and make
sure that their own particular corner of the world is "Internet aware"
takes their marbles elsewhere. Sure, we need to worry about quality
control, but as I've always suggested in the context of college - the
goal shouldn't be to make it hard to get in. The goal should be to make
it hard to get out. Cut off the flow of lower level input and we can all
run a book on how long before the higher level stuff dries up, too.

So, apply the time-honoured peer review techniques for standards track
documents, but if you work this hard at keeping people away, you can
rest assured they'll stay away. Just be careful what you ask for, as
you're liable to get it...

					- peterd

[* Bonus side rant  *]

I'd still strongly urge te "powers-that-be" to reconsider their historic
aversion to preserving the working group mailing lists. All this "angels
on the head of a pin" discussion about renaming the drafts, preserving
only some of the drafts, never preserving the drafts, etc ignores the
basic observation that:

	a) oldcomers complain that newbies keep repeating old,
	   bad ideas while, 

	b) the same oldcomers refuse to provide newcomers systemic 
	   access to both the old ideas and the context in which they
	   were dealt with in the past.

So, I again respectfully suggest that the IETF should, as a matter of
policy, preserve all working group mailing lists in machine readible and
readily accessible form. And when newbies suggest something that
stretches the patience of the oldcomers, they be told (to whatever
degree of politeness your mother managed to beat into you before you
left for cyberspace) "go read the archives".

					- peterd

---

From: Peter Deutsch <[email-masked]>
Date: Mon, 30 Aug 1999 13:27:24 -0400

g'day,

While it is true that:

					- peterd

[* Bonus side rant  *]

					- peterd

---

From: Tim Salo <[email-masked]>
Date: Mon, 30 Aug 1999 14:02:36 -0500 (CDT)

> Date: Mon, 30 Aug 1999 13:27:24 -0400
> From: Peter Deutsch <[email-masked]>
> 	[...]
> 	[...]

From private e-mail from a well-known IETF participant:

> Tim Salo writes:
> >	[...]
> > I believe that the IETF would undoubtedly benefit from expecting at least
> > a modicum of professionalism from even the clueful.
> 
> The reality is, however, that brilliant computer professionals are
> often socially unskilled people. Eliminate them, and lots of the folks 
> who made the internet work disappear. It is certainly *better* when
> everyone is nice, but we just have to accept that it isn't always what 
> happens.

-tjs

---

From: Tim Salo <[email-masked]>
Date: Mon, 30 Aug 1999 14:02:36 -0500 (CDT)

-tjs

---

From: Christian Huitema <[email-masked]>
Date: Mon, 30 Aug 1999 18:04:15 -0400

>I've definitely had to re-explain it to more engineering types than to the 

Let's take a contrarian view here.  Don't get me wrong; I know perfectly
well that "not all RFC are standard." But what if the press was actually
right?  What if market adoption of an open specification was way more
important than working group consensus and IESG votes?

Can you recall times when a document reached "standard status" in the
Internet before being even published as an RFC?  Well, this is exactly what
happened with BGP-4.  The draft was so much needed that it was implemented
and deployed long before being published as proposed standard. Yet, from a
market point of view, it was a standard: the specification was publicly
available, and it was pretty much mandatory in inter-domain routers.

Suppose that some router manufacturer, back in 1994, had published a press
release to the tone of "new Internet standard saves Internet from sure
death." What would have been the correct reaction of the proposed PR police?
Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 30 Aug 1999 18:04:15 -0400

---

From: Pete Loshin <[email-masked]>
Date: Tue, 31 Aug 1999 17:55:00 -0400

I know that many of you are probably tired of seeing this discussion go on.
However, I thought adding some data to the overwhelming body of opinions
might bring us to a better understanding of the "problem."

So far, I've had (only!) two reports of erroneous reporting, both relating
to the IPP situation. Doing a little bit of investigation, I discovered
that Microsoft's press release:

http://www.microsoft.com/PressPass/press/1999/aug99/HPfunctionPR.htm

was corrected and posted with a date of 8/27 (as someone reported earlier);
checking HP's website, I discovered a press release dated 8/19:

http://www.hp.com/pressrel/aug98/19aug98a.htm

describing the situation slightly more correctly, but still misidentifying
the working group as a consortium and the i-d as being submitted as a standard.

I also uncovered several other instances of the "incorrect" version of the
Microsoft press release replicated in other articles online. Some of these
were simply the same article, propagated through content-sharing deals
(e.g., IDG news service). Others were clearly written from the same press
release/PR contact, and describe the working group as an industry
consortium and the specification as an Internet standard. I'd suggest that
the "blame" for the IPP situation should be laid at Microsoft's feet, along
with Waggener-Edstrom, their PR agency.

Here are some more facts (as opposed to opinions based on stereotypes and
unfounded suspicions):

I did some informal research, consisting of doing a search for
"IETF+standard" on the IDG.net website and then checking the first 30 or so
articles for accuracy. Most of the articles reported on IETF standards and
drafts reasonably accurately. In fact, some of the articles quoted at least
one of the participants in this discussion (including someone who has been
complaining about inaccuracy), in some cases going on at length and great
detail about the IETF standards process. Was this the result of someone
following up on "inaccurate reporting"? Or was it simply "accurate
reporting" the first time around? I can not answer that question.

- Microsoft was involved in several stories where there was
misrepresentation; sometimes, these included instances of Microsoft product
managers making inaccurate statements about IETF processes.

- In some other cases where the report was inaccurate, the reporting would
have been corrected if the word "standard" had been replaced by
"specification."

I'm not going to bother trying to repeat this experiment with other trade
publishers, though I would suggest that those people who are convinced that
journalists "never get it right" and are "incapable of getting it" should
try it with ZDnet and CMP, and whatever other services they like. I suspect
that, with some minor variations, the results will be roughly equivalent
because editors often move from one publisher to another, as do freelancers.

Again, I invite the participants to report to me, off-list, any examples of
magazine or other articles where the IETF process was misrepresented. I'm
particularly interested in ongoing "cluelessness" rather than more examples
of reports about IPP.

Finally, I'd appreciate any comments or suggestions regarding my report on
IETF specifications at http://www.loshin.com/standards.html; if you think
it's useful, by all means pass it along to anyone who needs the information.

-pl

+-------------------------------------------------------------+
| Pete Loshin                           http://www.loshin.com |
|                                                             |
| _IPv6 Clearly Explained_ Morgan Kaufmann January 1999       |
| _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 |
|                                                             |
+-------------------------------------------------------------+

---

From: Pete Loshin <[email-masked]>
Date: Tue, 31 Aug 1999 17:55:00 -0400

-pl