On Fri, 31 May 2002 16:09:47 +0700, Robert Elz said:
My suggestion to fix this problem is quite simple
No more last calls before moving protocols to historic,
except where they're full standards already.
For everything else, going to historic should be automatic. That is,
the only way to avoid any spec being made historic automatically, is
for it to become a full standard.
OK.. I'll bite - at what point should a not-yet-full standard expire to
historic?
And the flip side - we've moved an amazingly SMALL number of documents
to Full Standard, and only when we *think* we *fully* understand things.
Even then, things have been known to get "out of sync" with reality:
1119 Network Time Protocol (version 2) specification and
implementation. D.L. Mills. Sep-01-1989. (Format: TXT=143, PS=518020,
PDF=187940 bytes) (Obsoletes RFC0958, RFC1059) (Obsoleted by RFC1305)
(Also STD0012) (Status: STANDARD)
1305 Network Time Protocol (Version 3) Specification, Implementation.
David L. Mills. March 1992. (Format: TXT=307085, PDF=442493 bytes)
(Obsoletes RFC0958, RFC1059, RFC1119) (Status: DRAFT STANDARD)
One of the *GOOD* things about protocols living at DS is that you can convince
vendors to start supporting the *new* DS rather than the *old* one. I've
had *enough* fun with one vendor who insisted on sticking with RFC2133
rather than updating to RFC2553 for IPv6 socket API, even though both
are only Informational.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
pgpzfBfdUe7xn.pgp
Description: PGP signature