Subject: archives (was The other parts of the report....

From: [email-masked] (scott bradner)
Date: Fri, 10 Sep 2004 08:36:37 -0400 (EDT)

fwiw - I would like to see a public archive of old IDs

something like 
http://www.potaroo.net/ietf/html/xids-curr.html

would be ideal (imo)

I also think that there needs to be a concentrated effort to bring the
mailing list archives up to date on the IETF web site (part of that is
to retrieve the old archives for lists which have not been run from
ietf.org)

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Sep 2004 15:19:44 +0200

This has been a rathole every time we've tried to discuss the issues on the 
IETF list.... among other things because nobody's written a draft that 
tries to cover the issues... at least we need to cover:

- whether all people at all times have committed to letting the IETF 
publish their drafts in perpetuity, or only for 6 months
- whether, if that's doubtful, we have to obtain their explicit permission 
or can rely on "we'll publish, tell us if you didn't want it"
- how we should formulate the rule change (if it is a rule change) that 
permits us to do the "eternal publishing" going forwad, and how we should 
make sure people know that

do you really want to take another round around that topic today?

agree that the potaroo.net site is close-to-ideal, once we decide that we 
can do this.....

                         Harald

---

From: [email-masked] (scott bradner)
Date: Fri, 10 Sep 2004 09:30:22 -0400 (EDT)

the last time we talked about this Jorge said that he saw no problem
(legally) to just offer a takedown process to anyone who felt that
they did not want their ID to last longer than N days

but, to me, its quite silly to pretend that IDs actually disapear
from the net just because teh IETF takes it off of our web site

Scott

---

From: Melinda Shore <[email-masked]>
Date: Fri, 10 Sep 2004 09:57:49 -0400

> from the net just because teh IETF takes it off of our web site

I don't think anybody's pretending that, but if there's an agreement
between the IETF and people who submit ids that the documents are
going to be disappeared from the IETF archive in six months, I think
it's kind of a problem to change that agreement retroactively.

On the other hand, I'd hate to see indecision about what to do
about old ids seep into indecision about what to do about new
ids going forward.  It seems to me that a new policy saying that
any ids submitted in the future will be archived by the IETF unless
the authors object is far better than allowing the current
situation to continue.  That wouldn't prevent us from going back
and revisiting the problem of old drafts at some future time,
either.

Melinda

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Fri, 10 Sep 2004 15:12:45 +0100

How about prior art? Am I wrong to think of expiry dates as only relating to
currency to Standards process rather than to the broader record?

Following on from that does the expiry indicate that the copyright reverts
back from ISOC to the authors? I hadn't expected that to be the case.

Christian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> scott bradner
> Sent: 10 September 2004 14:30
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: archives (was The other parts of the report....
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 10 Sep 2004 15:24:46 +0100

>from the net just because teh IETF takes it off of our web site
I completely agree with Scott.

I have always viewed the IETF's insistence on deleting the drafts
as a somewhat quaint and unhelpful, historic custom.

A consequence of this process is that there is no definitive record
of drafts for change control and IPR reference purposes.

I think that we should keep a full archive, but if that is not
deemed possible we should at least keep an archive of the
WG drafts up until the point at which they become RFCs. Without
such an archive there is only a partial record of WG change
consensus.

- Stewart

---

From: [email-masked] (scott bradner)
Date: Fri, 10 Sep 2004 10:34:25 -0400 (EDT)

> back from ISOC to the authors? I hadn't expected that to be the case.

note that the only rights that the ISOC has for IDs is to publish
them and to make derivative works (unless they are marked so as to
not allow derivative works) the autor retains all other rights

the granting (not transfer) of the publication and derivative rights
does not end if the ID gets removed from the IETF public ID directory

Scott

---

From: [email-masked] (scott bradner)
Date: Fri, 10 Sep 2004 10:37:29 -0400 (EDT)

note that a full, but non-public, archive is supposed to be
kept and can be retirieved in a legal discovery process but
it currently can not be publically searched at teh IETF site

Scott

---
>From [email-masked]  Fri Sep 10 10:25:04 2004
Date: Fri, 10 Sep 2004 15:24:46 +0100
From: Stewart Bryant <[email-masked]>
To: scott bradner <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: archives (was The other parts of the report....

- Stewart

---

From: Scott W Brim <[email-masked]>
Date: Fri, 10 Sep 2004 11:18:06 -0400

Drafts are as important as RFCs in demonstrating prior art against silly
patents.  De facto we, as a community, already depend on being able to
find old drafts to defend ourselves.

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Fri, 10 Sep 2004 17:34:04 +0100

scott bradner 10 September 2004 15:34
> does not end if the ID gets removed from the IETF public ID directory

So nothing to stop publication (by ISOC) of ID's in their original format or
if not explicitly disallowed in a compendium or other publication at
anytime.

Christian

---

From: Bill Manning <[email-masked]>
Date: Fri, 10 Sep 2004 09:42:42 -0700 (PDT)

% 
% How about prior art? Am I wrong to think of expiry dates as only relating to
% currency to Standards process rather than to the broader record?
% 
% Following on from that does the expiry indicate that the copyright reverts
% back from ISOC to the authors? I hadn't expected that to be the case.
% 
% Christian
% 
% > -----Original Message-----
% > From: [email-masked] [mailto:[email-masked]]On Behalf Of
% > scott bradner
% > Sent: 10 September 2004 14:30
% > To: [email-masked]; [email-masked]; [email-masked]
% > Subject: Re: archives (was The other parts of the report....
% >
% >
% > the last time we talked about this Jorge said that he saw no problem
% > (legally) to just offer a takedown process to anyone who felt that
% > they did not want their ID to last longer than N days
% >
% > but, to me, its quite silly to pretend that IDs actually disapear
% > from the net just because teh IETF takes it off of our web site
% >

	last time I went through this w/ my legal advisor,
	the general thrust was that the publication of the
	ID involved a "contractual" set of obligations on
	the parties.  When I allowed ISOC/IETF to publish
	my draft, they agreed tocertain terms/conditions.
	One of those terms/conditions was a limited period
	of publication, after which, the rights revert back
	to the author(s). 

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Bill Manning <[email-masked]>
Date: Fri, 10 Sep 2004 09:47:19 -0700 (PDT)

% 
% 
% fwiw - I would like to see a public archive of old IDs
% 
% something like 
% http://www.potaroo.net/ietf/html/xids-curr.html
% 
% would be ideal (imo)

	tangled nest of vipers here. :)
	ome might take the USG tactic and treat the maintance of
	some archive as a "third-party" database - not bound by the
	(not so much) implied publication contract btwn the 
	author(s) and the ISOC/IETF.

% I also think that there needs to be a concentrated effort to bring the
% mailing list archives up to date on the IETF web site (part of that is
% to retrieve the old archives for lists which have not been run from
% ietf.org)

	imho, this may be more important that old ids.

% Scott

--bill

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Sep 2004 09:48:46 -0700

> it's kind of a problem to change that agreement retroactively.

As do I; this is a severely beaten horse.

I also don't mind if new IDs have an opt-in (e.g., via one of a 
proscribed set of phrases in a BCP), but there needs to be a way for 
_any_ ID (even WG IDs) to be ephemeral by design. I would, BTW, prefer 
an opt-in than an opt-out.

Just because others illegally republish them doesn't mean it's 
appropriate to give up on this issue.

> 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 IETF_CENSORED ML 
> Administrator ([email-masked]).

---

From: [email-masked] (scott bradner)
Date: Fri, 10 Sep 2004 14:13:24 -0400 (EDT)

Bill - as I said in a previous posting - it would be quite fine
for you to say 'IETF- you do not have permission to post my expired ID' 
and the IETF should then remove your ID from the IETF's public archive
but just because you might want to do that shoudl not (imo) keep the
IETF from posting the 40,000 or so IDs from others, most of whom I
expect would not object

Scott

---

From: [email-masked] (scott bradner)
Date: Fri, 10 Sep 2004 14:15:28 -0400 (EDT)

ps - look at RFC 3667 section 1 (g)

Scott

---

From: Bill Manning <[email-masked]>
Date: Fri, 10 Sep 2004 11:26:44 -0700 (PDT)

% 
% Bill - as I said in a previous posting - it would be quite fine
% for you to say 'IETF- you do not have permission to post my expired ID' 
% and the IETF should then remove your ID from the IETF's public archive
% but just because you might want to do that shoudl not (imo) keep the
% IETF from posting the 40,000 or so IDs from others, most of whom I
% expect would not object
% 
% 
% Scott

	perhaps true.
	but retro-actively changing the term of a contract,
	esp when no such escape clause was in effect at the
	time the contract was in force, is fraught w/ potential
	liabilities.
	
	not saying it could not happen, just that not all that
	sure of the value proposition of this particular line
	item makes it worthwhile going after the collective
	at this time.  

	it would be worth some cycles to modify the BP used
	to indicate, for the general case, that ISOC or its duly
	authorized agents(blablabla) reserves the right to maintain
	any ID published with this clause intact in the ISOC archives.

	as usual, ymmv.

--bill

---

From: [email-masked] (scott bradner)
Date: Fri, 10 Sep 2004 14:30:37 -0400 (EDT)

yup  - no value here - its just the intellectual history of the IETF :-)

Scott

---

From: Bill Manning <[email-masked]>
Date: Fri, 10 Sep 2004 11:38:54 -0700 (PDT)

% 
%         One of those terms/conditions was a limited period
%         of publication, after which, the rights revert back
%         to the author(s). 
% 
% ps - look at RFC 3667 section 1 (g)
% 
% Scott

	ah... but said RFC did not exist at the time my IDs 
	went out. and my cursory perusal of said RFC seems
	to indicate that it is mute on materials submitted
	into the IETF process in times that pre-date said 
	RFC existance.  In my case, the drafts in question 
	clearly state the terms/conditions of publication
	by the IETF and where said copywright resides.
	Now perhaps the IETF should have refused publication,
	but it did not... so I believe that the T/C in the
	draft are valid.  Legacy stuff is quite thorny.
	Perhaps MO's law should be called on and one could 
	let sleeping dogs/drafts alone. 
	
	RFC 3667 section 1(g) clearly covers most all new
	drafts, save RFC Editor contributions and material
	that is limited by section 3.3(a)(c) - 

	that said, it could be that the 40,000 or so legacy
	draft authors won't care, but it would be sound hygiene
	to ask them if they mind if RFC 3667 rules would apply
	to their contributions.  

--bill

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 11 Sep 2004 06:55:24 -0500

Dear Harald-the-General-AD,

Can we PLEASE do as Melinda says - change the policy now for new 
drafts? so we can stop having part of this conversation and, in the 
meantime, stop making the problem worse?

I review documents for Harald as part of Gen-ART. It is really nice to 
be able to look back at previous versions of a draft and see what's 
been changing. I can trivially do this on a number of other sites, but 
not on the IETF site. This defines "dumb".

Henrik Levkowetz from the Proto team showed me a beautiful "history of 
the draft from 00 to RFC, including ID-Tracker" prototype in San 
Diego - but we can't implement it with our current boilerplate. This 
defines "dumber".

And we know that poor documentation of where we've been before is a 
problem. We've even reached IETF consensus on this. From RFC 3774:

2.7.  Working Group Dynamics can make Issue Closure Difficult

   The IETF appears to be poor at making timely and reasonable 
decisions
   that can be guaranteed to be adhered to during the remainder of a
   process or until shown to be incorrect.

... deleted down to

   Participants are frequently allowed to re-open previously closed
   issues just to replay parts of the previous discussion without
   introducing new material.  This may be either because the decision
   has not been clearly documented, or it may be a maneuver to try to
   get a decision changed because the participant did not concur with
   the consensus originally.  In either case, revisiting decisions 
stops
   the process from moving forward, and in the worst cases, can
   completely derail a working group.

Please note that 3774 is Informational - it is pointedly NOT a "Best 
Current Practice"!!!

Is this a change that requires the IPR working group to express an 
opinion, or can we just do it? and stop vaguely pointing new 
participants with recycled ideas to "the mailing list", some of which 
have been in existence since before HTTP/0.9?

Spencer

From: "Melinda Shore" <[email-masked]>

> situation to continue.

---

From: Joe Touch <[email-masked]>
Date: Sat, 11 Sep 2004 17:40:07 -0700

Spencer Dawkins wrote:

> Can we PLEASE do as Melinda says - change the policy now for new drafts? 

That may have a chilling effect on new drafts. I.e., this isn't as 
simple as "let's just change it now for future stuff".

IMO, changing the policy would indeed be "making the problem worse".

At least, unless there's an explicit opt-out (preferably an opt-in, 
though) that __does not affect the ability of an ID to be a WG document 
or be otherwise affected by procedure___.

Joe

---

From: [email-masked] (Kai Henningsen)
Date: 12 Sep 2004 12:14:00 +0200

> simple as "let's just change it now for future stuff".

"Chilling effect" - from *publishing* already-published material that's  
already copied all over the net?

That sounds rather ridiculous.

How would that effect work on material meant for RFCs, or for working  
group work (where the list archives are already public forever)?

And if it works on some other kind of draft, would we actually care?

> IMO, changing the policy would indeed be "making the problem worse".

I have yet to see a coherent argument for that.

MfG Kai

---

From: Joe Touch <[email-masked]>
Date: Sun, 12 Sep 2004 10:41:56 -0700

> already copied all over the net?

Authors might wait longer to "publish" IDs, since they'd be officially 
citable (once they're public, despite any instructions to the contrary 
in the body). They'd wait longer to submit, to collect sections, etc., 
rather than turning in half-written things with calls for additional 
material.

The other, attractive alternative is to bury the ISOC in ID versions, 
such that previous versions are individually basically useless.

...
> group work (where the list archives are already public forever)?

See above - that's exactly the point. It puts a 'wait, this is going to 
be published - is it ready for that?' hurdle in the loop, one that the 
ID process was designed to avoid.

> I have yet to see a coherent argument for that.

I have yet to see a coherent argument for keeping the ID series if it's 
archived publicly. Why do we need to see the entire process - in public 
- of editing and revision? And if we do, why do we need two separate 
series to do this?

Joe

---

From: [email-masked] (Kai Henningsen)
Date: 13 Sep 2004 21:38:00 +0200

[email-masked] (Joe Touch)  wrote on 12.09.04 in <[email-masked]>:

> in the body).

Huh? Nothing changes in that regard. *Real* official citing is absolutely  
untouched, and the other works via the unofficial repositories now.

> They'd wait longer to submit, to collect sections, etc.,

I cannot see why.

> such that previous versions are individually basically useless.

Nor can I see the motivation, or even the mechanism, here.

> ID process was designed to avoid.

Except it doesn't, really.

> - of editing and revision? And if we do, why do we need two separate

It's not a document series, it's preserving history - exactly the same way  
that the mailing list archives do, using the exact same arguments. (And  
incidentally, the exact same situation wrt. "getting published".)

If you argue that you want to abolish the mailing list archives, I think  
you'll find strong opposition; I certainly do not see why the I-D  
situation is any different.

MfG Kai

---

From: Bob Braden <[email-masked]>
Date: Mon, 13 Sep 2004 13:18:30 -0700

>situation is any different.

This "preserving history" notion is an obfuscation.  If there is a stable
reference to each particular I-D, then the set of I-Ds with those stable
references necessarily form an archival document series.

The Original Intent of the IETF founding fathers was that the RFCs should
form the stable, archival document series for the Internet technology,
containing its entire intellectual history (to use Scott's term), while 
I-Ds were to be
ephemeral.  This is analogous to academic publication; we archive only
the finished papers, not the 17 drafts that go into the production of each 
paper.
Publication in a conference or journal is a filter that keeps us from 
hopelessly
garbaging up the intellectual record.  The FFs believed that preserving 
I-Ds would
lead to such a garbage pile with piles of chaff for every grain of wheat.  Of
course, the IETF has drifted far away from this OI.

But then, you knew all that.

Bob Braden

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 13 Sep 2004 15:02:44 -0700 (PDT)

Bob,

I understand the sentiment of the FFs. The only problem is:

- Once something is published, it is really, really hard to unpublish it.

- Before something becomes a final stable document/standard, it is useful
  to be able to actually refer to it, somehow.

- Even if something never becomes a standard, it may still be useful to
  be able to refer to it.

- The analogy to academic papers is not quite correct as many, many IDs
  never make it beyond "published for information" or "current snapshot
  of X" status. These snapshots, like the mailing list archives, can
  be useful for someone seeking to gain the "larger picture."

I can't really see that there is much difference (at least in some cases)
between and obsolete RFC and an obsolete ID. Readers of the RFCs must
refer to the index to figure out if they have the most recent incarnation,
and it seems to me that a similar mechanism (as outlined by Scott) could
be employed for the IDs.

Relying on IDs timing out and magically disappearing is certainly not
going to work.

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Academic Research and Technology Initiatives, Cisco Systems
Tel: +1 408-527-8972   GSM: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

On Mon, 13 Sep 2004, Bob Braden wrote:

> The Original Intent of the IETF founding fathers was that the RFCs
> should form the stable, archival document series for the Internet
> technology, containing its entire intellectual history (to use Scott's
> term), while I-Ds were to be ephemeral.  This is analogous to academic
> publication; we archive only the finished papers, not the 17 drafts that
> go into the production of each paper. Publication in a conference or
> journal is a filter that keeps us from hopelessly garbaging up the
> intellectual record.  The FFs believed that preserving I-Ds would lead
> to such a garbage pile with piles of chaff for every grain of wheat.
> Of course, the IETF has drifted far away from this OI.
>

---

From: Eric Rosen <[email-masked]>
Date: Tue, 14 Sep 2004 10:49:19 -0400

I've never  thought that  the IETF  was OBLIGATED to  "hide" old  I-Ds; that
seems a rather far-fetched interpretation of anything in RFC 2026. 

However, I think  there is a real practical problem in  making the old i-d's
be too  readily available.   I frequently get  messages asking  me questions
like "where  is draft-rosen-something-or-other-04.txt,  I can't find  it" to
which the answer is one of the following:

a. you want draft-rosen-something-or-other-23.txt, or

b. you want draft-ietf-somewg-something-or-other-05.txt, or

c. you want RFC 12345. 

What's happened is  that they have found some email  which references a long
outdated draft, and have no clue  how to get to the most up-to-date version,
which is what they really want to see. 

If we make it  too easy to access the old drafts, a  lot of people will just
get the old drafts instead of being forced to look for the more recent work.

Sure, people  who really want to  see the old  drafts should be able  to get
them,  but  people who  really  want to  see  the  most up-to-date  versions
shouldn't get the old drafts just because they only know an old draft name.

In a perfect system, someone would go to the IETF's official I-D page, enter
a draft name,  and get a prominent pointer to the  most recent version (even
if it  is now an RFC  or a draft with  a different name), along  with a less
prominent pointer to the thing they actually asked for. 

If  that can't  be  done, it  might be  better  to keep  the expired  drafts
"officially  hidden".   Not  for  the   reasons  being  given  by  our  more
academically inclined  colleagues, but  for the practical  reasons described
above.  Sure, the expired drafts might be obtainable via Google, but getting
something from  Google is  a bit  different than getting  it via  the IETF's
official web page.

---

From: "Steve Crocker" <[email-masked]>
Date: Tue, 14 Sep 2004 11:45:52 -0400

Eric, you specified exactly the right answer:

> In a perfect system, someone would go to the IETF's official 
> I-D page, enter a draft name,  and get a prominent pointer to 
> the  most recent version (even if it  is now an RFC  or a 
> draft with  a different name), along  with a less prominent 
> pointer to the thing they actually asked for. 

This is very feasible and should be done.

Steve

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rosen
> Sent: Tuesday, September 14, 2004 10:49 AM
> To: [email-masked]
> I've never  thought that  the IETF  was OBLIGATED to  "hide" 
> old  I-Ds; that seems a rather far-fetched interpretation of 
> anything in RFC 2026. 
> 
> like "where  is draft-rosen-something-or-other-04.txt,  I 
> can't find  it" to which the answer is one of the following:
> 
> What's happened is  that they have found some email  which 
> references a long outdated draft, and have no clue  how to 
> get to the most up-to-date version, which is what they really 
> want to see. 
> 
> If we make it  too easy to access the old drafts, a  lot of 
> people will just get the old drafts instead of being forced 
> to look for the more recent work.
> 
> Sure, people  who really want to  see the old  drafts should 
> be able  to get them,  but  people who  really  want to  see  
> the  most up-to-date  versions shouldn't get the old drafts 
> just because they only know an old draft name.
> 
> In a perfect system, someone would go to the IETF's official 
> I-D page, enter a draft name,  and get a prominent pointer to 
> the  most recent version (even if it  is now an RFC  or a 
> draft with  a different name), along  with a less prominent 
> pointer to the thing they actually asked for. 
> 
> academically inclined  colleagues, but  for the practical  
> reasons described above.  Sure, the expired drafts might be 
> obtainable via Google, but getting something from  Google is  
> a bit  different than getting  it via  the IETF's official web page. 
> 
> 
>

---

From: Scott W Brim <[email-masked]>
Date: Tue, 14 Sep 2004 11:52:21 -0400

On Tue, Sep 14, 2004 10:49:19AM -0400, Eric Rosen allegedly wrote:
> I've never  thought that  the IETF  was OBLIGATED to  "hide" old
> I-Ds; that seems a rather far-fetched interpretation of anything in
> RFC 2026. 

Also it's impossible.

> In a perfect system, someone would go to the IETF's official I-D page,
> enter a draft name,  and get a prominent pointer to the  most recent
> version (even if it  is now an RFC  or a draft with  a different
> name), along  with a less prominent pointer to the thing they actually
> asked for. 

In the current situation, with the IETF pretending that old versions are
not accessible, and with drafts apparently disappearing as they change
WG status or become RFCs, people have to work very hard to find out if a
particular draft is outdated.  This is a major factor in their depending
on wrong information.  So, instead of trying to suppress information,
which we can't, we should create and offer the meta-information people
need to avoid mistakes.  

> If  that can't  be  done, it  might be  better  to keep  the expired
> drafts "officially  hidden".   Not  for  the   reasons  being  given
> by  our  more academically inclined  colleagues, but  for the
> practical  reasons described above.  Sure, the expired drafts might be
> obtainable via Google, but getting something from  Google is  a bit
> different than getting  it via  the IETF's official web page. 

Suppose they could get them from some reliable source (e.g. IETF) and
also had extremely available meta-info?  

swb

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 14 Sep 2004 10:41:25 -0600 (MDT)

> From: Scott W Brim 

> which we can't, we should create and offer the meta-information people

That should include the meta-information that the draft being sought
expired without being advanced.  Today it is hard for the uninitiated
to distinguish expired drafts that led to BCPs or standards track
RFCs from the expired drafts about encoding more than 4,294,967,296
addresses in 32 bits in order to avoid the hassles of IPv6.

Vernon Schryver    [email-masked]

---

From: [email-masked] (Kai Henningsen)
Date: 14 Sep 2004 20:55:00 +0200

> references necessarily form an archival document series.

You might as well claim that the mailing list archives create an archival  
document series. That is nothing but a red herring.

> the finished papers, not the 17 drafts that go into the production of each

But neither are those 17 drafts published, while the 17 I-Ds are. So, for  
that matter, is all the mailing list discussion around those drafts.

The situation is not even remotely parallel.

> lead to such a garbage pile with piles of chaff for every grain of wheat.

How on earth do I-Ds "hopelessly garbage up the intellectual record" when  
mailing list archives don't?! That doesn't even begin to make any sense.

> But then, you knew all that.

"[T]hat the RFCs should form the stable, archival document series for the  
Internet technology" is certainly still true.

The "containing its entire intellectual history" part was never true, as  
far as I can tell, nor does that claim seem at all sensible. You cannot  
get the entire intellectual history from only looking at the end results.  
That much certainly should be obvious.

It seems to me your definition of "entire" must be really strange.

MfG Kai