[rfc-i] Proper status for pre-IETF RFCs currently with "unknown"

bob.hinden at gmail.com (Bob Hinden) Mon, 07 November 2011 01:45 UTC

From: "bob.hinden at gmail.com"
Date: Sun, 06 Nov 2011 17:45:36 -0800
Subject: [rfc-i] Proper status for pre-IETF RFCs currently with "unknown"
In-Reply-To: <4EB71C13.9070908@isi.edu>
References: <mailman.1.1320174001.26658.rfc-interest@rfc-editor.org> <C6D60A559F67EBB45F189D92@[192.168.1.128]> <BFF38DB7-1152-405A-A13D-737EE8F2321E@isi.edu> <5ED0419AE34825E011B12886@[192.168.1.128]> <766C19A9-B111-43FF-BB82-AC27988BB57E@isi.edu> <C2E8016662AFEAB18B843B2C@[192.168.1.128]> <4EB71C13.9070908@isi.edu>
Message-ID: <7C3CE093-82C4-4DA9-8CBD-F30F94C69503@gmail.com>

To clarify something, are we talking about changing something in a published RFC, or just changing a label in a file/search result.

For example, when I do a search for RFC100 (just picked a low number) on rfc-editor.org, it returns a line that shows the status as "UNKOWN".  The actual RFC does not include that.

I would be OK with changing to the database to return some other result such as "ARPANET" as John suggested, as long as we are not changing the actual RFCs.   I assume that is what John suggested, but wanted to clarify.

Bob


On Nov 6, 2011, at 3:45 PM, Joe Touch wrote:

> 
> 
> On 11/6/2011 9:31 AM, John C Klensin wrote:
> ...
>>> My view is that history shouldn't be rewritten.
>> 
>> I guess my view is that the series is active and useful, not an
>> ossified fossil.  One could claim that history was rewritten
>> when categories were assigned in the first place, when IETF
>> documents (and IENs) were merged into and replaced by the
>> series, and so on.  So, if you have some particular point at
>> which you'd like to see change stop --whether you call that
>> "rewriting history" or not-- I'd like to understand that, and
>> the logic behind it, better.
> 
> I call tacking names and categories onto published documents revisionist history.
> 
> Once published, a doc should not be modified. We understand that with -bis docs (i.e., we don't rewrite an RFC with the same number); why don't we understand that for labels?
> 
>> FWIW, if you don't think the IESG/IETF has the authority to
>> change names within the IETF Stream, then you should rush out
>> and appeal the recent decision to move from there Standards
>> Track levels to two and rename the second.
> 
> Within the IETF stream is a different matter. The docs we're talking about predate that.
> 
>>> ...
>>>> If I understand you, you are suggesting that we call the IETF
>>>> Stream today be separated from the RFC Series entirely?  I
>>>> think the time at which that might have been possible is long
>>>> gone and that it is a far more radical suggestion than
>>>> classifying a bunch of early documents out of "unknown".
>>> 
>>> The time to rename or add names to early docs has clearly
>>> passed.
>> 
>> "Clearly" from what point of view?  No one, certainly not me,
>> has proposed changing the documents or their names, only the
>> category names by which they are identified in the index.
> 
> My first concern would be placing these labels inside the docs, i.e., in the top of the first page. That is revisionist.
> 
> My second concern is the IETF attaching labels to docs they didn't generate. That's outside their scope IMO.
> 
>>> It's still rewriting history. Leave the old docs alone.
>> 
>> See above.  No one, as far as I know, has proposed to change
>> those documents or to make them not-RFCs.  All we are talking
>> about doing is providing a better category-identifier for them
>> in the index than "unknown", a chance that would give them a
>> more distinctive status, not less.
> 
> They should, at best, be in the index in the category "None". Any other classification is outside the scope of the IETF to determine, IMO.
> 
>>> The only reason to do this labeling is to avoid "confusion"
>>> between a name the IESG didn't earn for itself and one the
>>> early RFCs did.
>> 
>> No, the reason is to replace "Unknown" with a term that is more
>> useful and better identification.  Those early RFCs didn't
>> "earn" the title "UNKNOWN" and were certainly in no sense
>> "unknown" when they were written, it was dropped on them many
>> years later.
> 
> I certainly agree with that. But they don't deserve any other classification either - "legacy", "arpanet" (not all are directly arpanet-related), etc.
> 
>>>> YMMD, but I don't believe that discussion is even worth having
>>>> today (even though I would prefer it to notions of getting rid
>>>> of the Independent Stream).
>>> 
>>> I'm saying:
>>> 
>>> 	1- if you want to be called an RFC, then you need to admit
>>> 	that you do not control the legacy RFCs, and have no right
>>> 	to rename/reclassify them
>> 
>> If I understand what you are saying here, it is equivalent to my
>> assertion that the IESG cannot reclassify (or rename, but no one
>> has proposed that) documents that are outside the IETF Stream or
>> that predated the IETF.  If so, we are in complete agreement.
> 
> Yes.
> 
>>> 	2- if you don't like #1, then create your own series (stream
>>> 	within RFC if the new stream label is sufficient; if you
>>> 	don't want the term "RFC" to be confusing, come up with
>>> 	a new name for a new document series)
>> 
>> I like #1 and I have not suggested changing the term "RFC" in
>> any present or past documents.     So your position confuses me.
> 
> My position is that any position that oppposes #1 ought to be seeking a new name for the series of documents from this point forward, not trying to usurp "RFC" and redefine it post-facto.
> 
>>> Remember, the IENs predate the RFCs. Maybe it's time the IESG
>>> considers creating its own doc series whose names/tags it can
>>> change with abandon.
>> 
>> Actually, they do not (although they do predate the IETF).
> 
> Agreed; I had meant to say "the IENs predate the current categories in the RFCs"... I.e., there is precedent for creating new document series. IMO, that's more appropriate than trying to continually redefine RFCs to avoid confusion among the uninformed.
> 
> Joe
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest