Subject: RE: draft-zigmond-tv-url-02

From: Vernon Schryver <[email-masked]>
Date: Tue, 24 Aug 1999 16:29:36 -0600 (MDT)

> From: Glen Zorn <[email-masked]>

> ...
> > This is attractive, I admit.  But I concur with Keith's remarks about 
> > the tacit approval publication confers.  Conversations with people 
> > who possess only a cursory understanding of IETF procedures 
> > demonstrate to me that assignment of an RFC number is often 
> > misconstrued as perfection of a standard.
>
> Presumably these same people possess "only a cursory understanding" of the
> English language, since they apparently cannot understand the following
> sentences (appearing verbatim in the first paragraph of _every_
> Informational RFC): "This memo provides information for the Internet
> community.  It does not specify an Internet standard of any kind." 
> ...

Why people pay no attention to the words is irrelevant.  We all know
it's true, and can name several commercial outfits that have tried to exploit
that fact.  Moreover, some very important de facto standards have carried
such disclaimers.  Consider SLIP.

> ...
> Editorializing is unnecessary, as is "assessment of the practice".  Come
> on, people!  This is an _Informational_ submission.  If the _information_
> provided is incorrect or unclear, then correct it.  Otherwise, publish the
> damn thing and quit wasting space in my Inbox.

That's disingenuous.  If the only issue were "submission," no one would
care.  The draft could be submitted directly to the RFC editor's /dev/null.
Instead, the issue is the publication by the IETF of a document that
10,000,000 people will understand as an official legal standard.  Whether
the hordes are right, wrong, stupid, or smart is irrelevant.  We all know
what they will do.

> ...
> The obvious answer to this problem is to educate the public, rather than
> to suppress information on how things are done.

You mean like many big companies "educate the public"?  Out of politeness
to Mr. Zorn and his assumed his good will, I'm trying not to mention
certain other educational documents that were famous, labeled "RFC,"
documented incompatible and entirely unnecessary changes to IETF PPP
standards, and were never even seen by the RFC editor, but it is a strain.
I think those particular documents were produced and published through
ignorance instead malice or conscious "embrace and extend" policies, but
the point remains that reality is what it is, not what it should be in
some theories.

>                                                              rather than
> to suppress information on how things are done.

"Suppress information"?  So if an Information RFC is not published,
the security officers from the Office of RFC Editor will make rounds,
purging disks and sending people to camps for re-education?--wow.

Seriously, exactly what would happen if the draft were not published?
What would work worse?  Since this is about an old, established practice,
what's the big deal in the real world?  Since it is an old, established
practice, anyone trying to be compatible with it would treat any RFC as
at most a supplement, and look elsewhere for the authoritative
specifications.

Vernon Schryver    [email-masked]

---

From: Glen Zorn <[email-masked]>
Date: Tue, 24 Aug 1999 17:44:25 -0700 (PDT)

> such disclaimers.  Consider SLIP.

I claim that _the fact_ that people pay no attention to the words is
irrelevant.  The reality is that neither you, I nor the IESG can prevent
the Slimy Marketroids (TM) from misleading their would-be prey -- only the
prey can do that.  I refuse responsibility for other people's intellectual
laziness, and I don't think that we should change the way we do things to
accomodate it, either.  Internet-Drafts are also claimed to be "Internet
Draft Standards" in literature I've seen, etc.  On second thought, I guess
that there _is_ a way to stop the abuse of the RFC: abolish I-Ds, BCPs and
all forms of RFC other than Standard.  That's not a direction I'd like to
go, though...  

> 10,000,000 people will 

mis-

> understand as an official legal standard.  Whether
> You mean like many big companies "educate the public"?  

Maybe.  Perhaps the people who (obviously) _don't_ read the RFCs _do_ read
"Network World"...

<text excised>

> -
> 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: Glen Zorn <[email-masked]>
Date: Tue, 24 Aug 1999 17:44:25 -0700 (PDT)

mis-

<text excised>

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 25 Aug 1999 00:56:06 -0400

Date: Tue, 24 Aug 1999 17:44:25 -0700 (PDT)
   From: Glen Zorn <[email-masked]>

   Draft Standards" in literature I've seen, etc.  

While in principal I agree with you that there is no defense against
other people's stupidity, I don't think that giving up is the
appropriate in response to Slimy Marketroids (tm).  That's equivalent of
telling the Linux folks and the Apple folks to give up and go home in
the face of Microsoft's mighty marketing machine, since Microsoft's
victory over the desktop is inevitable.

You face and fight evil, you don't give in to it or accomodate it.  It's
a lot harder for Slimy Marketroids to abuse Internet-Drafts because in
order to reference them, they have to use a cumbersome name that begins
draft-*.  The problem with informational RFC's is that it's not obvious
from the name, "RFC 12345" that there's anything that differentiates it
from the draft standard "RFC 12354".  This makes it *much* easier for
Slimy Marketroids to confuse the hapless consumer --- and maybe we
should do something about it.

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, and then start referencing it using the RFC number
to gain legitimacy in the marketplace.  To the extent that this sort of
thing happens, those vendors are gaming the system, and our rolling over
and letting them steamroller the IETF doesn't seem like the appropriate
response. 

It's not perfect, no.  But I think it will prevent a number of abuses. 

						- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 25 Aug 1999 00:56:06 -0400

- Ted

---

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

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

so I'm not sure that the dividing line should be informational/experimental
vs. standards-track/BCP, but rather "reviewed" vs. "unreviewed".

and were we create a separate series for the unreviewed documents,
I have to wonder why we would bother spending much effort to
publish them.  the RFC Editor is a nontrivial expense, and IETF
needs to be careful about where it spends its money.  should
it really spend significant amounts of money publishing a series
of unreviewed documents?

so I think the right answer is just to say that the RFC series
is a reviewed document series.  in order to preserve the value
of the series, we try to keep its documents of reasonably high 
quality, which means that we *don't* necessarily agree to publish 
every half-baked idea that comes along.  these days, the web 
makes it easy for anyone to publish anything, so there's no need
for the RFC series, or any other document series produced by IETF,
to fill that role. 

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.

Keith

p.s. as it turns out, we already have a series of unreviewed documents.
they're called Internet-Drafts.  they expire in six months, which
has a number of useful properties:  it means that filtering is done
by the community at large, which has better scaling properties than 
having IESG or the RFC Editor do it.  it discourages people from
referencing them over the long term, which allows us to be unconcerned
about the quality of the documents in the series.  and it takes some 
pressure off of the RFC series to be a very-fast-track publishing 
mechanism - very old RFCs often did consist of half-baked ideas, 
and deliberately so, but nowadays we have a higher standard for RFCs 
and Internet-Drafts have taken up a lot of the slack.

---

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

Keith

---

From: Glen Zorn <[email-masked]>
Date: Wed, 25 Aug 1999 13:22:34 -0700 (PDT)

> victory over the desktop is inevitable.

Although your last statement is tautological :-), I don't think that
I'm suggesting that we surrender, rather that we attempt to better arm one
side of the combatants.  If the problem is that people don't understand
the classification of RFCs, let's educate them.  

> draft-*.  

Well...most references to Internet-Drafts I've seen in marketing/sales
literature don't even name the document, instead relying upon linguistic
subterfuge (or outright lies) to obtain the desired effect.  

> The problem with informational RFC's is that it's not obvious

Note, however, that the "hapless consumer" is more likely in these cases
to be someone like Jeff Schiller (a network manager or decision-maker who
_should_ know better) than his grandmother (who probably doen't know RFC
from NBC).

> to gain legitimacy in the marketplace.  

The INF/EXP idea isn't _that_ horrible, I guess, though awfully
non-traditional.

> To the extent that this sort of

Brings up an interesting question: do we really know how often this stuff
happens?

---

From: Glen Zorn <[email-masked]>
Date: Wed, 25 Aug 1999 13:22:34 -0700 (PDT)

---

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

>RFCs, or because they are reviewed and are believed to be of

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

---

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

john noerenberg
[email-masked]

---

From: John Stracke <[email-masked]>
Date: Thu, 26 Aug 1999 10:39:58 -0400

"John W. Noerenberg" wrote:

> A standards track document can't depend on a

I think it does.  From section 4.2.4 of 2026:

> 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?

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: John Stracke <[email-masked]>
Date: Thu, 26 Aug 1999 10:39:58 -0400

---

From: "John W. Noerenberg" <[email-masked]>
Date: Thu, 26 Aug 1999 12:46:09 -0700

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

---

From: "John W. Noerenberg" <[email-masked]>
Date: Thu, 26 Aug 1999 12:46:09 -0700

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 26 Aug 1999 23:42:49 +0200

>Or am I misreading it somehow?

Note the "depend on" part. References are allowed, but only if it's 
possible to implement the protocol without reading the other document.
Lots of standards-track docs refer to informational documents. The 
references just have to be "non-normative".

                      Harald

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 26 Aug 1999 23:42:49 +0200

Harald

---

From: John Stracke <[email-masked]>
Date: Thu, 26 Aug 1999 17:50:45 -0400

> possible to implement the protocol without reading the other document.

Oh, of course.  Thanks!

---

From: John Stracke <[email-masked]>
Date: Thu, 26 Aug 1999 17:50:45 -0400

Oh, of course.  Thanks!