--On 31. august 2005 03:08 -0700 "william(at)elan.net" <william@xxxxxxxx> 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 originalNow 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
Attachment:
pgpMoZYujhOtC.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf