Subject: Re: [newtrk] comments on draft-alvestrand-newtrk-historical-00

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Jun 2004 12:06:52 +0200

Pekka Savola wrote:

>  - shouldn't this document (and the comission) also be commissioned to
> review and historicize BCP, experimental, or informational documents?  
> Maybe this would add a load a bit, but IMHO similar maintenance on
> those would be similarly welcome as well, even if due to different
> reasons.

Actually, I'm less concerned about experimental, and don't quite know 
how to consider informational documents.  And yes, the workload is 
substantial.  Scott has raised a point in the past that we need to 
distinguish between "dangerous" and merely "musty", by the way.  Perhaps 
that is relevant here.

But now let me agree with you on BCP, because C stands for Current.  And 
perhaps what was Current is no longer.

> 
>  - additional thought: this commission could be chartered to publish, e.g.
> once a year, an informational RFC describing its reasons for moving certain
> documents to historic.  This would not necessarily need to be longer than a
> paragraph per document (or not even that for documents having identical
> reasons), but I think it might be useful -- for the record -- to document
> the background for the actions.

In general what is needed is a clear set of recommendations that the 
IESG can act on without having to devote too much brain power.  That is 
the key.  That which frees up IESG time is a GOOD thing.  Whatever 
records are used should be documented ONCE.  Moreso is too much work.

> 
> (this kind of justification is especially important for those docs which are
> historiziced based on "potential for harm" -grounds, i.e.., where the reason
> may not be blindingly obvious.
> 
>  - is the "interest for future work" an overriding criterium?  it could be
> read like it is.  I.e., if there are no implementations or usage of the
> spec, but the spec could still be revised from PS to DS at some timeframe,
> is not historicizing it a good choice?  (there are arguments both ways, of
> course... but this looks like "I want to revise this even though it's not
> being used" is a show-stopper)

I'm tempted to suggest that we cross that bridge when we come to it 
because it seems to bely the laws of physics.  If there are people who 
are interested, and the IESG wants to devote room space and mind share, 
it would seem somewhat pointless to touch the document at that point for 
two reasons:

  1.  excessive confusion
  2.  more people have to work on the problem
  3.  the iesg could end up having to work on the problem TWICE

> 
> semi-editorial
> --------------
> 
>  - this has the old rfc2026 boilerplate, update to rfc3668?

Ok.

> 
>  - does it need spelling out in sect 3.2 that a spec must have stayed
> unimplemented for a relatively long time to be qualify as a reason for
> moving to historic?  or other guidance like that?  practically this isn't
> probably needed, but if folks have an opinion how long is "long enough" for
> unimplementation, putting hints here might not hurt.

Not initially.

> 
>  - the chair reporting every 6 months in section 4; would "3 times a year"
> be better (or the like), per the IETF meeting cycles?

The purpose of the report is to determine whether or not the commission 
is being successful.  So consider it a "review" cycle.  Want a 4 month 
review?  One might argue that it should be annual...

Eliot
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jun 2004 13:00:31 +0300 (EEST)

I was waiting if someone else would comment on this, but obviously 
not.. inline..

> perhaps what was Current is no longer.

I can agree to this from the priorization point of view, but IMHO the
whole point of this effort is to diminish the work load.  So, I
wouldn't see a reason for chartering a group which could (secondarily)  
also look at info/experimental documents.

> records are used should be documented ONCE.  Moreso is too much work.

Maybe you misread what I said, or I didn't elaborate it enough.

Let's assume the comittee would historize 60 PS's during the first 
year, 40 PS's in the second year, etc.

What I'd like to see is an informational document, after a year (or
some other period of time), describing the justifications for
historizing those 60 (and during the next year, 40) PS's.  That
doesn't strike to me as a lot of work.  Read: how I'd imagine this
would work is that the comittee would gather 10-15 priority documents
at a time, coin up short justification for each document (e.g., "this
is 10 years old, and never implemented and deployed in the Internet"),
combine them in a message, get that IETF Last Called, take the
comments into account, and push to the IESG.  After a year, or so, 
collect these justifications up in a document which would get 
published for archival reasons.

The key point here would be, that unless you speak up and state that
the document is still usable, a standard, very short justification
boilerplate for historicizing would be used.

> review?  One might argue that it should be annual...

4 months of inactivity is already a long time.  In other words, a
committee which would have nothing to report in every 4 months would
not be doing its job properly, IMHO.

Having to give reports forces to make progress [or give bad reports
:)].  We want to encourage making progress :).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jun 2004 13:37:38 +0300 (EEST)

> also look at info/experimental documents.

Sorry for too fast typiping here -- I meant 'could not' in the above..

(I.e., if the load of moving PS documents to historic using this 
process is too high, then perhaps the process needs to be made 
smoother.)

IMHO, such a comittee should be able to easily classify at least 100
or 200 documents a year..  That's only about 2 or 4 documents a week.

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 04 Jun 2004 08:22:09 -0700

When thinking about this when typing, I thought about an RFC rather than a 
mailing list message (archived in the ML archives), and landed on the 
opinion that mailing list archives are part of the public record of IETF 
activities too. Google is good at searching well-constructed archives, and 
RFCs have a higher processing overhead.

What are the advantages you see of RFC publication over ML archives?

                         Harald

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 5 Jun 2004 03:26:06 -0500

Hi, Harald,

Which mailing list archive are we talking about?

I have a lot higher confidence in most people finding RFCs than a
particular article somewhere in ML archives, especially if posting is
a manual process and mistakes like omitting "To Historical" in the
subject line (or whatever the flag is supposed to be) can happen.

Spencer

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "Pekka Savola" <[email-masked]>; "Eliot Lear" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 04, 2004 10:22 AM
Subject: Re: [newtrk] comments on
draft-alvestrand-newtrk-historical-00

.