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

From: Scott Bradner <[email-masked]>
Date: Wed, 25 Aug 1999 10:40:12 -0400 (EDT)

> the real problem we are seeing is that there is a persistent belief
> that the RFC series is open to all comers regardless of the quality
> of their submissions or their applicability to the Internet.  we need
> to put a stake in this one and state very clearly and publically
> that this is not the case.

in the 30 years that the RFC series has run it has always been the case
that an independent person could get an RFC published if the RFC Editor
frlt it was a contribution to the Internet community - I think we
have to think very hard if we want to change this.

Scott

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 25 Aug 1999 09:13:34 -0600 (MDT)

> From: Scott Bradner <[email-masked]>

> have to think very hard if we want to change this.

You say that as if it contradicts the preceding words.  
On the contrary, historically the RFC editor exercised a lot of filtering.

To put it another way, do you read the I-D announcements?  Did you see
the one that came through today that made me wonder if today is April 1?

It's hard to believe that any IETF regular who thinks there is no problem
is paying much attention to the stream of RFC's and I-D's outside their
personal interests.

Vernon Schryver    [email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Wed, 25 Aug 1999 12:28:45 -0400 (EDT)

> 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

> 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

Scott

---

From: [email-masked]
Date: Wed, 25 Aug 1999 10:57:51 -0700

*> 
  *> You say that as if it contradicts the preceding words.  
  *> On the contrary, historically the RFC editor exercised a lot of filtering.
  *> 

Vernon,

Actually, I have questioned Joyce Reynolds on this point.  On her
evidence, and based on what I have heard the primordial RFC Editor Jon
Postel himself say, I believe that he did NOT do a lot of filtering.
That is, while he applied a lot of understanding and intelligence to
the decision on every RFC, it was a point of principle for him to err
on the side of publication of "crazy ideas" -- by which he meant ideas
that might be out of the mainstream of current thought but were
responsible and not ignorant.  He took an essentially academic
viewpoint on RFC publication (since he WAS an academic).

Jon also believed strongly that the RFC series could perform
a valuable service to the Internet community by providing ready access
to alternative ideas.  For example, he put effort into publishing OSI
documents as RFCs, openly available to all, even though OSI was the
"enemy".  He also believed in the importance of intelligent and
accurate documentation of important protocols, even if they were
not exactly correct or perfect.  I suspect he would have published
draft-zigmond-tv-url-02 in a moment, in the absence of evidence
that it was intended as an end-run around the IETF, believing that
to do so would be overall a service to the larger Internet community and
in the long run.

Since the beginning of the IETF in the mid 1980s, Jon's policy on
(almost) free publication has been in collision with the "real" world
of the IETF and with the IETF chair, who kept pointing out that some
uninformed people treat all RFCs as standards.  This collision
continues, as is evident from the current discussion.

Bob Braden

---

From: [email-masked]
Date: Wed, 25 Aug 1999 10:57:51 -0700

*> 

Vernon,

Bob Braden

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Wed, 25 Aug 1999 12:58:32 -0500 (CDT)

>but there are a lot of RFCs publiched that

No matter how many different levels of publication we adopt, vendors will always 
be able to mislead the public so long as the public are not familiar with the 
details of what each of these levels represents.  In fact, I would argue that 
the more different types of documents we issue, the greater the potential for 
misrepresentation by unscrupulous vendors (I think, or at least I hope, that 
these are in the decided minority).  Rather than trying to wrestle with just how 
authoritative to make IETF publications, perhaps it would be more productive to 
embark on an aggressive campaign of education.  The more non-IETF participants 
know about our mission and mechanisms, the less likely they are to be fooled by 
distorted claims.

This education is one of the goals of the WEIRD wg, as I understand it.

RGF

Robert G. Ferrell
Internet Technologist
National Business Center, US DoI
[email-masked]
**********************************
**** I hack, therefore I am ******
**********************************

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Wed, 25 Aug 1999 12:58:32 -0500 (CDT)

RGF

Robert G. Ferrell
Internet Technologist

---

From: [email-masked]
Date: Wed, 25 Aug 1999 11:11:10 -0700

*> but this is secondary to our primary mission.  we don't need to waste 
  *> our time trying to justify publishing, or not publishing, half-baked
  *> ideas.
  *> 
  *> Keith
  *> 
  *> 

Keith,

Absolutely no argument about the primary mission.

For the rest, the problem is agreeing on what is "half-baked".  There
are some well-known, very widely used Internet protocols that I
personally consider half-baked, but clearly this opinion is
irrelevant.  One could pick out a lot of RFCs that at the time of
publication were known to be half-baked (eg RFC 1009 in my own closet),
as well as many, many others whose half-bakedness was revealed in
time.

Half-baked lies somewhere on the line between "dumb" and "mature".  Jon
rejected the dumb ones and published everything else.  The current RFC
Editor organization is attempting to move a little on the line towards
mature, but not too far.

Bob Braden

---

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
> 
> agree entirely.
> 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: Vernon Schryver <[email-masked]>
Date: Wed, 25 Aug 1999 15:19:28 -0600 (MDT)

> Why exactly do you think that this draft (bizarre as it is) indicates a
> problem? (Your previous appeal to Gresham's Law was not convincing; ideas are
> not coins.)

Yes, Gresham's law is nominally about things that are fungible.  Ideas
are not fungible, and contrary to what Dilbert's manager wishes, neither
are the people who have them, but they are driven away by dross.

If you have a good idea and want to take it public, which would you choose
and why:
   - ITU, ANSI, or IEEE
  - netnews
  - IETF 
  - private WWW pages.

Now answer the same question 5, 10, and 15 years ago, (of course withough
WWW pages).

On Wed, 25 Aug 1999, Charles Perkins wrote:

] 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).

Exactly how would requirement be implmented?   How would you punish or
even educate the vast majority who would not merely fail to comply, but
never even hear about the requirement.  For example, have you noticed that
the experts think that RFC 1990 defines a protocol named "MLPPP", most
people think it is named "MPPP," and practically no one knows the name
given in the title of the RFC?

} From: [email-masked]

} Actually, I have questioned Joyce Reynolds on this point.  On her
} evidence, and based on what I have heard the primordial RFC Editor Jon
} Postel himself say, I believe that he did NOT do a lot of filtering.
} That is, while he applied a lot of understanding and intelligence to
} the decision on every RFC, it was a point of principle for him to err
} on the side of publication of "crazy ideas" -- by which he meant ideas
} that might be out of the mainstream of current thought but were
} responsible and not ignorant.  He took an essentially academic
} viewpoint on RFC publication (since he WAS an academic). ...

Do you look at the I-D announcements?  What do you think all of this
morning's crop?

I have yet another idea to fix this problem that only I see.  Let's have
more I-D's and RFC's like this morning's that finds "5.46 * 10^9" addresses
in a 32-bit value.  Two or three of those every day would soon end the
appetite of even the worst marketoons for an I-D or RFC.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 26 Aug 1999 00:05:06 -0500

Hi, John,

Sometimes I think I'm only visiting this planet (and I'm NOT complaining),
but my copy of RFC 2026 says, and I quote:

3.  INTERNET STANDARD SPECIFICATIONS

   Specifications subject to the Internet Standards Process fall into
   one of two categories:  Technical Specification (TS) and
   Applicability Statement (AS).

3.1  Technical Specification (TS)

   A Technical Specification is any description of a protocol, service,
   procedure, convention, or format.  It may completely describe all of
   the relevant aspects of its subject, or it may leave one or more
   parameters or options unspecified.  A TS may be completely self-
   contained, or it may incorporate material from other specifications
   by reference to other documents (which might or might not be Internet
   Standards).

I would have thought that the last line says that a Technical Specification
can be an Internet Standard even if it refers to a document that isn't an
Internet Standard.

(1) Have I yet again been confused on the IETF standards process?

(2) When I hear a topic LIKE this being discussed, it is most often the
requirement that RFCs can't have normative references that are still I-Ds,
so periodically there's an RFC published that releases other RFCs. Could
this be what you were remembering?

Spencer

> -----Original Message-----
> From:	John W. Noerenberg [SMTP:[email-masked]]
> Sent:	Wednesday, August 25, 1999 4:36 PM
> To:	Keith Moore
> Cc:	Theodore Y. Ts'o; [email-masked]
> At 9:34 AM -0400 8/25/99, Keith Moore wrote:
> > > Creating a new archival series for informational and/or experimental
> >> RFC's, such as INF-12345 or EXP-12345 as some have suggested, makes it
> >> impossible for some vendor to try to publish some propietary protocol
> as
> >> an informational RFC
> >
> >problem is, there are informational and/or experimental documents
> >that legitimately belong in the RFC series - because they are
> >working group documents that are companions to standards track
> >RFCs, or because they are reviewed and are believed to be of
> >high quality.
> 
> There seems to be a tacit assumption in this argument that INF or EXP 
> labels are inferior to RFC labels.  Dunno if that has to be true.  Is 
> there some reason a standards track document can't refer to an 
> Informational RFC?  A standards track document can't depend on a 
> non-standards track document, but it's not clear that 2026 prohibits 
> references to non-standards track RFCs.
> 
> john noerenberg
> [email-masked]
>    ----------------------------------------------------------------------
>    The man that can most truly be accounted brave is he who best
>    knows the meaning of what is sweet in life and what is terrible,
>    and then goes out undeterred to meet what is to come.
>    -- Pericles, "Funeral Oration", 479 B.C.
>    ----------------------------------------------------------------------
> 
> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Harald Alvestrand.

---

From: Scott Bradner <[email-masked]>
Date: Thu, 26 Aug 1999 07:56:56 -0400 (EDT)

Tripp suggests PR

see http://golem.sobco.com/nww/1997/34-misleading.with.ietf.html

and yet my own paper (Network World) can not seem to get it right

Scott

---

From: Scott Bradner <[email-masked]>
Date: Thu, 26 Aug 1999 07:56:56 -0400 (EDT)

Tripp suggests PR

Scott

---

From: Scott Bradner <[email-masked]>
Date: Thu, 26 Aug 1999 08:02:46 -0400 (EDT)

Mark asserts
> 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.

there must be a lot of journalists out there that have low self respect

Scott

---

From: Scott Bradner <[email-masked]>
Date: Thu, 26 Aug 1999 08:02:46 -0400 (EDT)

Mark asserts

Scott

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 26 Aug 1999 13:29:43 +0100

Why not making it part of the boilerplate?

(only half joking)

> ----------
> From: 	Scott Bradner[SMTP:[email-masked]]
> Sent: 	26 August 1999 12:56
> To: 	[email-masked]

---

From: Charles Perkins <[email-masked]>
Date: Thu, 26 Aug 1999 08:30:17 -0700 (PDT)

Hello Keith,

>> or Standard RFCs (as appropriate). 
> 
> doesn't seem to work...we have a difficult enough time educating
> the press about less sutble things.

Maybe there isn't one single thing that will "work".

But if we wait around until we find the magic bullet that will
solve all our problems with no pain, we may never accomplish
the goal.

I suggest taking small, easy steps that make sense, and then
continuing to look for the next small, easy step.

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

Internet Drafts and RFCs are often cited already by title, not
by filename.  Nevertheless, I agree that changing filenames
may be worth considering.

Regards,
Charlie P.

=============================================================

I am changing my affiliation.  My new e-mail address will be:
		Charles E. Perkins <[email-masked]>
I am also reachable at <[email-masked]>

=============================================================

---

From: Scott Bradner <[email-masked]>
Date: Thu, 26 Aug 1999 17:48:31 -0400 (EDT)

John asks

>>> Note: Standards track specifications normally must not depend on other
>>> standards track specifications which are at a lower maturity level or on non
>>> standards track specifications other than referenced specifications from
>>> other standards bodies.  (See Section 7.)
>>
>>Or am I misreading it somehow?
>
>I'm looking at "depends".  If an informational document doesn't make
>requirements on a standards-track document, then it seems to me a
>reference by a standards-track doc to an informational one is
>allowable.  But, so far, this is only my interpretation.  I'll feel a
>lot more comfortable if others read it the same way I do.
>Unfortunately, your remarks, John, don't improve my comfort. <grin>
>A word from Scott here regarding the 4.2.4's intent could help. 

the intent was to talk about "normative" references - references where
the knowledge of the referenced document is required to properly implement
the technology.  If the referenced document is just referenced for
information and backgroud and one could implement the technology without
reading the referenced document then that is not a normative reference
and does not trigger the words in 4.2.4

Scott