Remove rfc-compliance list in plaintext - ARM deduplication

The plaintext version is now fully replaced by the doc/arm/general.rst.

(cherry picked from commit 63989e98ac06cf1895727357a3a6cb5401fd8daa)

diff --git a/doc/misc/rfc-compliance b/doc/misc/rfc-compliance
deleted file mode 100644 (file)
index 183afaf..0000000
--- a/doc/misc/rfc-compliance
+++ /dev/null
@@ -1,166 +0,0 @@
-Copyright (C) Internet Systems Consortium, Inc. ("ISC")
-
-SPDX-License-Identifier: MPL-2.0
-
-This Source Code Form is subject to the terms of the Mozilla Public
-License, v. 2.0.  If a copy of the MPL was not distributed with this
-file, you can obtain one at https://mozilla.org/MPL/2.0/.
-
-See the COPYRIGHT file distributed with this work for additional
-information regarding copyright ownership.
-
-BIND 9 is striving for strict compliance with IETF standards.  We
-believe this release of BIND 9 complies with the following RFCs, with
-the caveats and exceptions listed in the numbered notes below.  Note
-that a number of these RFCs do not have the status of Internet
-standards but are proposed or draft standards, experimental RFCs,
-or Best Current Practice (BCP) documents.  The list is non exhaustive.
-
-  RFC1034
-  RFC1035 [1] [2]
-  RFC1101
-  RFC1123
-  RFC1183
-  RFC1521 [16]
-  RFC1535
-  RFC1536
-  RFC1706
-  RFC1712
-  RFC1750
-  RFC1876
-  RFC1982
-  RFC1995
-  RFC1996
-  RFC2136
-  RFC2163
-  RFC2181
-  RFC2230
-  RFC2308
-  RFC2539
-  RFC2606 [17]
-  RFC2782
-  RFC2874 [18]
-  RFC2930
-  RFC2931 [5]
-  RFC3007
-  RFC3110
-  RFC3123
-  RFC3225
-  RFC3226
-  RFC3363 [6]
-  RFC3403
-  RFC3493
-  RFC3496
-  RFC3597
-  RFC3645
-  RFC4025
-  RFC4033
-  RFC4034
-  RFC4035
-  RFC4074
-  RFC4255
-  RFC4294 - Section 5.1 [8]
-  RFC4343
-  RFC4398
-  RFC4431 [22]
-  RFC4470 [9]
-  RFC4509
-  RFC4592
-  RFC4635
-  RFC4701
-  RFC4892
-  RFC4955 [10]
-  RFC5001
-  RFC5011
-  RFC5155
-  RFC5205
-  RFC5452 [11]
-  RFC5702
-  RFC5891 [7]
-  RFC5936
-  RFC5952
-  RFC6052
-  RFC6147 [12]
-  RFC6303
-  RFC6604
-  RFC6605 [13]
-  RFC6672
-  RFC6698
-  RFC6742
-  RFC6725 [19]
-  RFC6840 [14]
-  RFC6891
-  RFC7043
-  RFC7208
-  RFC7314
-  RFC7344 [20]
-  RFC7477
-  RFC7553
-  RFC7766
-  RFC7793
-  RFC7830 [15]
-  RFC7929
-  RFC8078 [20]
-  RFC8080
-  RFC8624
-  RFC8659
-  RFC8945
-
-[1] Queries to zones that have failed to load return SERVFAIL rather
-than a non-authoritative response.  This is considered a feature.
-
-[2] CLASS ANY queries are not supported.  This is considered a
-feature.
-
-[5] When receiving a query signed with a SIG(0), the server will
-only be able to verify the signature if it has the key in its local
-authoritative data; it will not do recursion or validation to
-retrieve unknown keys.
-
-[6] Section 4 is ignored.
-
-[7] Requires --with-libidn2 to enable entry of IDN labels within dig,
-host and nslookup at compile time.  ACE labels are supported
-everywhere with or without --with-libidn2.
-
-[8] Section 5.1 - DNAME records are fully supported.
-
-[9] Minimally Covering NSEC Record are accepted but not generated.
-
-[10] Will interoperate with correctly designed experiments.
-
-[11] Named only uses ports to extend the id space, address are not
-used.
-
-[12] Section 5.5 does not match reality.  Named uses the presence
-of DO=1 to detect if validation may be occurring.  CD has no bearing
-on whether validation is occurring or not.
-
-[13] Conditional on the OpenSSL library being linked against
-supporting ECDSA.
-
-[14] Section 5.9 - Always set CD=1 on queries.  This is *not* done as
-it prevents DNSSEC working correctly through another recursive server.
-
-When talking to a recurive server the best algorithm to do is send
-CD=0 and then send CD=1 iff SERVFAIL is returned in case the recurive
-server has a bad clock and/or bad trust anchor.  Alternatively one
-can send CD=1 then CD=0 on validation failure in case the recursive
-server is under attack or there is stale / bogus authoritative data.
-
-[15] Named doesn't currently encrypt DNS requests so the PAD option
-is accepted but not returned in responses.
-
-[16] Only the Base 64 encoding specification.
-
-[17] Not applicable to DNS server implementations.
-
-[18] Loading and serving of A6 records only.  A6 records were moved
-to the experimental category by RFC3363.
-
-[19] RSAMD5 support has been removed. See RFC 6944 and RFC 8624.
-
-[20] Updating of parent zones is not yet implemented.
-
-[22] Compliance is with loading and serving of DLV records only.
-DLV records were moved to the historic category by RFC 8749.