Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

--On 31. august 2005 03:08 -0700 "william(at)elan.net" <william@elan.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