Subject: Re: the old "separate document series" argument

From: Charles Perkins <[email-masked]>
Date: Wed, 25 Aug 1999 11:39:05 -0700 (PDT)

I have an intermediate solution, that is not the whole solution.

We should _require_ that RFCs be cited as Informational RFCs,
Proposed Standard RFCs, Experimental RFCs, Draft Standard RFCs,
or Standard RFCs (as appropriate).  IETF people who read industry
publications will have to educate the editors for those
publications solwly over time, but eventually the message will
get out.

This solution was applied to a similar problem, whereby people
would cite Internet Drafts in a way that implied IETF approval
or consideration.  Now, drafts are typically cited as "work in
progress".  That has helped a lot.

I don't claim that adopting my suggested requirement will solve
the whole problem, but it will help.  If adopted, this requirement
should be made into part of the boilerplate text.

Regards,
Charlie P.

> X-URI: http://www.cs.utk.edu/~moore/
> From: Keith Moore <[email-masked]>
> To: Scott Bradner <[email-masked]>
> cc: [email-masked], [email-masked]
> Subject: Re: the old "separate document series" argument 
> Date: Wed, 25 Aug 1999 13:39:08 -0400
> 
> > > You say that as if it contradicts the preceding words.
> > 
> > I say that if we want to additionally restrict the RFC series
> > we should decide to do so with great care
> 
> agree entirely.
>  
> > > On the contrary, historically the RFC editor exercised a lot of filtering.
> > 
> > as has the IESG - but there are a lot of RFCs publiched that
> > vendors mislead their potential customers with yet they are potentially
> > useful to the Internet community
> 
> I assume we would handle these much the same way that we do now -
> if the information is useful to the community, publish with appropriate 
> modifications and/or disclaimers in place.
> 
> Keith
>

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 25 Aug 1999 21:01:36 +0100 (BST)

On Wed, 25 Aug 1999, Charles Perkins wrote:

> or Standard RFCs (as appropriate).

This is IMO a good idea. It's certainly not the first time it's been
suggested; for example, I most recently suggested such a change in
boilerplate text on August 16th at end of:

http://www.ietf.org/mail-archive/ietf/Current/msg05170.html

and presumably it's been suggested regularly over the past few years
by people thinking on similar lines.

L.

same old arguments in a whole new thread.

> IETF people who read industry

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 25 Aug 1999 21:01:36 +0100 (BST)

L.

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 16:44:21 -0400

> or Standard RFCs (as appropriate). 

doesn't seem to work...we have a difficult enough time educating
the press about less sutble things.

the only effective way to require that they be cited differently 
is to change their filenames and designations.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 16:44:21 -0400

Keith

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 14:26:44 -0700

>the press about less sutble things.

agreed.

>is to change their filenames and designations.

So we've come back to the idea of changing the labels.  This isn't 
evil.  There's no reason a document receiving an INF label should 
implies a different level of review than an Informational RFC does 
now.  It will reduce the ambiguity over the intended purpose of the 
document which is inherent in all of them being labeled RFCxxxx. 
Making a clearer distinction between kinds of documents could hardly 
hurt our current situation.

The application of RFC, INF, or EXP labels needs to be more carefully 
spelled out than in this discussion so far.  But that could surely be 
done in a revision to 2026.  Whether there is sufficient consensus 
around a such a proposal remains to be seen.  But there is no harm in 
making the attempt.

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 14:26:44 -0700

agreed.

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 17:59:58 -0400

> So we've come back to the idea of changing the labels. 

I didn't say I liked the idea. In fact, I'm strongly opposed to it.

I want to keep the RFC label for all kinds of RFCs. I think the
RFC name has too much market value to give up, and I think there are 
numerous high-quality informational and experimental documents that 
should be published in the same series as standards-track documents.

Mostly I want to get IESG out of the game of spending lots of effort 
(often more effort than is required for any standards-track documents) 
doing exhaustive review and criticism, and sometimes editorial work, 
trying to improve really bad non-working-group drafts to the point 
that we can tolerate their publication as RFCs, because we know that 
(at least for certain drafts) they may be published even over IESG 
objections.  It's one thing to go to this level of effort for working 
group documents, and quite another to do it for individual submissions 
that have no visible community support.

Don't get me wrong; I *like* the fact that there's a path around IESG
to RFC publication.  I don't think that IESG should hold all of the cards.
But I think - based on the past few years experience with the current
process - that this path might need a bit of tweaking. For instance, 
it might be desirable to impose slightly higher quality requirements than
has been done in the past.  

I also don't think that the alternate publication path should be able 
to circumvent established policies for parameter assignment.  If IESG 
feels that a document should not be published because it contradicts
assignment policies (including parameters that require IESG approval
for such assignment), the alternate path to registration (and therefore 
publication of the document) should be the normal IETF appeals process 
documented in 2026 section 6.5.

Keith

p.s. note that I do not consider the tv: document to be in the category
of "really bad drafts"...despite the numerous negative comments on the 
document I'm optimistically thinking that there's room for consensus-
building on this one.  Having consensus on a tv: URL would clearly 
be a major win, so I hope we pull it off.

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 17:59:58 -0400

Keith

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 15:30:25 -0700

>should be published in the same series as standards-track documents.

To make sure I understand you, you're saying that a label other than 
RFC is by definition inferior.    Therefore you're opposed to the 
idea that valuable documents would be considered inferior because of 
their label.  I'll allow that could be the result, but it need not 
be.  I'm not suggesting giving up the RFC label for standards track 
documents.  I heartily agree that RFC has considerable market value. 
It is because it does we're having the current debate.  Preserve RFC 
for standards track by all means!

I'd be content to let the reader decide if the content is useful or 
not (As others have noted, they regard certain documents labeled RFC 
as half-baked).  The label itself doesn't confer any more utility 
than does the document's contents.

However, a label can be a clue to the document's intended purpose. 
That can be a valuable aid to someone perusing the library of IETF 
documents for information on their topic of interest.

Consider your local library.  Do you think library users would 
benefit if BK were used instead of  FIC and NF?  After all, both 
fiction and non-fiction volumes are books.  Surely some of those are 
better than others.   Can that be deduced from the label FIC or NF?

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 15:30:25 -0700

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 15:36:49 -0700

>that have no visible community support.

In a perfectly congenial society where everyone adheres to the 
labeling of documents as standards track vs informational vs playful 
vs curiousity vs etc, labeling by the editor/author can be used by 
the IESG	to prioritize their work.  To the extent we are not a 
congenial society, this won't help.  But neither would any other 
approach.

The IESG will still be faced with documents of questionable value. 
However, I do believe the IETF is more congenial than not, so the 
IESG benefits from labels offered by the authors.

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 15:36:49 -0700

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 22:09:37 -0400

> RFC is by definition inferior. 

no, this isn't it at all.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 22:09:37 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 23:19:36 -0400

> the IESG  to prioritize their work. 

no, this wouldn't help in the slightest.  

the problem is not that IESG cannot easily discern the author's 
intended seriousness of the document, or that it cannot 
prioritize its work. (though part of the problem is that the IESG
cannot ignore the threat of having bogus documents published)

the problem that I'm concerned about is that the IESG occasionally 
has to review documents which are written by people with apparent 
intelligence yet low clue density.   those are the hardest to refute 
because to a casual reader it looks like the author knows what he's 
talking about. even if it's obvious to an expert that the proposal
is not sound, it takes a lot of work by busy people to demonstrate 
to non-experts that the proposal is not sound.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Aug 1999 23:19:36 -0400

Keith

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 20:22:41 -0700

>no, this isn't it at all.

What am I missing?  You say you want to keep the RFC label for all 
kinds of RFCs.  Consider the plight of someone trying to learn about 
some  RFC who hasn't been schooled in the IETF mysteries.  Say you're 
a new reporter who's been assigned to cover a story on XYZ company's 
hot new Internet product.  You've read the press release which says 
their product supports RFCxxxxx.  What indication is there on the 
IETF website that RFCxxxx is an Informational RFC?  None.  Maybe you 
take the time to download the RFC, 'cause you know you ought to at 
least scan it.  If you read the RFC you might notice its status in 
Informational.  But you're a reporter-in-a-hurry...the editor just 
said you have 15 minutes to make the deadline...you don't have the 
time....you write the story based on the press release. (Oh, this 
never happens...)

Did you do a bad job on the story?  From the IETF point of view, you 
sure did.  The market value of the RFC label paid off handsomely  - 
for company XYZ.  Not so for the IETF...

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 20:22:41 -0700

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 21:02:20 -0700

>to non-experts that the proposal is not sound.

No labeling isn't likely to help the IESG in this regard.  Nothing 
will stop this from happening.  I suppose this is part of the joy of 
being an AD...

But don't you think the collected wisdom and effort by the IESG 
couldn't be signaled to the casual readership by invoking the BOZO 
category? <grin>  Or maybe you just label them INT for Interesting 
(That's how a theater director friend once told me he described 
particularly disastrous auditions to the unlucky performer...).

---

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 25 Aug 1999 21:02:20 -0700

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Aug 1999 00:14:01 -0400

> What am I missing?  

the problem you describe is not the one I'm trying to solve,
and the cost of your solution to the problem you are trying
to solve, in my opinion, is not worth the benefit.

as for the example you gave, I don't think there's any way to
significantly increse the clue density of the trade press.  
(though the '15 minutes to make a deadline' phenomenon is 
definitely part of the problem.)  and even if you give the
trade press a marginal clue increase, there is absolutely
nothing that will stop a marketroid from making bogus claims.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Aug 1999 00:14:01 -0400

Keith

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 26 Aug 1999 01:07:59 -0400 (EDT)

> for company XYZ.  Not so for the IETF...

Color me naive, but, doesn't the IETF have *some* responsibility for
"marketing" itself and its practices if it expects to have anyone give a
damn? That is, if it's so important to *us* that there's a difference
between Standards track, Informational, BCP, and Experimental, shouldn't
we be writing letters to the editor and guest editorials and so forth as
often as we possibly can? 

I'm pretty certain that it's not hard to get a few column inches in the
average trade rag. They really *like* content, especially content from the
clueful. And a few of us know a few of those harried reporters and can
give them some insight.

It doesn't really take changing *everyone's* worldview outside of the IETF
world. Just getting the message out in a few key places, through a few
key, visibile reporters ought to catch the eye of some of those other
reporters hoping to be more like them, and so forth...

Anyway, though I fully agree that marketroids are a blight on pleasant
society, it is completely within our power to make change here. I think,
though, that in order to do this, we need to reach "rough consensus" on
just what the heck the 'Informational', 'Standard', 'Best Current
Practice' and 'Experimental' labels mean these days, and what it means
when 'Informational' RFCs might as well be standards because they're so
pervasive (the PPP examples mentioned earlier).

If we are, ourselves, confused, how can we expect the hapless reporter and
consumer not to be?

--
   Tripp Lilley  *  [email-masked]  *  http://stargate.sg505.net/~tlilley/
------------------------------------------------------------------------------
   Perl is the preferred programming language of the Libertarian Party,
   Python that of the Democratic Party, and C that of the Republican Party.

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 26 Aug 1999 01:07:59 -0400 (EDT)

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 26 Aug 1999 01:22:39 -0400 (EDT)

> nothing that will stop a marketroid from making bogus claims.

But you *can* arm the public against such claims. In both cases (that of
the marketroid making bogus claims, and that of the IETF arming the public
against those claims), your best weapon is that trade press in the middle.

I can see it now:

For Immediate Release -- August 25, 1999, Reston, VA

The IETF Secretariat, in partnership with the IETF membership at large,
today began its "consumer reeducation campaign", intended to help
consumers of Internet-related products understand the process by which
technologies are standardized by the IETF.

"Many consumers are aware that the IETF works very hard to develop and
standardize good, robust solutions to internetworking problems," said
Tripp Lilley, IETF list member and occasional commentator, "but few
understand that the IETF *also* documents existing practices and 'de
facto' standards, whether or not they are best-of-breed technology."

Lilley further explains that "the IETF draws subtle distinctions between
these 'Standards' and 'Informational' documents, and from time to time
vendors' marketing efforts have exploited these subtleties, relying on the
public's relative ignorance of the IETF's standardization process."

The "consumer reeducation campaign" is a focused educational effort by the
IETF to help the information technology decision-maker wade through
marketing hype and understand the real engineering significance of IETF
document designations.

"Our hope," says Lilley, "is that an educated public will respond to these
vendor assertions with critical analysis, and pointed questions about the
exact nature of 'IETF involvement' being claimed."

The IETF is the foremost international body governing standards creation,
evaluation, and deployment in the Internet. Formed in the 1960s as an
informal group of researchers working on the then-ARPA Net, the IETF has
shepherded the growth of the ARPA Net into today's Internet, the modern,
pervasive communications infrastructure that has revolutionized the way
people interact personally and professionally.

See? It's not that terribly hard to turn their own weapons against them.
Now, you clean this up for accuracy (get the dates right, flesh out some
of the blurbs, give me a few more quotes), and we fax this out to all of
the rags. I *guarantee* you we get mention in the press. Then we bomb them
again with more "announcements" and such, especially right around the
Interop special issues.

Marketing isn't rocket science. That's why they let marketers be in charge
of it.

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 26 Aug 1999 01:22:39 -0400 (EDT)

I can see it now:

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Wed, 25 Aug 1999 23:20:17 -0700 (PDT)

Hi,

I'd be more than happy to publish an in-depth article in IPJ explaining
the mysteries of the IETF and its documents/standards if anyone would like
to volunteer to write such. I've got 5,000+ readers plus an unknown number
reading IPJ on-line, most of whom are (hopefully) technically savvy
individuals. It may not be "the world," but it's a start.

Ole

Ole J. Jacobsen 
Editor and Publisher
The Internet Protocol Journal
Tel: +1 408-527-8972
e-mail: [email-masked]
URL: http://www.cisco.com/ipj

VP for Chapters, The Internet Society.

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Wed, 25 Aug 1999 23:20:17 -0700 (PDT)

Hi,

Ole

Ole J. Jacobsen 
Editor and Publisher

---

From: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 07:34:43 +0100

The Chinese have a proverb (don't they always):

"He who knows, but does nothing doesn't really
know"

The argument here (or should I say debate?) is not
about the IETF marketing itself or making money
for its services or maybe losing money for
providing its services, but about the process of
providing its services / expertise without any
tangible show of having done anything.

The IETF is a great organisation manned by some
very dedicated people with a great technical
insight into issues, but as most technicians are
sh*t at promoting itself.  The IETF is not a
marketing organisation, it is a technical
standards organisation and as such performs a
brilliant function for constant criticism.

The UK standards / patent office provide their
certification for a fixed fee, this is none
negotiable.  If the issue is money then the
promotion of RFC's (draft standards) from
companies / organisations wishing to provide
interactive services to the masses could pay for
the privilage of having the IETF certification
awarded to their standard.

I don't see how this could really work and the
process would become over burdened with
administration.  The idea of donations /
sponsorship would provide funds for the IETF to
continue its function and still allow it to remain
totally clean from any suggestion of marketing
bias that can creep into "funded  organisation"

Lets keep personal remarks off this list and
concentrate on the work in hand.  Remember press
releases can be interpreted many different ways be
many different people.

That's my 2cents worth, now to put the rest of the
world to rights (or maybe just eat another candy
bar).

Regards

Mark Paton CEO/DIR. Internet Network Eng
Mercury Network Systems Limited
http://www.mnsl.org

"Mercury Network Systems - The Unstoppable Force"

-----Original Message-----
From: Tripp Lilley [mailto:[email-masked]]
Sent: 26 August 1999 06:08
To: John W. Noerenberg
Cc: Keith Moore; Charles Perkins;
[email-masked]; [email-masked];
[email-masked]
Subject: Re: the old "separate document
series" argument

> for company XYZ.  Not so for the IETF...

Color me naive, but, doesn't the IETF
have *some* responsibility for
"marketing" itself and its practices if
it expects to have anyone give a
damn? That is, if it's so important to
*us* that there's a difference
between Standards track, Informational,
BCP, and Experimental, shouldn't
we be writing letters to the editor and
guest editorials and so forth as
often as we possibly can?

I'm pretty certain that it's not hard to
get a few column inches in the
average trade rag. They really *like*
content, especially content from the
clueful. And a few of us know a few of
those harried reporters and can
give them some insight.

It doesn't really take changing
*everyone's* worldview outside of the IETF
world. Just getting the message out in a
few key places, through a few
key, visibile reporters ought to catch
the eye of some of those other
reporters hoping to be more like them,
and so forth...

Anyway, though I fully agree that
marketroids are a blight on pleasant
society, it is completely within our
power to make change here. I think,
though, that in order to do this, we need
to reach "rough consensus" on
just what the heck the 'Informational',
'Standard', 'Best Current
Practice' and 'Experimental' labels mean
these days, and what it means
when 'Informational' RFCs might as well
be standards because they're so
pervasive (the PPP examples mentioned earlier).

If we are, ourselves, confused, how can
we expect the hapless reporter and
consumer not to be?

--
   Tripp Lilley  *  [email-masked]  *
http://stargate.sg505.net/~tlilley/
------------------------------------------
------------------------------------
   Perl is the preferred programming
language of the Libertarian Party,
   Python that of the Democratic Party,
and C that of the Republican Party.

---

From: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 07:34:43 +0100

Regards

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 26 Aug 1999 02:46:36 -0400 (EDT)

> tangible show of having done anything.

I never meant to imply that the IETF should "charge" for anything. I meant
only to suggest that it might be worth the time for some of us to take on
the task of educating the public about what we do. I simply offered that
it might work very well to co-opt the very mechanisms the "marketroids"
use to purvey their wares.

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 26 Aug 1999 02:46:36 -0400 (EDT)

---

From: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 08:04:03 +0100

Re: the old "separate document series" argumentJohn,
Surely no self respecting journalist or technician would be fooled by any
organisations claims that they comply to RFCXXXX without first downloading
it and checking it out fully.

Change is good for the right reasons and not for changes sake.
Regards

  -----Original Message-----
  From: John W. Noerenberg [mailto:[email-masked]]
  Sent: 26 August 1999 04:23
  To: Keith Moore
  Cc: Charles Perkins; [email-masked]; [email-masked];
[email-masked]

  What am I missing?  You say you want to keep the RFC label for all kinds
of RFCs.  Consider the plight of someone trying to learn about some  RFC who
hasn't been schooled in the IETF mysteries.  Say you're a new reporter who's
been assigned to cover a story on XYZ company's hot new Internet product.
You've read the press release which says their product supports RFCxxxxx.
What indication is there on the IETF website that RFCxxxx is an
Informational RFC?  None.  Maybe you take the time to download the RFC,
'cause you know you ought to at least scan it.  If you read the RFC you
might notice its status in Informational.  But you're a
reporter-in-a-hurry...the editor just said you have 15 minutes to make the
deadline...you don't have the time....you write the story based on the press
release. (Oh, this never happens...)

  Did you do a bad job on the story?  From the IETF point of view, you sure
did.  The market value of the RFC label paid off handsomely  - for company
XYZ.  Not so for the IETF...

---

From: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 08:04:03 +0100

-----Original Message-----
  From: John W. Noerenberg [mailto:[email-masked]]
  Sent: 26 August 1999 04:23
  To: Keith Moore
  Cc: Charles Perkins; [email-masked]; [email-masked];
[email-masked]

---

From: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 08:04:15 +0100

You edited my point to make yours, the following
lines explains why the IETF comes under constant
criticism for providing it services.

"The IETF is a great organisation manned by some
very dedicated people with a great technical
insight into issues, but as most technicians are
sh*t at promoting itself.  The IETF is not a
marketing organisation, it is a technical
standards organisation and as such performs a
brilliant function for constant criticism."

By editing and taking comments out of context the
end game changes.  Human nature must explain and
take the blame for this process.

Re-education is great thing for those willing to
be re-educated.

Regards

-----Original Message-----
From: Tripp Lilley [mailto:[email-masked]]
Sent: 26 August 1999 07:47
To: mark.paton
Cc: John W. Noerenberg; Keith Moore;
Charles Perkins; [email-masked];
[email-masked]; [email-masked]
Subject: RE: the old "separate document
series" argument

> tangible show of having done anything.

I never meant to imply that the IETF
should "charge" for anything. I meant
only to suggest that it might be worth
the time for some of us to take on
the task of educating the public about
what we do. I simply offered that
it might work very well to co-opt the
very mechanisms the "marketroids"
use to purvey their wares.

--
   Tripp Lilley  *  [email-masked]  *
http://stargate.sg505.net/~tlilley/
--------------------------------------------------
----------------------------
   Perl is the preferred programming language of
the Libertarian Party,
   Python that of the Democratic Party, and C that
of the Republican Party.

---

From: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 08:04:15 +0100

Regards

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Aug 1999 11:46:47 +0100

>is to change their filenames and designations.

We could change the filenames to include the designation
	RFC2657-Experimental.txt
	RFC2664-Informational.txt 
	RFC2673-Proposed-Standard.txt
maybe? Sure it's ugly, but it makes the status really clear to anyone who
bothers to download the RFC...

Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Aug 1999 11:46:47 +0100

Colin