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

From: Pekka Savola <[email-masked]>
Date: Fri, 28 May 2004 14:46:37 +0300 (EEST)

Hi,

A few comments.  I think we should go forward with this ASAP.

for what it's worth, there isn't a huge reason to reclassify stuff that's
being used by fringe communities to informational; historic is just fine. 
But either way works for me.

substantial
-----------

 - 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.

 - 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.

(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)

semi-editorial
--------------

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

 - 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.

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

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

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