--On 31. august 2005 03:08 -0700 "william(at)elan.net" <william(_at_)elan(_dot_)net>
wrote:
As such if RFC1032 is being considered for moving to historic (which
may need to happen but I see no reason to do it right now and I think
it would be difficult because many other non-historic RFCs depend on
it), some of what is there that people think is relevant should be
considered for new BCP RFC.
Just because I was curious, I used some time on this....
Bill Fenner's tool <http://rtg.ietf.org/~fenner/ietf/deps/index.cgi> says
(content descriptions mine, based on RFC index):
Documents that depend on: RFC1032
Depending document Type of dependency
rfc1031 (Unknown) rfc1032 (Unknown) unknown MILNET ops
rfc1034 (Standard) rfc1032 (Unknown) unknown DNS spec
rfc1035 (Standard) rfc1032 (Unknown) unknown DNS spec
rfc1183 (Experimental) rfc1032 (Unknown) unknown DNS - more rectypes
rfc1348 (Experimental) rfc1032 (Unknown) unknown DNS NSAP RRs
rfc2052 (???) rfc1032 (Unknown) unknown DNS SRV
rfc1464 (Experimental) rfc1032 (Unknown) unknown DNS arbitary strings
rfc2053 (???) rfc1032 (Unknown) reference AM domain ops
rfc1480 (???) rfc1032 (Unknown) reference US domain ops
rfc1401 (Informational) rfc1032 (Unknown) reference Correspondence
rfc1386 (Informational) rfc1032 (Unknown) reference US domain ops
rfc1123 (Standard) rfc1032 (Unknown) reference Host
Requirements
rfc2065 (???) rfc1032 (Unknown) reference DNSSEC original
Now if we agree that the operations documents and the corrspondence
document are not critical, using the same logic as the logic used for
dismissing RFC 1032, we have the following possibly interesting
dependencies:
RFC 1034 - DNS base specs
Reference: "Current policy for the top levels is discussed in [RFC-1032]."
Reference: "While there are no particular technical constraints dealing
with where in the tree this can be done, there are some administrative
groupings discussed in [RFC-1032] which deal with top level organization,
and middle level zones are free to create their own rules."
Hardly a normative dependency.
RFC 1035 - DNS base specs
Appears in reference list, but is not referenced in the text.
Hardly normative.
RFC 1183 - DNS record types
Appears in reference list, but is not referenced in the text.
Hardly normative.
RFC 1348 - DNS NSAP RR
Appears in reference list, but is not referenced in the text.
This is getting to be familiar....
RFC 2052 - DNS SRV
Appears in....
RFC 1123 - Host Requirements
6.1.4.1 DNS Administration
This document is concerned with design and implementation
issues in host software, not with administrative or
operational issues. However, administrative issues are of
particular importance in the DNS, since errors in particular
segments of this large distributed database can cause poor
or erroneous performance for many sites. These issues are
discussed in [DNS:6] and [DNS:7].
(DNS:6 is RFC 1032)
RFC 2065 - DNSSEC
Appears in reference list, but is not referenced in text....
.... and of course this has been obsoleted by 2535, which is itself
obsoleted.....
(If the authors of draft-sanz want to, they are free to use the information
above..... it's all public info anyway.)
While I still don't see any reason to bother with changing "status UNKNOWN"
to something else, I think the argument that "so many other RFCs depend on
it" can be safely dismissed now - unless someone comes up with a real
example of a NORMATIVE dependency on RFC 1032, of course. I could be wrong.
Harald
pgpw1Aq5pjwPD.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf