[v1_0_0] differences.txt file removed

doc/Makefile.am

@@ -1,6 +1,6 @@
 SUBDIRS = guide design
 
-EXTRA_DIST  = version.ent.in differences.txt Doxyfile Doxyfile-xml
+EXTRA_DIST  = version.ent.in Doxyfile Doxyfile-xml
 EXTRA_DIST += devel/config-backend.dox
 EXTRA_DIST += devel/contribute.dox
 EXTRA_DIST += devel/mainpage.dox

doc/differences.txt

@@ -1,42 +0,0 @@
-Differences of Bind 10 to other software
-========================================
-
-BIND 9
-------
-
-TODO: There are definitely more differences than just this.
-
-DNS zone transfer:
-* When an incoming zone transfer fails, for example because the
-  received zone doesn't contain a NS record, bind 9 stops serving the
-  zone and returns SERVFAIL to queries for that zone. Bind 10 still
-  uses the previous version of zone.
-
-RDATA implementations:
-* IN/A: BIND 10 does not accept abbreviated forms of textual IPv4
-  addresses for class-IN, type-A RDATA.  BIND 9 warns about it but
-  still accepts it as the standard inet_aton() function.  Such forms
-  should actually be NOT accepted per RFC 1035, but BIND 9 accepts them
-  probably because of compatibility reasons.  Until our strict
-  (and more correct) behavior causes operations issues, we'll keep it.
-
-DNS data sources:
-* In-memory data source does not sort RDATA of each RRset (in the
-  DNSSEC order) while BIND 9 normally sorts them internally.  The main
-  purpose of the BIND 9's behavior is to make the ordering
-  predictable, but if the RDATA are rotated in DNS responses (which
-  BIND 9 also does by default) the predictability wouldn't be that
-  useful for the clients.  So we skip the sorting in the BIND 10
-  implementation to simplify the implementation (and possibly make it
-  a bit more efficient).
-
-* If different RRs of the same RRset and their RRSIGs have different
-  TTL when loaded to the in-memory data source, the lowest TTL among
-  all RRs (whether it's the covered RRset or RRSIGs) will be used.
-  BIND 9 shows some inconsistent policy on this point for unknown
-  reason (sometimes the TTL of the first RR is used, sometimes the
-  latest one is used).  We differ here firstly for consistency, and
-  because it seems to be more compliant to the sense of RFC2181.
-  In any case, the administrator should make the TTLs same, especially
-  if the zone is signed, as described in RFC4034 (and, that will be
-  normally ensured by zone signing tools).