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

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]
> Subject:	Re: the old "separate document series" argument
> 
> 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: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 07:53:56 +0100

Spencer,
I think the onboard flight entertainment has
colored your memory it did mine!

I thought RFC2026 stated exactly what it did,
sh*t the interGalactic travel agency did'nt warn
me about loss of memory.

What was the topic?

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: Spencer Dawkins
[mailto:[email-masked]]
Sent: 26 August 1999 06:05
To: [email-masked]
Subject: RE: the old "separate document
series" argument

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:

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

   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

> >> RFC's, such as INF-12345 or
EXP-12345 as some have suggested, makes it
> references to non-standards track RFCs.
------------------------------------------
----------------------------
>    -- Pericles, "Funeral Oration", 479 B.C.
------------------------------------------
----------------------------
> Decisions on what to pass are made
solely by Harald Alvestrand.

-
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: "mark.paton" <[email-masked]>
Date: Thu, 26 Aug 1999 07:53:56 +0100

Spencer,

What was the topic?

Regards

-----Original Message-----
From: Spencer Dawkins

Hi, John,

Spencer

messages are passed.

-