I do think informational RFCs (both IETF and non-IETF) are valuable.
I would suggest though that their value is mostly NOT about ease of
access, archival, those great ASCII graphics, or any other practical
matter. The value is in our assessment of them being worthy of being
published as RFCs.
I fail to find any of the justifications in RFC 4846 all that persuasive.
Choosing a few examples:
...
Nowadays, vendors have web sites that describe their protocols.
These are frequent lines of argumentation against publishing anything other than
formal IETF documents. What they
On Sep 8, 2010, at 11:17 PM, Bob Hinden wrote:
Eric,
On Sep 8, 2010, at 1:05 PM, Eric Burger wrote:
I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT be
publishing! I can see the press release now: IETF publishes IPv6
transition plan. NO ONE OUTSIDE THE IETF
That's probably because RFC 2549 was the transitional document.
Richard Bennett
On Sep 8, 2010, at 7:34 PM, Kevin Fall kf...@cs.berkeley.edu wrote:
On Sep 8, 2010, at Sep 83:12 PMPDT, Richard Bennett wrote:
It seems to me that one of the issues here is that architecture models are
...@ietf.org] On Behalf Of Fred
Baker
Sent: Wednesday, September 08, 2010 9:49 PM
To: Eric Burger
Cc: IETF Discussion
Subject: Re: The Evils of Informational RFC's
Please, no.
The RFC Series is not a collection of standards. It is community memory, and
in it we have white papers that have been seminal
On Wed, Sep 8, 2010 at 11:03 AM, Eric Burger ebur...@standardstrack.com wrote:
Can we please, please, please kill Informational RFC's? Pre-WWW, having
publicly available documentation of hard-to-get proprietary protocols was
certainly useful. However, in today's environment of thousands of
On 9/8/2010 8:03 AM, Eric Burger wrote:
Can we please, please, please kill Informational RFC's?
...
why would we possibly ask ourselves to
shoot ourselves in the foot by continuing the practice of Informational RFC
publication?
wow. it's oddly fun to see you run off the rails like
On Sep 8, 2010, at Sep 83:12 PMPDT, Richard Bennett wrote:
It seems to me that one of the issues here is that architecture models are
published as Informational when they're clearly not in the same level of
authority as most Informational RFCs. An architecture document is meant to
guide
...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Fred
Baker
Sent: Wednesday, September 08, 2010 9:49 PM
To: Eric Burger
Cc: IETF Discussion
Subject: Re: The Evils of Informational RFC's
Please, no.
The RFC Series is not a collection of standards. It is community memory, and
in it we have
On 9/8/2010 3:12 PM, Richard Bennett wrote:
It seems to me that one of the issues here is that architecture models
are published as Informational when they're clearly not in the same
level of authority as most Informational RFCs. An architecture document
is meant to guide future work on
Bob == Bob Braden bra...@isi.edu writes:
Bob On 9/8/2010 3:12 PM, Richard Bennett wrote:
It seems to me that one of the issues here is that architecture
models are published as Informational when they're clearly not in
the same level of authority as most Informational RFCs. An
Sam:
Bob == Bob Braden bra...@isi.edu writes:
Bob On 9/8/2010 3:12 PM, Richard Bennett wrote:
It seems to me that one of the issues here is that architecture
models are published as Informational when they're clearly not in
the same level of authority as most
Can we please, please, please kill Informational RFC's? Pre-WWW, having
publicly available documentation of hard-to-get proprietary protocols was
certainly useful. However, in today's environment of thousands of
Internet-connected publication venues, why would we possibly ask ourselves to
At 11:03 AM -0400 9/8/10, Eric Burger wrote:
Can we please, please, please kill Informational RFC's?
Please, no.
Pre-WWW, having publicly available documentation of hard-to-get proprietary
protocols was certainly useful. However, in today's environment of thousands
of Internet-connected
On 8 sep 2010, at 17:03, Eric Burger wrote:
in today's environment of thousands of Internet-connected publication venues,
why would we possibly ask ourselves to shoot ourselves in the foot by
continuing the practice of Informational RFC publication?
Link rot.
On Sep 3, 2010, at 7:48 PM,
Can we please, please, please kill Informational RFC's?
I don't think it makes any sense to do so, the media, and even many in
the networking industry don't even understand the ones that are
standards, why we would expect a right on the money interpretation for
the rest ?
There will be always a
Eric,
On Sep 8, 2010, at 8:03 AM, Eric Burger wrote:
Can we please, please, please kill Informational RFC's? Pre-WWW, having
publicly available documentation of hard-to-get proprietary protocols was
certainly useful. However, in today's environment of thousands of
Internet-connected
I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT be
publishing! I can see the press release now: IETF publishes IPv6 transition
plan. NO ONE OUTSIDE THE IETF has a clue the RFC Editor is NOT the IETF.
RFC = IETF is the *reality*, no matter how much we say it is not.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Eric Burger
Sent: Wednesday, September 08, 2010 4:05 PM
To: Bob Hinden
Cc: IETF Discussion
Subject: Re: The Evils of Informational RFC's
I would offer RFC 5211 is PRECISELY the kind
s/Informational RFCs/independent stream/
If what you're after is RFC == IETF, shouldn't we be eliminating the
independent submission process instead of informational RFCs in
general. Things like RFC 3693 or draft-ietf-geopriv-arch, which don't
specify a protocol, but describe an
Eric,
On Sep 8, 2010, at 1:05 PM, Eric Burger wrote:
I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT be
publishing! I can see the press release now: IETF publishes IPv6 transition
plan. NO ONE OUTSIDE THE IETF has a clue the RFC Editor is NOT the IETF.
RFC =
I don't see what it is wrong with rfc5211, besides the IESG note
pointed by Ronald nowhere the text says that the transition plan is
IETF's plan or even that IT IS the plan.
It is an informational piece of text, and I guess anybody who can read
understands what is says starting with the abstract
On 2010-09-09 09:08, Richard L. Barnes wrote:
s/Informational RFCs/independent stream/
If what you're after is RFC == IETF, shouldn't we be eliminating the
independent submission process instead of informational RFCs in
general. Things like RFC 3693 or draft-ietf-geopriv-arch, which don't
Finally, we are an open community encouraging a diversity of views,
and
it's sometimes necessary (and often desirable) to publish material
from
the community that meets none of the above criteria. Hence the
Independent stream of RFCs. As everyone should know, the independence
of the
On 2010-09-09 11:25, Richard L. Barnes wrote:
Finally, we are an open community encouraging a diversity of views, and
it's sometimes necessary (and often desirable) to publish material from
the community that meets none of the above criteria. Hence the
Independent stream of RFCs. As everyone
FWIW, I'm not at all confused by the various RFC streams
and see no negatives and some positives in their existence.
So let's keep it as-is please.
Stephen.
PS: I know of no evil RFCs but would welcome contrary
opinions (not including rfc3514's version of evil). Maybe
there are, recently, one
On Thu, 9 Sep 2010, Brian E Carpenter wrote:
In one word: archival.
In several words: systematic archival rather than the vagueness
of transient URLs and search engine caches.
+1
... for all that was wrong with it, the original Netscape Cookie
spec is no longer available from
Please, no.
The RFC Series is not a collection of standards. It is community memory, and in
it we have white papers that have been seminal such as RFC 970, problem
statements, requirements documents, and analyses of a wide variety, all of
which are informational.
Let me give you two
28 matches
Mail list logo
