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
Attachment:
pgp00072.pgp
Description: PGP signature